在k8s中部署Prometheus并实现对k8s集群的监控

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

1. 架构概述与组件说明

在开始部署之前，了解你将安装的组件有助于后续的运维和排查。kube-prometheus-stack 并不是一个单一的软件，而是一个集成了以下核心组件的技术栈：

• Prometheus Operator：作为 Kubernetes 的控制器，它监听 ServiceMonitor、PodMonitor 和 Prometheus 等自定义资源（CRD），自动生成并管理 Prometheus 的配置文件，让你无需手动修改复杂配置。

• Prometheus Server：实际的监控核心，负责拉取（Pull）指标数据并存储到时序数据库中。

• Grafana：可视化层，提供预置的仪表盘用于展示集群、节点、Pod 的各项指标。

• Alertmanager：负责处理告警，支持将告警路由到钉钉、邮件或 Slack 等接收端。

• Exporter 集合：

  • node-exporter：采集所有集群节点的硬件和操作系统指标（CPU、内存、磁盘等）。

  • kube-state-metrics：通过监听 Kubernetes API 生成关于集群对象状态（如 Pod 数量、Deployment 状态等）的指标。

2. 环境准备

在开始部署前，请确保以下基础环境已就绪：

3. 部署 kube-prometheus-stack

3.1 添加 Helm 仓库

首先，添加 Prometheus 社区的官方 Helm 仓库并更新本地缓存：

bash

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

3.2 创建命名空间

为了便于管理，通常将监控组件安装在独立的 monitoring 命名空间中：

bash

kubectl create namespace monitoring

3.3 安装监控栈

执行以下命令进行安装。这里我们先使用默认配置进行快速部署，稍后会介绍如何自定义配置：

bash

helm install prometheus prometheus-community/kube-prometheus-stack \\
–namespace monitoring \\
–set grafana.adminPassword=admin123 # 设置 Grafana 管理员密码

注：kube-prometheus-stack 默认会配置持久化存储请求，如果你的集群没有默认的 StorageClass，安装可能会卡在 Pending 状态。建议在生产环境提前配置存储类，测试环境可暂时不配置持久化（通过 –set prometheus.prometheusSpec.storageSpec=null 禁用）。

3.4 验证安装

检查 Pod 是否正常运行：

bash

kubectl get pods -n monitoring

你应当看到类似以下的 Pod 列表：

• prometheus-prometheus-kube-prometheus-prometheus-0 (Prometheus)

• alertmanager-prometheus-kube-prometheus-alertmanager-0 (Alertmanager)

• prometheus-grafana-xxxxx (Grafana)

• prometheus-kube-state-metrics-xxxxx

• prometheus-prometheus-node-exporter-xxxxx (在每个节点上运行)

4. 访问监控面板

安装完成后，你需要通过端口转发或暴露服务来访问 Prometheus 和 Grafana 的 UI。

4.1 访问 Prometheus UI

使用 port-forward 将 Prometheus 服务映射到本地 9090 端口：

bash

kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090

打开浏览器访问 http://localhost:9090。在导航栏点击 Status -> Targets，如果所有 Endpoint 状态都是 UP，说明采集任务配置成功。

4.2 访问 Grafana 仪表盘

映射 Grafana 服务到本地 3000 端口：

bash

kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80

在浏览器中访问 http://localhost:3000，输入用户名 admin 和之前设置的密码（如未设置，可通过以下命令获取默认密码）：

bash

kubectl get secret -n monitoring prometheus-grafana -o jsonpath="{.data.admin-password}" | base64 –decode ; echo

登录后，Grafana 默认预置了多个针对 Kubernetes 监控的仪表盘（如 Kubernetes / Compute Resources / Cluster），你可以直接查看集群的 CPU、内存、网络等核心指标。

5. 自定义配置：扩展监控目标

默认配置已经可以监控集群的核心组件（如 API Server、kubelet、容器资源等）。如果你需要监控自定义应用或修改抓取间隔，可以通过自定义 values.yaml 文件来实现。

5.1 创建自定义 values.yaml

导出默认配置作为模板：

bash

helm show values prometheus-community/kube-prometheus-stack > custom-values.yaml

5.2 配置 ServiceMonitor 抓取自定义应用

