KubeApiServer 监控实操 APIServer 在 Kubernetes 架构中非常核心，是所有 API 的入口，APIServer 也暴露了 metrics 数据，我们尝试获取一下： [root@dev01.nj etcd]# ss -tlpn|grep apiserver LISTEN 0 128 *:6443 *:* users:(("kube-apiserver",pid=164445,fd=7)) [root@dev01.nj etcd]# curl -s http://localhost:6443/metrics Client sent an HTTP request to an HTTPS server. [root@dev01.nj etcd]# curl -s -k https://localhost:6443/metrics { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "forbidden: User \"system:anonymous\" cannot get path \"/metrics\"", "reason": "Forbidden", "details": {}, "code": 403 } 解释一下上面的命令和结果。首先我通过 ss 命令查看 apiserver 模块监听在哪些端口，发现这个进程在 6443 端口有监听。然后，使用 curl 命令请求 6443 的 metrics 接口，结果又说这是一个 HTTPS Server，不能用 HTTP 协议请求。好，那我用 HTTPS 协议请求，自签证书，加了 -k 参数，返回 Forbidden，说没权限访问 /metrics 接口。OK，那看来是需要 Token 鉴权，我们创建一下相关的 ServiceAccount。...

kubelet 监控实操 Kube-Proxy 的/metrics接口没有认证，相对比较容易，这一篇我们介绍一下 Kubelet，Kubelet 的监控相比 Kube-Proxy 增加了认证机制，相对更复杂一些。 Kubelet 端口说明 如果你有多台 Node 节点，可以批量执行 ss -tlnp|grep kubelet 看一下，Kubelet 监听两个固定端口(我的环境，你的环境可能不同)，一个是 10248，一个是 10250，通过下面的命令可以知道，10248 是健康检查的端口： [root@dev01.nj ~]# ps aux|grep kubelet root 163490 0.0 0.0 12136 1064 pts/1 S+ 13:34 0:00 grep --color=auto kubelet root 166673 3.2 1.0 3517060 81336 ? Ssl Aug16 4176:52 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --hostname-override=10.206.0.16 --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.6 [root@dev01.nj ~]# cat /var/lib/kubelet/config.yaml | grep 102 healthzPort: 10248 [root@dev01.nj ~]# curl localhost:10248/healthz ok 我们再看一下 10250，10250 实际是 Kubelet 的默认端口，/metrics 接口就是在这个端口暴露的，我们请求一下：...

kube-proxy 监控实操 Kube-Proxy 是在所有工作负载节点上的，默认暴露两个端口，10249 用于暴露监控指标，在 /metrics 接口吐出 Prometheus 协议的监控数据： [root@dev01.nj lib]# curl -s http://localhost:10249/metrics | head -n 10 # HELP apiserver_audit_event_total [ALPHA] Counter of audit events generated and sent to the audit backend. # TYPE apiserver_audit_event_total counter apiserver_audit_event_total 0 # HELP apiserver_audit_requests_rejected_total [ALPHA] Counter of apiserver requests rejected due to an error in audit logging backend. # TYPE apiserver_audit_requests_rejected_total counter apiserver_audit_requests_rejected_total 0 # HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles....

组件监控 k8s 主要是控制面组件；控制面组件包括 API Server、Scheduler、Controller-Manager、ETCD 四个组件，每个组件都很重要，需要黑盒、白盒监控并举。计算面主要是工作节点；工作节点主要用来运行工作负载，节点运行了 Pod 容器负载，以及容器引擎和 Kubernetes Node 组件，容器引擎图上是 Docker，不过不局限 Docker，也可能是别的容器引擎，Kubernetes Node 组件包括 Kubelet 和 Kube-Proxy，也都是需要监控的。 节点监控 Node-Exporter 这个大家比较熟悉了，专注在机器层面的指标监控，并且只专注机器层面的指标监控，因为是 Prometheus 生态的组件，使用 Prometheus 的用户初次入行，大概率会采用这个采集器。如果可以接受PULL模式并且只是处理机器监控，Node-Exporter 是完全够用的。 Categraf Categraf 是 Flashcat 开源的一款监控采集器，开源协议是 MIT，非常开放。 Categraf 偏重 Prometheus 生态，标签是稳态结构，只采集数值型时序数据，通过 Remote Write 方式推数据给后端存储，所有支持 Remote Write 协议的时序库都可以对接，比如 Prometheus、VictoriaMetrics、M3DB、Thanos 等等。 对于习惯使用 Prometheus 的用户，Categraf 也支持直接读取 prometheus.yml 中的 scrape 规则，对接各类服务发现机制，实现上就是把 Prometheus agent mode 的代码引入进来了。 Categraf 作为一款 agent 需要部署到所有目标机器上，因为采集 CPU、内存、IO、进程等指标，是需要读取 OS 里的一些信息的，远程读取不了。采集到数据之后，做格式转换，传输给监控服务端，这里我们使用 Nightingale 作为监控服务端软件。 Categraf 推送监控数据到服务端，走的是 Prometheus 的 RemoteWrite 协议，是基于 protobuf 的 HTTP 协议，所以，不止是 Nightingale，所有支持 RemoteWrite 的后端，都可以和 Categraf 对接。...

vite vue 文件配置 // https://vitejs.dev/config/ export default defineConfig(({ command, mode }) => { // 根据当前工作目录中的 `mode` 加载 .env 文件 // 设置第三个参数为 '' 来加载所有环境变量，而不管是否有 `VITE_` 前缀。 const env = loadEnv(mode, process.cwd(), ""); return { // vite 配置 plugins: [ vue(), AutoImport({ imports: ["vue", "vue-router", "pinia", "vue-i18n"], resolvers: [ElementPlusResolver()], }), Components({ resolvers: [ElementPlusResolver()], }), ], server: { // 如果使用docker-compose开发模式，设置为false open: true, port: 8081, proxy: { // 把key的路径代理到target位置 [env.VITE_BASE_API]: { // 需要代理的路径 例如 '/api' target: `${env....