云原生教程【免费下载链接】kubernetes-handbookKubernetes Handbook Kubernetes指南 https://kubernetes.feisky.xyz项目地址https://gitcode.com/gh_mirrors/kub/kubernetes-handbook点击查看免费下载Kubernetes 社区提供了一系列工具来监控容器与集群的运行状态并可借助 Prometheus 构建告警能力。本篇指南以 kubernetes-handbook 仓库的 en/addons/monitor.md 为主线系统梳理 cAdvisor、metrics-server、Heapster、InfluxDBGrafana、Prometheus、Node Problem Detector 以及 sysdig、Weave Scope 等工具的角色分工、部署步骤与排错方法并结合仓库内的 metrics-server 部署清单、Prometheus 配置示例 与 NPD 部署清单 等源码级证据深入讲解。读完本文你将掌握一套覆盖节点采集—集群聚合—存储展示—告警—节点健康检测—容器排错的完整 Kubernetes 监控实践方案。监控工具全景各司其职的分层结构Kubernetes 监控体系并非单一工具而是由多个组件按职责分层协作社区常用工具及其定位如下工具监控范围核心职责数据/接口cAdvisor单节点容器与节点资源使用统计内置在 Kubelet 内部Kubelet/metrics/cadvisorAPImetrics-server集群提供集群核心资源度量通过 Metrics API 对外/apis/metrics.k8s.io/Heapster已弃用集群聚合全集群资源监控支持持久化到多种后端/metricsPrometheus 格式InfluxDB Grafana存储与展示时序数据库存储监控数据Grafana 提供图表 DashboardInfluxDB 8086 / Grafana 3000kube-state-metrics集群提供 Kubernetes 资源对象DaemonSet、Deployment 等的度量Prometheus 格式Prometheus集群监控与时间序列数据库提供查询语言和告警功能HTTP /9090Node Problem Detector节点监测 Node 硬件、内核、运行时等异常NodeCondition / Node Eventsysdig / Weave Scope容器容器排错与可视化监控命令行 / 交互式拓扑界面其中cAdvisor 解决单机容器资源问题metrics-server 解决集群核心度量供给问题Prometheus 承担长期存储、查询与告警职责而 Node Problem Detector 则补齐了节点自身健康的监控盲区。cAdvisorKubelet 内置的节点资源采集器[cAdvisor] 是来自 Google 的容器监控工具也是 Kubelet 内置的容器资源收集组件。它会自动收集本机容器与节点的 CPU、内存、网络和文件系统资源占用情况并对外提供 cAdvisor 原生 API默认端口为--cadvisor-port4194该端口在未来版本中可能被移除。从 v1.7 开始Kubelet metrics API 不再包含 cAdvisor metrics而是拆分为两个独立的 API 接口Kubelet metricshttp://127.0.0.1:8001/api/v1/proxy/nodes/node-name/metricscAdvisor metricshttp://127.0.0.1:8001/api/v1/proxy/nodes/node-name/metrics/cadvisorcAdvisor metrics 通常是监控系统必需的数据因此需要为 Prometheus 增加新的 target 来解决例如通过 Helm 一键部署helm install stable/prometheus --set rbac.createtrue --name prometheus --namespace monitoring仓库 setup/addon-list/monitor.md 进一步提醒cAdvisor 监听的端口将在 v1.12 中删除建议所有外部工具改用 Kubelet Metrics API 替代避免长期依赖已废弃的端口。metrics-server 与 Metrics API集群核心度量的现代方案从 v1.8 开始资源使用情况如容器 CPU、内存使用量可以通过 Metrics API 获取这是取代 Heapster 的现代方案相关要点见 setup/addon-list/metrics.mdMetrics API 只可以查询当前的度量数据并不保存历史数据Metrics API URI 为/apis/metrics.k8s.io/由 k8s.io/metrics 维护必须部署 metrics-server 才能使用该 APImetrics-server 通过调用 Kubelet Summary API 获取数据。在 Kubernetes 监控架构中存在两条流程核心度量流程从 Kubelet、cAdvisor 等获取度量由 metrics-server 提供给 Dashboard、HPA 控制器使用和监控流程基于核心度量构建如 Prometheus 从 metrics-server 获取核心度量从 Node Exporter 等其他数据源获取非核心度量再构建监控告警系统。HPA 等弹性伸缩功能也依赖该管道——concepts/objects/autoscaling.md 明确指出在使用 HPA 之前需要确保已部署好 metrics-server。开启 API Aggregation部署 metrics-server 前需要在 kube-apiserver 中开启 API Aggregation即增加以下配置--requestheader-client-ca-file/etc/kubernetes/certs/proxy-ca.crt --proxy-client-cert-file/etc/kubernetes/certs/proxy.crt --proxy-client-key-file/etc/kubernetes/certs/proxy.key --requestheader-allowed-namesaggregator --requestheader-extra-headers-prefixX-Remote-Extra- --requestheader-group-headersX-Remote-Group --requestheader-username-headersX-Remote-User如果 kube-proxy 没有在 Master 上运行还需要额外配置--enable-aggregator-routingtrue。部署 metrics-servergit clone https://github.com/kubernetes-incubator/metrics-server cd metrics-server kubectl create -f deploy/1.8/稍后即可查看运行状态kubectl -n kube-system get pods -l k8s-appmetrics-server仓库 manifests/metrics-server/ 目录提供了完整的部署清单从源码层面可还原其工作方式metrics-server-deployment.yaml 定义了核心启动参数--sourcekubernetes.summary_api:说明 metrics-server 通过Kubelet Summary API采集数据与文档描述一一对应metrics-apiservice.yaml 注册了v1beta1.metrics.k8s.io这个 APIService将/apis/metrics.k8s.io/请求代理到 kube-system 命名空间下的 metrics-server 服务resource-reader.yaml 通过 ClusterRole 授予了 pods、nodes、namespaces、deployments 的 get/list/watch 权限这是其聚合集群数据所需的 RBAC 基础auth-delegator.yaml 与 auth-reader.yaml 则完成了认证委托配置使 apiserver 可以验证请求者身份。访问 Metrics API可以通过kubectl proxy访问 Metrics APIhttp://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodeshttp://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/node-namehttp://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/podshttp://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespaces/namespace-name/pods/pod-name也可以直接用kubectl get --raw访问kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodeskubectl get --raw /apis/metrics.k8s.io/v1beta1/podskubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes/node-namekubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/namespace-name/pods/pod-name排错metrics-server CrashLoopBackOff如果发现 metrics-server Pod 无法正常启动处于 CrashLoopBackOff 状态且 restartCount 不断增长则很可能是其与 kube-apiserver 通信异常。查看 Pod 日志会出现dial tcp 10.96.0.1:443: i/o timeout解决方法是开启 Docker 容器的 IP 转发echo ExecStartPost/sbin/iptables -P FORWARD ACCEPT /etc/systemd/system/docker.service.d/exec_start.conf systemctl daemon-reload systemctl restart dockerInfluxDB 与 Grafana时序存储与图表展示InfluxDB 是一个开源分布式时序、事件和指标数据库而 Grafana 则是面向时序数据的 Dashboard提供了强大的图表展示功能。二者常被组合使用用于展示图表化的监控数据。仓库 manifests/heapster/grafana.yaml 展示了这套组合的容器化部署要点Grafana 通过环境变量INFLUXDB_HOSTmonitoring-influxdb指定数据源地址暴露 3000 端口同时通过GF_AUTH_ANONYMOUS_ENABLEDtrue开启匿名访问以便通过 apiserver 代理访问生产环境则建议关闭这些变量、启用认证并通过 LoadBalancer 或公网 IP 暴露服务。Heapster集群级资源监控已弃用Kubelet 内置的 cAdvisor 只提供单机容器资源占用情况而 Heapster 提供整个集群的资源监控并支持持久化数据存储到 InfluxDB、Google Cloud Monitoring 或 OpenTSDB 等其他后端存储。Heapster 的工作流程是首先从 Kubernetes apiserver 查询所有 Node 的信息然后从 kubelet 提供的 API 采集节点和容器的资源占用同时在/metricsAPI 提供 Prometheus 格式的数据。仓库 manifests/heapster/heapster.yaml 中的启动参数印证了这一流程--sourcekubernetes:https://kubernetes.default从 apiserver 发现集群--sinkinfluxdb:http://monitoring-influxdb.kube-system.svc:8086将数据推送到 InfluxDB。需要特别注意的是 Heapster 的弃用状态见 setup/addon-list/monitor.md仅 Kubernetes v1.7.X 或更老的集群推荐使用 Heapster从 v1.8 开始资源使用情况度量已通过 Metrics API 获取HPA 也从 metrics-server 查询数据Heapster 已在 v1.11 中弃用推荐 v1.8 及以上版本部署 metrics-server 替代。部署 Heapster、InfluxDB 和 Grafana在 Kubernetes 部署成功后dashboard、DNS 和监控服务通常已默认部署。例如通过cluster/kube-up.sh部署的集群默认开启以下服务$ kubectl cluster-info Kubernetes master is running at https://kubernetes-master Heapster is running at https://kubernetes-master/api/v1/proxy/namespaces/kube-system/services/heapster KubeDNS is running at https://kubernetes-master/api/v1/proxy/namespaces/kube-system/services/kube-dns kubernetes-dashboard is running at https://kubernetes-master/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard Grafana is running at https://kubernetes-master/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana InfluxDB is running at https://kubernetes-master/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb如果这些服务没有自动部署可参考 kubernetes/heapster 的 deploy/kube-config 来部署git clone https://github.com/kubernetes/heapster cd heapster kubectl create -f deploy/kube-config/influxdb/ kubectl create -f deploy/kube-config/rbac/heapster-rbac.yaml注意访问这些服务时需要先在浏览器中导入 apiserver 证书才能通过认证。为简化访问也可以使用 kubectl 代理不需要导入证书# 启动代理 kubectl proxy --address0.0.0.0 --port8080 --accept-hosts^*$ 然后打开http://master-ip:8080/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana即可访问 Grafana。Prometheus监控与告警的时间序列数据库Prometheus 是另一个监控和时间序列数据库除存储外还提供告警功能。它拥有强大的查询语言PromQL和 HTTP 接口也支持将数据导出到 Grafana 中展示是当前 Kubernetes 监控生态的核心组件。Prometheus 抓取配置详解使用 Prometheus 监控 Kubernetes 需要配置好数据源仓库提供了完整可用的示例 addons/prometheus.txt其核心抓取配置包含 6 类 jobprometheus抓取 Prometheus 自身指标localhost:9090用于自监控kubernetes-cluster通过kubernetes_sd_configs的服务发现role: apiserver抓取集群 apiserver 指标使用 service account 的 CA 证书与 bearer token 完成认证kubernetes-nodesrole: node发现所有节点通过relabel_configs将节点标签映射为 Prometheus 标签__meta_kubernetes_node_label_(.)kubernetes-service-endpointsrole: endpoint发现 Service Endpoint并通过注解prometheus.io/scrape: true决定是否抓取action: keep同时支持prometheus.io/scheme、prometheus.io/path、prometheus.io/port注解的覆盖这是为服务打注解即可接入监控的关键机制kubernetes-servicesrole: service且metrics_path: /probe将服务作为黑盒探测目标__param_target由 blackbox 组件执行 HTTP 探活kubernetes-podsrole: pod发现所有 Pod按 Pod 注解prometheus.io/scrape、prometheus.io/path、prometheus.io/port决定抓取方式并将命名空间、Pod 名写入标签。配套的 Deployment 清单 还展示了 Prometheus 容器的启动参数-config.file/etc/prometheus/prometheus.yml、-storage.local.path/prometheus、-storage.local.retention24h数据保留 24 小时并设置了 100m CPU / 100Mi 内存的 requests 与 500m CPU / 2500Mi 内存的 limits。使用 Helm 部署 Prometheus 与 Grafana推荐使用 Prometheus Operator 或 Prometheus Chart 来部署和管理 Prometheus# 使用 prometheus charts # 注意未开启 RBAC 时需要设置 --set rbac.createfalse helm install --name prometheus stable/prometheus --set rbac.createtrue --namespacemonitoring helm install --name grafana stable/grafana --namespacemonitoring --set server.imagegrafana/grafana:master仓库 manifests/prometheus/README.md 提供了另一种基于 Prometheus Operator 的部署方式helm repo add coreos https://s3-eu-west-1.amazonaws.com/coreos-charts/stable/ helm install coreos/prometheus-operator --name prometheus-operator --namespace monitoring helm install coreos/kube-prometheus --name kube-prometheus --namespace monitoring使用端口转发的方式访问 Prometheuskubectl port-forward -n monitoring service/prometheus-prometheus-server :80查询 Grafana 管理员密码kubectl get secret --namespace monitoring grafana -o jsonpath{.data.grafana-admin-password} | base64 --decode ; echo然后以端口转发方式访问 Grafana 界面kubectl port-forward -n monitoring service/grafana :80添加 Prometheus 类型的 Data Source填入原地址http://prometheus-prometheus-server.monitoring即可。Prometheus 常见问题排错exporter-kubelets 报 401 Unauthorized需要给 Kubelet 配置 webhook 认证kubelet --authentication-token-webhooktrue --authorization-modeWebhookK8SControllerManagerDown / K8SSchedulerDown 告警说明 kube-controller-manager 和 kube-scheduler 以 Pod 形式运行在集群中且 Prometheus 部署的监控服务与它们的标签不一致可通过修改服务标签解决kubectl -n kube-system set selector service kube-prometheus-exporter-kube-controller-manager componentkube-controller-manager kubectl -n kube-system set selector service kube-prometheus-exporter-kube-scheduler componentkube-scheduler使用 Prometheus Operator 时它不支持通过prometheus.io/scrape注解发现服务需要自行定义 ServiceMonitor 才会抓取服务度量数据。Node Problem Detector节点健康守护Kubernetes Node 有可能会出现各种硬件、内核或运行时问题这些问题可能导致服务异常。Node Problem DetectorNPD正是用来监测这类异常的守护服务。NPD 以 DaemonSet 方式运行在每台 Node 上在异常发生时更新 NodeCondition如 KernelDeadlock、DockerHung、BadDisk 等或发出 Node Event如 OOM Kill 等。仓库 manifests/node-problem-detector/npd.yaml 给出了可直接应用的部署清单从源码层面可以观察到其关键设计以DaemonSet形式部署kind: DaemonSet确保每台节点都运行一个实例启动命令同时加载 4 个系统日志监控配置kernel-monitor.json、kernel-monitor-filelog.json、docker-monitor.json、docker-monitor-filelog.json同时支持 journald 与 syslog 两种日志来源配置注释明确说明Pass both config to support both journald and syslog使用privileged: true特权模式与/var/loghostPath 挂载以便读取宿主机系统日志通过NODE_NAME环境变量spec.nodeNamefieldRef标识当前节点设置了CriticalAddonsOnly与NoExecute容忍保证作为关键插件稳定运行资源配额为 requests 20m CPU / 20Mi 内存limits 200m CPU / 100Mi 内存资源占用极小。部署方式kubectl apply -f manifests/node-problem-detector/npd.yaml或使用 Helm 部署仓库提供的另一方案# add repo helm repo add feisky https://feisky.xyz/kubernetes-charts helm update # install packages helm install feisky/node-problem-detector --namespace kube-system --name npdNPD 监测到的异常还会通过 journald 采集进入日志系统例如 manifests/fluentd-elasticsearch/fluentd-es-configmap.yaml 中就配置了对node-problem-detector.service日志的采集规则实现节点问题与日志平台的联动。其他容器监控与排错工具除上述监控系统外还有很多开源或商业系统可用于辅助监控包括 Sysdig、Weave Scope、Datadog、Sematext 等。sysdig容器排错利器sysdig 是一个容器排错工具提供开源和商业版本常规排错使用开源版本即可。除此之外还可搭配两个辅助工具csysdig与 sysdig 一起自动安装提供命令行界面sysdig-inspect为 sysdig 保存的跟踪文件如sudo sysdig -w filename.scap提供图形界面非实时。安装方式# on Linux curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash # on MacOS brew install sysdig常用示例# 查看单个容器的 Top 网络连接 sysdig -pc -c topconns # 显示与主机 192.168.0.1 交换的网络数据 sysdig -s2000 -A -c echo_fds fd.cip192.168.0.1 # 列出所有未由 apache 服务的入站连接 sysdig -p%proc.name %fd.name evt.typeaccept and proc.name!httpd # 查看容器内进程的 CPU/网络/IO 使用情况 sysdig -pc -c topprocs_cpu container.id2e854c4525b8 sysdig -pc -c topprocs_net container.id2e854c4525b8 sysdig -pc -c topfiles_bytes container.id2e854c4525b8 # 查看 apache 在哪些文件上花费最多的 I/O 时间 sysdig -c topfiles_time proc.namehttpd # 显示容器内执行的所有交互式命令 sysdig -pc -c spy_users # 显示每次打开 /etc 下文件的事件 sysdig evt.typeopen and fd.nameWeave Scope可视化拓扑监控Weave Scope 是另一款可视化容器监控和排错工具。与 sysdig 相比它没有强大的命令行工具但提供简单易用的交互界面自动描绘整个集群的拓扑并可通过插件扩展功能主要特性包括交互式拓扑界面、图形模式与表格模式、过滤功能、搜索功能、实时度量应用与容器、容器排错、插件扩展。Weave Scope 由 App 和 Probe 两部分组成Probe负责收集容器和宿主的信息并发送给 AppApp负责处理这些信息生成相应的报告并以交互界面形式展示。两者协作的拓扑如下--Docker host---------- --Docker host---------- .---------------. | --Container------ | | --Container------ | | Browser | | | | | | | | | |---------------| | | ----------- | | | | ----------- | | | |-----| | scope-app |-----. .-----| scope-app | | | | | | | ----------- | | \ / | | ----------- | | | | | | ^ | | \/ | | ^ | | --------------- | | | | | /\ | | | | | | | ------------- | | / \ | | ------------- | | | | | scope-probe |----- -----| scope-probe | | | | | ------------- | | | | ------------- | | | | | | | | | | | ----------------- | | ----------------- | ----------------------- -----------------------安装 Weave Scopekubectl apply -f https://cloud.weave.works/k8s/scope.yaml?k8s-version$(kubectl version | base64 | tr -d \n)k8s-service-typeLoadBalancer安装完成后可通过 weave-scope-app 服务访问交互界面kubectl -n weave get service weave-scope-app点击 Pod 还可以查看该 Pod 所有容器的实时状态和度量数据是日常巡检与问题定位的直观工具。小结一套完整的 Kubernetes 监控体系可以按采集—聚合—存储—展示—告警—排错分层落地节点层面由 Kubelet 内置的 cAdvisor 完成资源采集集群层面由 metrics-server 通过 Metrics API 向 HPA、Dashboard 等消费方供给核心度量长期存储与可视化交给 Prometheus Grafana或 InfluxDB Grafana节点自身健康由 Node Problem Detector 守护遇到具体容器问题时则借助 sysdig 的命令行能力与 Weave Scope 的可视化拓扑快速定位。仓库中 en/addons/monitor.md、setup/addon-list/monitor.md、setup/addon-list/metrics.md 以及 manifests/ 下的各类部署清单均可作为搭建与排错时的直接参考。赞分享云原生教程【免费下载链接】kubernetes-handbookKubernetes Handbook Kubernetes指南 https://kubernetes.feisky.xyz项目地址https://gitcode.com/gh_mirrors/kub/kubernetes-handbook点击查看免费下载相关推荐快速搭建Kubernetes集群监控系统基于Prometheus Operator的完整指南快速搭建Kubernetes集群监控系统基于Prometheus Operator的完整指南 想要为你的Kubernetes集群搭建一套专业的监控系统吗Cl柚坛工具箱NT完整上手指南从刷机小白到玩机老手的4个关键场景柚坛工具箱NT完整上手指南从刷机小白到玩机老手的4个关键场景 柚坛工具箱NT是一款面向 Android 与 OpenHarmony 设备的现代化一体化工具箱桌面应用开发工具智能硬件Ruffle Flash 模拟器扩展5 步安装6 项配置让老内容稳定播放Ruffle Flash 模拟器扩展5 步安装6 项配置让老内容稳定播放 Ruffle 是用 Rust 写的 Flash 模拟器浏览器扩展自动接管页面里的音视频语言运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考