假设你有一个应用暴露了 /metrics 接口，你可以通过 additionalServiceMonitors 来定义抓取规则。

在 custom-values.yaml 中添加以下内容：

yaml

prometheus:
additionalServiceMonitors:
– name: my-app-monitor
selector:
matchLabels:
app: my-app # 你的应用 Service 的标签
namespaceSelector:
matchNames:
– default # 你的应用所在的命名空间
endpoints:
– port: metrics # Service 定义的端口名称
interval: 30s
path: /metrics

更新部署：

bash

helm upgrade prometheus prometheus-community/kube-prometheus-stack \\
-f custom-values.yaml \\
–namespace monitoring

5.3 基于 Pod 注解的自动发现

如果你不想为每个应用单独创建 ServiceMonitor，也可以配置 Prometheus 自动发现带有特定注解的 Pod。

确保在 values.yaml 中启用了 Pod 监控，并在目标 Pod 上添加注解：

yaml

metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/path: "/metrics"
prometheus.io/port: "8080"

这种模式下，Prometheus 会自动抓取该 Pod 的指标。

6. 配置告警规则与通知

6.1 添加自定义告警规则

告警规则通过 PrometheusRule CRD 来定义。在 custom-values.yaml 中添加新的告警规则组：

yaml

additionalPrometheusRules:
– name: my-cpu-alerts
groups:
– name: cpu.rules
rules:
– alert: HighCPUUsage
expr: sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod) > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage detected"
description: "Pod {{ $labels.pod }} is using >80% CPU."

应用更新后，可以在 Prometheus UI 的 Alerts 页面看到新规则。

6.2 配置 Alertmanager 发送通知（钉钉示例）

kube-prometheus-stack 支持配置多种接收器。如果需要配置钉钉机器人告警，通常需要借助 prometheus-webhook-dingtalk 组件或使用内置的 receivers 配置。

在 values.yaml 中配置 Alertmanager 部分：

yaml

alertmanager:
config:
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'webhook'
receivers:
– name: 'webhook'
webhook_configs:
– url: 'https://oapi.dingtalk.com/robot/send?access_token=xxxxx' # 钉钉机器人地址
send_resolved: true

注意：钉钉自定义机器人的配置可能会根据版本更新有所变化，建议参考具体版本的文档。

7. 数据持久化

默认情况下，Prometheus 会请求一个 10Gi 的 PVC。如果需要修改存储大小或存储类，可在 custom-values.yaml 中配置：

yaml

prometheus:
prometheusSpec:
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: "fast-ssd" # 指定存储类
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 50Gi # 扩容到 50G

同样，Grafana 的数据持久化也可以单独配置。

8. 故障排查

如果发现监控数据缺失或组件启动异常，可以按以下步骤排查：

9. 深入 ServiceMonitor 与 PodMonitor

在 kube-prometheus-stack 中，Prometheus Operator 通过监听 ServiceMonitor 和 PodMonitor 两种 CRD 来动态生成 Prometheus 的 scrape_configs。

9.1 ServiceMonitor 详解

ServiceMonitor 通过关联 Kubernetes Service 来发现后端 Pod，推荐用于有稳定 Service 的应用。其结构如下：

yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: example-app
namespace: monitoring # 通常放在监控命名空间
spec:
selector:
matchLabels:
app: example-app # 匹配 Service 的标签
namespaceSelector:
matchNames:
– default # Service 所在的命名空间
endpoints:
– port: metrics # Service 中定义的端口名称
interval: 30s
path: /metrics
scheme: http
tlsConfig: {} # 如需 HTTPS，配置证书
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token # 如果需要认证

关键点：

• selector 和 namespaceSelector 共同决定了哪些 Service 被纳入监控。

• 如果服务是集群内访问，Prometheus 会通过 Service 的 ClusterIP 抓取；如果服务是 Headless，则会直接解析为 Pod IP，更适合抓取 DaemonSet 等。

• 对于需要额外认证的 endpoint，可以在 endpoints 中配置 basicAuth、bearerToken 等。

9.2 PodMonitor 详解

PodMonitor 直接基于 Pod 的标签选择 Pod，不依赖 Service，适用于那些没有 Service 但暴露了 metrics 端点的 Pod（如一些批处理任务）。

