云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载导读本文是 kube-prometheus 项目官方指南《Deploy to kubeadm》的完整技术解读与实践手册。它面向使用 kubeadm 自托管 Kubernetes 集群的用户说明如何调整控制面组件监听地址、暴露kube-controller-manager与kube-scheduler的指标端点并基于本仓库的manifests目录一步一步安装 Prometheus、Prometheus Operator、Alertmanager、node-exporter、kube-state-metrics 与 Grafana。读完本文你将掌握kubeadm 集群部署前需要做的控制面暴露配置、kube-prometheus 各监控数据源Metric Sources的采集原理、一条从零到可访问三套 UI 的完整安装命令链以及对应的仓库源码与配置文件佐证。一、为什么在 kubeadm 集群上监控需要额外配置kubeadm 是 Kubernetes 官方推荐的、用于部署与管理自托管集群的工具它会自动完成很多通用配置让用户快速获得一个可用的集群。但默认情况下kubeadm 存在两个与监控直接相关的限制kube-controller-manager与kube-scheduler以静态 Pod 形式运行在控制面节点上并且只监听127.0.0.1。这意味着它们暴露的/metrics端点无法被集群内其他命名空间的组件访问Prometheus 的 ServiceMonitor 也就无法抓取到数据。由于上述两个控制面组件无法被发现kube-prometheus 预置的控制面监控控制面告警规则、Grafana 控制面看板会处于无数据状态。因此在部署 kube-prometheus 之前必须先调整 kubeadm 集群把这些组件暴露给整个集群。关于 kubelet 与 cAdvisor在早期 Kubernetes 版本中还需要为控制面与所有节点上的 kubelet 修改 cAdvisor 监控相关配置由于 Kubernetes 的相应改动见 kubernetes/kubernetes issue #56523这一要求已不再需要无需再做额外处理。1.1 通过 kubeadm 配置文件在集群初始化前暴露控制面组件官方推荐的修改方式是在kubeadm init时使用 kubeadm 配置文件。核心思路是在ClusterConfiguration中给controllerManager与scheduler追加extraArgs把它们的bind-address从127.0.0.1改为0.0.0.0。原文档给出了一份完整的示例配置字段含义已补充apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration controlPlaneEndpoint: 192.168.1.173:6443 # 控制面对外暴露的稳定地址:端口 apiServer: extraArgs: authorization-mode: Node,RBAC # API Server 的鉴权模式Node RBAC 是推荐组合 controllerManager: extraArgs: bind-address: 0.0.0.0 # 关键让 controller-manager 监听所有网卡 scheduler: extraArgs: bind-address: 0.0.0.0 # 关键让 scheduler 监听所有网卡 certificatesDir: /etc/kubernetes/pki etcd: # one of local or external # 选择内嵌 etcd 或外部 etcd local: dataDir: /var/lib/etcd kubernetesVersion: v1.23.1 # 按实际使用的 Kubernetes 版本填写 networking: dnsDomain: cluster.local # 集群 DNS 域名 serviceSubnet: 10.96.0.0/12 # Service 网段 imageRepository: registry.k8s.io # 镜像仓库需要重点说明的参数scheduler.extraArgs.bind-address与controllerManager.extraArgs.bind-address这是本指南的核心。设置0.0.0.0后两个组件将不再只回环地址上提供/metrics端点而是对集群内所有地址可见kube-prometheus 的 ServiceMonitor 才能发现并抓取指标。apiServer.extraArgs.authorization-modeNode,RBAC是常见的推荐鉴权组合与监控抓取时使用的 ServiceAccount 令牌RBAC相配合。1.2 已存在的集群直接修改静态 Pod 清单如果你的 kubeadm 集群已经初始化完毕不需要重建集群只需在控制面节点上修改两个静态 Pod 清单把--bind-address127.0.0.1替换为--bind-address0.0.0.0sed -e s/- --bind-address127.0.0.1/- --bind-address0.0.0.0/ -i /etc/kubernetes/manifests/kube-controller-manager.yaml sed -e s/- --bind-address127.0.0.1/- --bind-address0.0.0.0/ -i /etc/kubernetes/manifests/kube-scheduler.yamlkubelet 会监听/etc/kubernetes/manifests目录并自动重建对应的静态 Pod无需手动重启控制面组件。修改完成后集群即满足 kube-prometheus 的控制面监控前提。1.3 控制面组件以 Pod 形式存在时的服务选择器校验原文档特别提醒如果你的 Kubernetes 核心组件是以kube-system 命名空间中的 Pod形式运行的请确保kube-prometheus-exporter-kube-scheduler与kube-prometheus-exporter-kube-controller-manager服务的spec.selector与这些 Pod 的标签一致否则 ServiceMonitor 通过 Service 发现目标时会匹配不到 Pod。从本仓库的控制面采集实现可以印证这一点。仓库把对控制面组件的发现定义为ServiceMonitor通过标签选择器与命名空间约束来匹配服务与 PodkubernetesControlPlane-serviceMonitorKubeScheduler.yamlselector.matchLabels为app.kubernetes.io/name: kube-schedulernamespaceSelector.matchNames为kube-system。kubernetesControlPlane-serviceMonitorKubeControllerManager.yamlselector.matchLabels为app.kubernetes.io/name: kube-controller-manager命名空间同样限定在kube-system。对应的 jsonnet 模板定义在 k8s-control-plane.libsonnetserviceMonitorKubeScheduler与 同文件 #L228-L279serviceMonitorKubeControllerManager。在serviceMonitorKubeScheduler中还可以看到两个抓取端点默认每 30s 抓取一次https-metrics端口另有一个每 5s 抓取/metrics/slisSLO 相关指标的端点均使用bearerTokenFile挂载的 ServiceAccount 令牌做鉴权、tlsConfig.insecureSkipVerify: true处理自签名证书。提示本项目针对 kind 的 e2e 测试也使用了同样的 kubeadm 补丁思路。见 tests/e2e/kind/config.yml通过kubeadmConfigPatches为controllerManager与scheduler设置extraArgs.bind-address: 0.0.0.0。这说明暴露控制面组件是 kube-prometheus 在 kubeadm 系集群上可被正常监控的必要条件。二、Metric Sourceskube-prometheus 监控哪些数据源Kubernetes 集群组件本身就是用 Prometheus 指标埋点instrumented的因此监控 Kubernetes 集群是 Prometheus 的自然选择——组件暴露指标后只需让 Prometheus 完成服务发现集群的大部分核心组件即可被覆盖。除了各组件自带的指标kube-prometheus 还引入两个补充数据源kube-state-metrics暴露的是集群状态而非单个组件的运行时指标例如 Deployment、ReplicaSet、Pod 等对象的期望状态与实际状态、资源配额等元数据是判断集群健康状态的关键数据源。node_exporter用于监控集群节点的资源使用情况包括 CPU、内存、磁盘利用率等是节点级监控的基础。完成本文的部署后你将监控到以下内容集群状态来自 kube-state-metrics节点资源来自 node_exporterkubeletapiserverkube-schedulerkube-controller-manager从仓库的 jsonnet 源码结构看这些数据源分别由components/目录下的组件模块生成kube-state-metricskube-state-metrics.libsonnetnode-exporternode-exporter.libsonnet控制面组件apiserver / kube-scheduler / kube-controller-manager / kubelet / CoreDNSk8s-control-plane.libsonnet其中serviceMonitorKubelet同文件 #L108-L226分别抓取/metricskubelet 自身指标、/metrics/cadvisorcAdvisor 容器指标、/metrics/probes探针指标与/metrics/slis四个端点apiserver 的 ServiceMonitor 则通过component: apiserver, provider: kubernetes标签在default命名空间发现 Kubernetes 内置的kubernetes服务同文件 #L281-L357。这些 jsonnet 模板在编译后落地为 manifests 目录下可直接kubectl apply的 YAML 文件例如 kubernetesControlPlane-serviceMonitorKubelet.yaml、kubernetesControlPlane-serviceMonitorApiserver.yaml、nodeExporter-serviceMonitor.yaml、kubeStateMetrics-serviceMonitor.yaml。三、快速安装 kube-prometheus 监控栈kube-prometheus 是一个开箱即用的监控方案集合它把 Prometheus Operator、Prometheus、Alertmanager、node-exporter、kube-state-metrics、Grafana 以及配套的 Dashboard 与告警规则统一打包成一组 manifests。本小节是快速安装流程不深入讲解每个组件的原理。下文命令均可在当前仓库根目录执行。3.1 克隆仓库并创建命名空间git clone https://github.com/prometheus-operator/kube-prometheus cd kube-prometheus/如果你已经在使用本仓库例如通过镜像站点git clone https://gitcode.com/gh_mirrors/ku/kube-prometheus可直接跳到创建命名空间步骤。首先创建监控套件要运行的命名空间可按需修改变量值export NAMESPACEmonitoring kubectl create namespace $NAMESPACE仓库预置的命名空间定义位于 manifests/setup/namespace.yaml其中带有pod-security.kubernetes.io/warn: privileged的 Pod Security 警告标签表示该命名空间内特权工作负载只会收到警告而不会被拦截。3.2 部署 Prometheus Operatorkubectl --namespace$NAMESPACE apply -f manifests/prometheus-operator该命令创建 Prometheus Operator 的全部组件。注意Custom Resource DefinitionsCRD在集群中就绪需要一小段时间可通过下面的循环等待alertmanagers.monitoring.coreos.com这个 CRD 出现后再继续后续步骤until kubectl --namespace$NAMESPACE get alertmanagers.monitoring.coreos.com /dev/null 21; do sleep 1; printf .; done当前仓库的 Prometheus Operator 版本为0.94.1见 jsonnet/kube-prometheus/versions.json。对应的 Operator 部署文件位于 manifests/prometheusOperator-deployment.yaml其需要的 RBACClusterRole / ClusterRoleBinding / ServiceAccount分别见 manifests/prometheusOperator-clusterRole.yaml 与 manifests/prometheusOperator-clusterRoleBinding.yaml。关于时序先创建 CRD 再创建 Operator是为了避免 Operator 在 CRD 尚未注册时启动失败。也可以一次性应用manifests/setup中的 CRD见 README Quickstart 的kubectl apply --server-side -f manifests/setup方式本快速安装流程采用的是文档原始的按序部署方式。3.3 部署 node-exporter 与 kube-state-metricskubectl --namespace$NAMESPACE apply -f manifests/node-exporter kubectl --namespace$NAMESPACE apply -f manifests/kube-state-metricsnode-exporter 以 DaemonSet 形式在每个节点上运行manifests/nodeExporter-daemonset.yaml仓库当前版本为1.12.1。kube-state-metrics 以 Deployment 形式运行manifests/kubeStateMetrics-deployment.yaml仓库当前版本为2.20.0。3.4 部署 Grafana 凭据与 Grafana 本体先应用 Grafana 的凭据。默认用户名/密码为admin/admin生产环境务必修改kubectl --namespace$NAMESPACE apply -f manifests/grafana/grafana-credentials.yaml然后安装 Grafana 本身kubectl --namespace$NAMESPACE apply -f manifests/grafana说明与补充在当前仓库中Grafana 相关配置已经整合到 manifests/grafana-config.yaml、manifests/grafana-dashboardDefinitions.yaml、manifests/grafana-dashboardDatasources.yaml 等文件中Grafana 当前版本为13.2.2见 versions.json。Grafana Deploymentmanifests/grafana-deployment.yaml通过env: []显式清空环境变量把 Grafana 的管理员凭据交给挂载的凭据文件管理数据源、Dashboard 则通过挂载到/etc/grafana/provisioning/datasources与/etc/grafana/provisioning/dashboards的 ConfigMap 进行 provisioning见该文件中的 volumeMounts 与 dashboard 定义挂载。凭据文件位于 manifests/grafana-dashboardDatasources.yaml 周边的配套 Secret 中quickstart 中的grafana-credentials.yaml对应本仓库 manifest 集合中的 Grafana Secret 资源。Grafana 的默认访问方式与admin/admin登录说明可参考 docs/access-ui.md。3.5 部署 Prometheus 本体及其 RBAC先部署 Prometheus 应用本身注意roles 与 role-bindings 要单独用全局方式应用因为它们作用于集群范围不应受命名空间限定find manifests/prometheus -type f ! -name prometheus-k8s-roles.yaml ! -name prometheus-k8s-role-bindings.yaml -exec kubectl --namespace $NAMESPACE apply -f {} \; kubectl apply -f manifests/prometheus/prometheus-k8s-roles.yaml kubectl apply -f manifests/prometheus/prometheus-k8s-role-bindings.yaml命令要点第一条find ... -exec找出manifests/prometheus目录下除 roles 和 role-bindings 之外的所有文件逐个在monitoring命名空间内应用其中包含核心的 Prometheus CR 对象 manifests/prometheus-prometheus.yaml。后两条不带--namespace参数因为 ClusterRole 与 ClusterRoleBinding 是集群级资源。Prometheus CR 关键字段manifests/prometheus-prometheus.yamlreplicas: 2默认双副本高可用部署alerting.alertmanagers指向monitoring命名空间下的alertmanager-main服务serviceAccountName: prometheus-k8s抓取时使用该 ServiceAccount 的令牌做 kubelet / API 鉴权securityContext.runAsNonRoot: true, runAsUser: 1000以非 root 用户运行。仓库当前 Prometheus 镜像版本为quay.io/prometheus/prometheus:v3.14.0。3.6 部署 Alertmanagerkubectl --namespace$NAMESPACE apply -f manifests/alertmanagerAlertmanager 部署完成后全套监控栈就绪。当前仓库中 Alertmanager 版本为0.34.1见 versions.json。其默认告警配置位于 manifests/alertmanager-secret.yaml包含resolve_timeout: 5m、基于namespace/alertname的抑制规则inhibit_rules、以及Default/Watchdog/Critical/null四个接收器receivers——其中Watchdog接收器用于验证告警链路存活null接收器用于丢弃InfoInhibitor类信息。3.7 验证安装并访问三套 UI所有 Pod 就绪后即可通过以下 NodePort 访问 UIPrometheus UI节点端口30900Alertmanager UI节点端口30903Grafana节点端口30902这些端口定义在 Service 清单中可以通过修改 Service 定义来变更。仓库中对应的端口映射定义在 jsonnet 的 node-ports 扩展里jsonnet/kube-prometheus/addons/node-ports.libsonnetPrometheus30900→9090、Alertmanager30903→9093、Grafana30902→3000。由于默认的 manifests/prometheus-service.yaml、manifests/alertmanager-service.yaml、manifests/grafana-service.yaml 均为 ClusterIP 类型NodePort 由 examples/jsonnet-snippets/node-ports.jsonnet 引入的 node-ports mixin 在定制编译时生成。如果不希望直接暴露 NodePort推荐使用kubectl port-forward临时访问详见 docs/access-ui.mdkubectl --namespace monitoring port-forward svc/prometheus-k8s 9090 kubectl --namespace monitoring port-forward svc/grafana 3000 kubectl --namespace monitoring port-forward svc/alertmanager-main 9093更多关于如何将这三套服务暴露给集群外用户的方案可参考仓库文档 docs/customizations/exposing-prometheus-alertmanager-grafana-ingress.mdIngress 方式与 docs/customizations/node-ports.mdNodePort mixin 使用方式。四、安装后的使用与验证建议4.1 访问 Prometheus 验证控制面指标kubeadm 集群完成上述安装后进入 Prometheus UI 的 /targets 页面应能看到以下 job 处于 UP 状态kube-controller-manager依赖前文第 1 节的bind-address调整否则该 target 无法抓取kube-scheduler同样依赖前文配置kubelet含/metrics/cadvisor端点抓取容器资源apiserver、kube-state-metrics、node-exporter等。这些 job 名称的来源可见于 jsonnet 的_config.mixin._configk8s-control-plane.libsonnet例如kubeSchedulerSelector: jobkube-scheduler、kubeControllerManagerSelector: jobkube-controller-manager——告警规则与 Dashboard 正是通过这些 selector 与抓取 job 关联。4.2 验证 Alertmanager 与告警规则进入 Alertmanager UI 可查看当前接收到的告警。仓库预置了大量告警与录制规则例如控制面告警保存在 manifests/kubernetesControlPlane-prometheusRule.yamlPrometheus 自身告警在 manifests/prometheus-prometheusRule.yaml节点与集群级告警来自 mixin源码见 jsonnet/kube-prometheus/components/mixin/alerts 与 jsonnet/kube-prometheus/components/mixin/rules。4.3 验证 Grafana Dashboard使用admin/admin务必在生产环境修改登录 Grafana 后仓库已通过 provisioning 预置了多套 Dashboard包括Kubernetes / API server、Kubernetes / Controller Manager、Kubernetes / Kubelet、Kubernetes / Nodes、Node Exporter、Cluster Total等完整的 dashboard 定义见 manifests/grafana-dashboardDefinitions.yaml对应的 volumeMount 挂载清单见 manifests/grafana-deployment.yaml。若Kubernetes / Controller Manager看板无数据请回到第 1 节检查bind-address配置是否生效。五、常见问题排查速查现象可能原因处理方式kube-controller-manager/kube-schedulertarget 处于 DOWN组件仍监听127.0.0.1或 Service selector 与静态 Pod 标签不匹配按第 1 节修改静态 Pod 清单或 kubeadm 配置校验 selectorCRD 未注册导致 Operator 异常应用顺序问题等待 CRD 就绪后再应用 Operator第 3.2 节的until循环Grafana 无法登录默认凭据被修改或未应用凭据文件检查grafana-credentials对应 Secret生产环境需主动改密NodePort 不可访问Service 类型仍为 ClusterIP使用 node-ports mixin 重新编译生成 NodePort Service或改用kubectl port-forward部分组件版本与预期不符仓库不同分支/发布版本镜像不同以 jsonnet/kube-prometheus/versions.json 与实际部署镜像为准更多排查思路可参考 docs/troubleshooting.md。结语在 kubeadm 集群上启用 kube-prometheus 的关键一步是让kube-controller-manager与kube-scheduler脱离127.0.0.1回环监听完成这一步后按本仓库 manifests 目录的顺序部署 Prometheus Operator、node-exporter、kube-state-metrics、Grafana、Prometheus 与 Alertmanager即可在 NodePort30900/30902/30903上获得完整的集群监控体验。无论是通过 kubeadm 配置文件在初始化前预设还是用sed修改已存在集群的静态 Pod 清单其目的都是让 kube-prometheus 的 ServiceMonitor 能够发现并抓取控制面指标——这也是本文所述流程与仓库源码k8s-control-plane.libsonnet、manifests相互印证的底层逻辑。赞分享云原生可观测性指标监控监控大盘告警【免费下载链接】kube-prometheusUse Prometheus to monitor Kubernetes and applications running on Kubernetes项目地址https://gitcode.com/gh_mirrors/ku/kube-prometheus点击查看免费下载相关推荐kubeasz 集成部署 Prometheus 监控栈kube-prometheus-stack 安装、验证与钉钉告警实战指南kubeasz 集成部署 Prometheus 监控栈kube prometheus stack 安装、验证与钉钉告警实战指南 prometheus 已经成为云原生集群管理运维Flan-T5-TSA-THoR应用场景10个实际案例展示目标情感分析Flan T5 TSA THoR应用场景10个实际案例展示目标情感分析 Flan T5 TSA THoR是一款基于Flan T5架构优化的目标情感分析模型能Prometheus Operator 完全指南在 Kubernetes 上原生部署与管理 Prometheus 监控栈Prometheus Operator 完全指南在 Kubernetes 上原生部署与管理 Prometheus 监控栈 导读 Prometheus Oper云原生可观测性上一篇gh_mirrors/webso/websocket-client 核心功能解析从连接到消息处理全攻略下一篇YOLOv10 × Roboflow 100RF100从下载到验证一文跑通多领域目标检测基准创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