yaml

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: example-podmonitor
namespace: monitoring
spec:
selector:
matchLabels:
app: example-app
namespaceSelector:
any: true # 监控所有命名空间
podMetricsEndpoints:
– port: metrics
interval: 30s
path: /metrics

注意：podMetricsEndpoints 中的 port 可以是容器端口的名称，也可以是数字端口。

9.3 常见问题与调试

• Target 显示为 DOWN：常见原因包括网络策略阻止、Service 端口不匹配、Pod 未暴露指标端点。检查 Service 的端口名称是否正确，以及 Pod 是否在 /metrics 路径上返回数据。

• 发现目标但无数据：可能是指标路径错误，或指标格式不符合 Prometheus 规范。可以通过 kubectl port-forward 直接访问 Pod 的 /metrics 端点来验证。

• 如何让 Prometheus 抓取所有 Pod 的 metrics：可以创建全局的 PodMonitor，例如使用 any: true 和标签选择器 {}，但这可能导致大量抓取，需谨慎。

10. Kubernetes 核心组件监控指标解读

kube-prometheus-stack 默认配置已经抓取了 Kubernetes 各核心组件的指标。了解这些指标可以帮助你更好地设置告警和仪表盘。

10.1 控制平面组件

API Server

• 请求延迟：apiserver_request_duration_seconds，观察 99 分位数（P99）是否超过阈值（如 1s）。

• 请求错误率：apiserver_request_total{code=~"5.."} 统计 5xx 错误。

• etcd 延迟：apiserver_storage_* 相关的指标反映了 etcd 的响应时间。

etcd

• 领导者选举：etcd_server_is_leader 确保只有一个 leader。

• 磁盘同步延迟：etcd_disk_backend_commit_duration_seconds，过高可能影响集群稳定性。

• 数据库大小：etcd_debugging_mvcc_db_total_size_in_bytes，超过配额（默认 2GB）可能导致集群只读。

Controller Manager & Scheduler

• 工作队列深度：workqueue_depth，反映组件是否积压任务。

• leader 选举状态：leader_election_master_status 帮助判断哪个实例是 leader。

10.2 节点（kubelet）与容器运行时

• 节点资源：node_cpu_seconds_total、node_memory_MemAvailable_bytes、node_filesystem_avail_bytes 等由 node-exporter 采集。

• 容器资源：container_cpu_usage_seconds_total、container_memory_working_set_bytes 由 kubelet 暴露的 cAdvisor 指标提供。注意区分 container_memory_usage_bytes 和 container_memory_working_set_bytes，后者更接近实际使用内存。

• Pod 重启：kube_pod_container_status_restarts_total（由 kube-state-metrics 提供）。

10.3 集群状态（kube-state-metrics）

kube-state-metrics 不直接采集 Pod 内部指标，而是通过监听 Kubernetes API 提供对象的状态指标，例如：

• kube_deployment_status_replicas_available：可用副本数。

• kube_node_status_condition：节点状态（Ready、MemoryPressure 等）。

• kube_persistentvolumeclaim_status_phase：PVC 状态。

这些指标对于集群运维非常重要，例如监控 Pod 处于 Pending 或 CrashLoopBackOff 状态。

11. 高级告警规则配置

除了默认的告警规则，你可能需要根据业务场景自定义更精细的告警。

11.1 节点 CPU 使用率告警（基于 node-exporter）

yaml

– alert: NodeHighCPUUsage
expr: (100 – (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 10m
labels:
severity: warning
annotations:
summary: "Node high CPU usage"
description: "Node {{ $labels.instance }} has CPU usage above 80% (current: {{ $value }}%)"

11.2 Pod 频繁重启告警

yaml

– alert: PodFrequentlyRestarting
expr: increase(kube_pod_container_status_restarts_total[1h]) > 5
for: 5m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is restarting frequently"
description: "Container {{ $labels.container }} has restarted {{ $value }} times in the last hour"

11.3 PVC 容量即将用满

yaml

– alert: PVCUsageHigh
expr: (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) * 100 > 85
for: 5m
labels:
severity: warning
annotations:
summary: "PVC {{ $labels.namespace }}/{{ $labels.persistentvolumeclaim }} is almost full"

11.4 使用 Alertmanager 路由与抑制

Alertmanager 支持复杂的路由规则和告警抑制。例如，可以配置当节点不可达时，抑制该节点上所有 Pod 的告警，避免告警风暴。

在 alertmanager.config 中添加：

yaml

route:
group_by: ['alertname', 'cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'default-receiver'
routes:
– match:
severity: critical
receiver: 'critical'
continue: true
– match:
alertname: 'NodeDown'
receiver: 'node-down'
# 抑制规则
inhibit_rules:
– source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['instance'] # 相同 instance 的告警将被抑制

12. 高可用与远程存储

当集群规模较大或需要长期存储时，单一 Prometheus 实例可能成为瓶颈，且数据有丢失风险。

12.1 Prometheus 高可用

通过 kube-prometheus-stack 可以部署多个 Prometheus 实例，它们共享同一份配置，独立抓取数据，但彼此不感知。这种架构通常配合 Thanos 或 Cortex 实现全局视图和长期存储。

启用多副本（例如 2 个副本）：

yaml

prometheus:
prometheusSpec:
replicas: 2
retention: 30d
retentionSize: 50GB

12.2 Alertmanager 高可用

Alertmanager 支持通过 Gossip 协议组成集群，避免单点故障。在 values.yaml 中设置：

yaml

alertmanager:
alertmanagerSpec:
replicas: 3
externalUrl: http://alertmanager.example.com

12.3 远程存储（Remote Write）

Prometheus 支持将数据写入远程存储（如 Thanos、Cortex、Mimir、VictoriaMetrics 等）。配置 remote write：

yaml

prometheus:
prometheusSpec:
remoteWrite:
– url: http://thanos-receive:19291/api/v1/receive
queueConfig:
capacity: 2500
maxShards: 200
writeRelabelConfigs: []

12.4 使用 Thanos 实现全局查询和长期存储

Thanos 可以聚合多个 Prometheus 实例的数据，并提供长期存储（通过对象存储）。部署 Thanos 通常包括：

• Sidecar：在每个 Prometheus Pod 中运行，将数据上传到对象存储（如 S3、MinIO）。

• Query：统一查询入口。

• Store Gateway：从对象存储查询历史数据。

• Compactor：对数据进行压缩和降采样。

kube-prometheus-stack 可以与 Thanos 集成，参考社区提供的 thanos 子 Chart 或单独部署。

13. 性能调优

在生产环境中，需要对 Prometheus 的资源、抓取策略进行优化。

13.1 内存与 CPU 配置

Prometheus 的内存消耗主要与活跃的时间序列数量、抓取间隔、存储时间有关。一个经验公式：每个活跃时间序列大约消耗 1-2KB 内存。Kubernetes 集群中，默认抓取任务可能产生数万个时间序列，内存需求可能达到几 GB。

根据集群规模调整：

yaml

prometheus:
prometheusSpec:
resources:
requests:
memory: 8Gi
cpu: 2
limits:
memory: 16Gi
cpu: 4

13.2 调整抓取间隔和超时

全局抓取间隔默认 30 秒，对于某些高频变化指标可调整为 15 秒，但会增加资源消耗。可在 values.yaml 中修改：

yaml

prometheus:
prometheusSpec:
scrapeInterval: 30s
evaluationInterval: 30s

对于单个 ServiceMonitor，可以覆盖间隔：

yaml

endpoints:
– interval: 15s

13.3 限制时间序列数量

通过 metric relabeling 可以丢弃不需要的标签，减少时间序列数量。例如，丢弃某些高基数的标签（如 Pod IP）：

yaml

prometheus:
prometheusSpec:
additionalScrapeConfigs:
– job_name: 'kubernetes-pods'
kubernetes_sd_configs: […]
relabel_configs:
– action: labeldrop
regex: "pod_ip"

或者在 ServiceMonitor 级别配置。

13.4 存储保留策略

设置数据保留时间（默认 10 天）和容量限制：

yaml

prometheus:
prometheusSpec:
retention: 15d
retentionSize: 100GB # 超出此大小将自动删除旧数据

14. 监控集群外部资源

虽然 kube-prometheus-stack 主要面向 Kubernetes 内部，但也可以监控集群外部的服务（如数据库、外部 API）。方法如下：

14.1 使用 ExternalName Service 或 Endpoint

创建一个不带选择器的 Service，并手动创建 Endpoints 指向外部 IP：

yaml

apiVersion: v1
kind: Service
metadata:
name: external-mysql
namespace: monitoring
spec:
ports:
– name: metrics
port: 9104
targetPort: 9104
—
apiVersion: v1
kind: Endpoints
metadata:
name: external-mysql
namespace: monitoring
subsets:
– addresses:
– ip: 192.168.1.100
ports:
– name: metrics
port: 9104

然后创建 ServiceMonitor 选择这个 Service。

14.2 直接使用 ScrapeConfig（Prometheus v2.49+）

新版 Prometheus 支持 ScrapeConfig CRD（需要启用），可以直接定义静态抓取目标。

15. 安全加固

默认部署中，Prometheus 和 Grafana 没有配置身份验证，且 Service 可能暴露在集群内部。以下措施可以提升安全性：

15.1 使用 Ingress 并启用 Basic Auth

对于 Prometheus 和 Grafana 的 Web UI，建议通过 Ingress 暴露，并添加 Basic Auth。可以使用 nginx-ingress 的 auth 功能或 oauth2-proxy。

15.2 网络策略

限制只有 Prometheus 才能访问 exporter 的端口。例如，限制 kubelet 的 metrics 端口只允许 Prometheus 访问。

15.3 RBAC 最小权限

确保 Prometheus 的 ServiceAccount 仅具有必要的 RBAC 权限（kube-prometheus-stack 默认创建了合适的权限，无需额外修改）。

15.4 启用 TLS

对于抓取任务，可以配置 HTTPS 和证书验证。例如，对于 kubelet，默认证书可能不通过验证，可以配置 insecureSkipVerify: true 或提供 CA 证书。

在 values.yaml 中：

yaml

prometheus:
prometheusSpec:
tlsConfig:
caFile: /etc/prometheus/secrets/ca.crt

16. 备份与恢复

Prometheus 的数据是本地存储的，如果 Pod 被删除且没有持久化，数据将丢失。因此，需要定期备份数据或依赖远程存储。

16.1 使用 PVC 快照

如果使用支持快照的存储类（如云厂商的 CSI），可以定期创建 PVC 快照。

16.2 使用 Thanos 或远程存储

如前所述，使用远程存储可以避免数据丢失。

16.3 手动备份数据

可以通过 kubectl exec 进入 Prometheus Pod，打包 /prometheus 目录并保存到外部存储。

17. 升级与维护

17.1 升级 kube-prometheus-stack

查看可用的 Chart 版本：

bash

helm search repo prometheus-community/kube-prometheus-stack –versions

升级前最好备份 values 和重要数据：

bash

helm upgrade prometheus prometheus-community/kube-prometheus-stack \\
-f custom-values.yaml \\
–namespace monitoring \\
–version <new-version>

17.2 处理 CRD 升级

Chart 可能会引入新的 CRD，通常需要手动安装或升级 CRD。Helm 不会自动管理 CRD，需提前执行：

bash

kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml

17.3 滚动升级注意事项

• 如果 Prometheus 使用多副本，升级 Operator 时 Prometheus 实例可能会重启，但数据不会丢失。

• Grafana 升级后可能需要对仪表盘进行迁移（通常会自动迁移）。

18. 常见错误与解决方案

19. 监控扩展：日志与链路追踪

完整的可观测性方案除了指标（Metrics）外，还应包括日志（Logging）和链路追踪（Tracing）。

19.1 集成 Loki 实现日志聚合

Loki 是 Grafana 推出的轻量级日志系统，可以与 Grafana 无缝集成。通过 Helm 部署 Loki：

bash

helm repo add grafana https://grafana.github.io/helm-charts
helm upgrade –install loki grafana/loki-stack –namespace monitoring

然后配置 Grafana 添加 Loki 数据源，即可在 Grafana 中查看与指标关联的日志。

19.2 集成 Tempo 或 Jaeger 实现链路追踪

Tempo 也是 Grafana 推出的追踪系统，支持 OpenTelemetry 协议。部署 Tempo 后，可在应用注入 SDK，将追踪数据发送到 Tempo，并在 Grafana 中查看。