📊 K8S 监控三件套:Prometheus + AlertManager + Grafana 动手装之前,先用一张图确认三者关系与依赖 —— 结论:① Prometheus(核心:采集+TSDB 存储+告警规则评估)→ ② AlertManager(被动收告警,去重分组发通知)→ ③ Grafana(接数据源画图,随时可装);第 04 章 Prometheus Helm 实战已上线(装→验→Ingress 全开放),05~07 章持续补充

01一图看懂:三者关系与依赖 ⭐

装之前先搞清楚三件事:谁连谁、数据往哪流、谁离了谁不能工作。下面这张图就是三件套的全景 —— ①②③ 圈号即推荐安装顺序,箭头即数据流向:

图:监控三件套数据流与依赖全景 —— ①②③ = 推荐安装顺序;箭头 = 数据流向;蓝框 = 核心(一切的依赖根)

02先装哪一个?结论与理由

结论:Prometheus → AlertManager → Grafana

为什么 AlertManager 排第二,而不是第一?

有个看似反过来的理由:Prometheus 配置里要写 AlertManager 的地址,似乎该先把 AlertManager 建好?注意区分两件事:

• 依赖的本质是"谁离了谁不能工作":AlertManager 单独存在毫无意义(没告警可收),Grafana 单独存在毫无意义(没数据可画),而 Prometheus 单独存在完全可用。
• 没装 AlertManager 时,Prometheus 照常采集存储,只是告警发不出去(日志报 connection refused)—— 不影响核心功能。

03依赖矩阵与易混淆点 —— 数据流 ≠ 依赖方向

依赖矩阵:谁离了谁不能工作

数据流向 vs 依赖方向(最容易搞混的一张对比)

数据流向(运行时,数据怎么走)              依赖方向(部署时,谁必须先在)
─────────────────────────────            ─────────────────────────────
Target ←─ pull ── Prometheus             Prometheus(根,0 依赖)
Prometheus ── push ──► AlertManager              ├─► AlertManager(等它来推)
Prometheus ←─ query ── Grafana                   └─► Grafana(来查数据)
AlertManager ── webhook ──► 钉钉/邮件
                                          部署序 = 从根往下:① P → ② A → ③ G
推 push / 拉 pull 的主动方都是箭头尾         (数据流的主动方 ≠ 先装的一方!)

三个常见误区

04Prometheus 部署实战 —— Helm 一把梭(装→验→开放)

实战环境:测试集群 qingfeng 单节点(v1.35.9 · containerd),安装时间 2026-10-30 16:58,命令与输出均为真实记录,复制即可用。路线:用 Helm 单装 prometheus-community/prometheus(想三件套一键装齐见第 07 章)。

0. 动手前 30 秒检查(两条命令避大坑)

# ① 集群里是否已有三件套?(防与 Rancher monitoring 撞车 —— 有输出就要考虑复用而非重装)
kubectl get pods -A | grep -iE "prometheus|alertmanager|grafana|node-exporter"
# → 无任何输出 = 环境干净,可全新安装 ✅

# ② 默认存储类是谁?(决定 Prometheus 数据落在哪、能不能扩容)
kubectl get storageclass
NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  7d2h

1. 加仓库 + 裁剪 values(不裸装)

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

这个 chart 是"一父多子"结构:server(Prometheus 本体)、alertmanager、nodeExporter、pushgateway、kube-state-metrics,各自一个开关。按第 01 节的顺序,先只装 Prometheus 本体 + 采集端:

mkdir -p ~/monitor && cat > ~/monitor/prom-values.yaml <<'EOF'
## ============ Prometheus 本体 ============
server:
  enabled: true
  retention: "7d"                # 测试环境 7 天足够,生产 15d~30d
  persistentVolume:
    enabled: true
    size: 10Gi                   # local-path 不能扩容,一次给够
    # storageClass 不写 = 用默认 local-path
  resources:
    requests: {cpu: 200m, memory: 768Mi}
    limits:   {cpu: "1",  memory: 2Gi}
  service:
    type: ClusterIP              # 先 ClusterIP 验证,要域名见本章第 5 步 ingress 段

## ============ 周边组件按需裁剪 ============
alertmanager:
  enabled: false                 # ← 第二步再开(第 05 章)
nodeExporter:
  enabled: true                  # 节点指标,保留
pushgateway:
  enabled: false                 # 临时任务推送用,暂时不需要
EOF

2. 一键安装(真实输出)

helm install prometheus prometheus-community/prometheus \
  -n monitoring --create-namespace \
  -f ~/monitor/prom-values.yaml

NAME: prometheus
LAST DEPLOYED: Fri Oct 30 16:58:43 2026
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:
prometheus-server.monitoring.svc.cluster.local

Get the Prometheus server URL by running these commands in the same shell:
  export POD_NAME=$(kubectl get pods --namespace monitoring -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}")
  kubectl --namespace monitoring port-forward $POD_NAME 9090
...(NOTES 里还有 Pushgateway 一段,见下方误区)

• 记下这个 DNS 名:prometheus-server.monitoring.svc.cluster.local(端口 80)—— 以后 AlertManager/Grafana 对接、加数据源全靠它。
• ⚠️ NOTES 提到 Pushgateway,装没装要以 kubectl get svc/pods 为准(实测教训):NOTES 模板是无条件打印的,但本集群 get svc 里真的出现了 prometheus-prometheus-pushgateway —— 说明实际 values 漏写了 pushgateway.enabled: false(漏写 = 默认 true)。处理:values 补一段 pushgateway: {enabled: false} 再 helm upgrade,该组件即被移除。

3. 验证四连(装好了没有,以这四条为准)

# ① 实际装了哪些 Pod?预期 3 类:server / node-exporter / kube-state-metrics
#    (不该有 alertmanager 和 pushgateway —— values 关掉了)
kubectl get pods -n monitoring
# NAME                                                 READY   STATUS    RESTARTS   AGE
# prometheus-kube-state-metrics-xxxxx                  1/1     Running   0          2m   (示意,后缀以实际为准)
# prometheus-prometheus-node-exporter-xxxxx            1/1     Running   0          2m
# prometheus-server-xxxxxxx-xxxxx                      2/2     Running   0          2m   ← 2/2:主容器+config-reload

# ② Service 清单,记住 prometheus-server 这个名字(port 80 → 9090)
kubectl get svc -n monitoring

# ③ PVC:Pod Running 之后应为 Bound(起初 Pending 是 WaitForFirstConsumer 特性,正常)
kubectl get pvc -n monitoring

# ④ Helm 视角:release 状态与版本
helm list -n monitoring

4. 验收三关(9090 页面,命令行版同列)

先用 port-forward 把页面拉到本地(仅验证用,长期访问见第 6 步):

# 方式一:chart NOTES 推荐的(转发 Pod)
export POD_NAME=$(kubectl get pods -n monitoring -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME -n monitoring 9090
# Forwarding from 127.0.0.1:9090 -> 9090     ← 真实输出

# 方式二:转发 Service(更短,效果一样)
kubectl port-forward svc/prometheus-server -n monitoring 9090:80

在服务器的另一个窗口先用命令行过三关(不开浏览器也能验收):

# 关① 活性
curl -s http://localhost:9090/-/healthy
# 期望: Prometheus is Healthy.

# 关② Targets 健康(命令行版"看绿点")
curl -s http://localhost:9090/api/v1/targets | grep -o '"health":"[a-z]*"' | sort | uniq -c
# 期望: 若干 "health":"up"

# 关③ up 指标查询(命令行版 Graph 查询)
curl -s 'http://localhost:9090/api/v1/query?query=up' | head -c 600
# 期望: "value":[时间戳,"1"] 的若干条

5. 全开放:Ingress + 域名(长期姿势,复用站内 ingress 那套)

port-forward 一断就失效,还占终端。"全开放"= 照 站内 Ingress 文档同款链路加一条子域名规则,测试集群入口 31588 是现成的:

浏览器 http://prometheus.ergesanbaishou.com:31588/
   │ hosts 解析到节点 IP
   ▼
ingress-nginx-controller (NodePort 31588 ← ingress.yaml 里已固定的入口)
   │ 按 Host: prometheus.ergesanbaishou.com 匹配新 Ingress
   ▼
svc prometheus-server (monitoring ns, port 80)
   ▼
Pod :9090   ← 和 port-forward 看到的是同一个页面

不用手写 YAML,values 的 server.ingress 段打开即可(Helm 统一管理,卸载不残留):

# ~/monitor/prom-values.yaml 的 server: 段里追加(与 retention 等字段平级):
  ingress:
    enabled: true
    className: nginx                       # 对应 ingress-nginx
    annotations:
      nginx.ingress.kubernetes.io/ssl-redirect: "false"   # 先 HTTP,同 k8s-web 站
    hosts:
      - prometheus.ergesanbaishou.com      # ★ 新子域名
    path: /
    pathType: Prefix

# 生效
helm upgrade prometheus prometheus-community/prometheus -n monitoring -f ~/monitor/prom-values.yaml

# 确认 Ingress 已生成
kubectl get ingress -n monitoring
# NAME        CLASS   HOSTS                             ADDRESS   PORTS   AGE
# prometheus  nginx   prometheus.ergesanbaishou.com     节点IP     80      ...   (示意)

# 先在服务器上验证(不等 DNS,Host 头模拟 —— 和验证 k8s-web 的手法一模一样)
curl -s -H "Host: prometheus.ergesanbaishou.com" http://127.0.0.1:31588/-/healthy
# 期望: Prometheus is Healthy.   ← 通了 = Ingress→Service→Pod 全链路 OK

最后在 Windows 用管理员编辑 C:\Windows\System32\drivers\etc\hosts 加一行(IP 换成实际节点 IP),浏览器访问 http://prometheus.ergesanbaishou.com:31588/:

<节点IP>    prometheus.ergesanbaishou.com

5.5 入口方案对比:共享 31588 vs 独立 controller 30990 ⭐

高频疑问:Ingress 里为什么不写端口?31588 已被 k8s-web 用了怎么办?先纠正概念:Ingress 资源只有 host/path → Service 的映射,没有入口端口参数(设计使然),端口属于 controller 的 Service —— 31588 被多域名共享按 Host 分流本不算冲突。但本集群有更优雅的先例:harbor 单独装了一套 controller(入口 32588);照抄该模式给 Prometheus 配专属 controller + 独立端口 30990,端口与规则全隔离,还不丢 Ingress 层能力:

# ① 先加仓库(★本机第一次用 ingress-nginx 仓库必须这步!)
#    repo 是"按机器"记的:装 Prometheus 时加的 prometheus-community 不通用;
#    漏了这步 = Error: repo ingress-nginx not found(实测踩坑,已登记第 8 节坑速查)
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm repo list     # 期望看到 ingress-nginx + prometheus-community 两行

# ② 装第三套 ingress-nginx:专属 class=prometheus-nginx,HTTP 固定 30990(同 harbor 32588 模式)
helm upgrade --install ingress-prometheus-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx \
  --set controller.ingressClassResource.name=prometheus-nginx \
  --set controller.ingressClassResource.controllerValue=k8s.io/ingress-prometheus-nginx \
  --set controller.ingressClassResource.default=false \
  --set controller.service.type=NodePort \
  --set controller.service.nodePorts.http=30990 \
  --set controller.service.nodePorts.https=30490 \
  --set controller.admissionWebhooks.enabled=false \
  --set controller.replicaCount=1
# 三个关键参数:
#   ingressClassResource.name → 只认领 class=prometheus-nginx 的 Ingress,不与共享款(nginx)抢
#   nodePorts.http=30990      → 专属入口;https 顺手固定 30490,以后上证书直接用
#   admissionWebhooks=false   → 新 controller 不装"安检门"(webhook),避开多实例抢校验
#                               的经典坑(那两个 443 svc 是什么 → 见下方 5.6 全景表)

# ③ 等新 controller 就绪(单节点约 30s)
kubectl -n ingress-nginx get pods,svc | grep prometheus
# 期望: pod Running;svc ingress-prometheus-nginx-controller → 80:30990/TCP,443:30490/TCP

# ④ Ingress 切到新 class —— ★前提:服务器上的 yaml 已是新版!(仓库双 clone 实测坑:
#    apply 了旧版 class=nginx,controller 装好了 30990 也死活不通 —— 规则还挂在共享款上)
grep ingressClassName prometheus-ingress.yaml
# 期望输出: prometheus-nginx;若还是 nginx → git pull 或 vim 手动改这一行
kubectl apply -f prometheus-ingress.yaml          # ★ apply 的是 .yaml,不是 .conf!(见下表)
kubectl -n monitoring get ingress prometheus-ingress
# CLASS 列: nginx → prometheus-nginx;换 class = 规则"搬家",31588 上随之失效

# ⑤ 验证专属入口 + 佐证搬家
curl -s -H "Host: prometheus.ergesanbaishou.com" http://10.18.170.34:30990/-/healthy
# 期望: Prometheus is Healthy.
curl -s -H "Host: prometheus.ergesanbaishou.com" -o /dev/null -w '%{http_code}\n' http://10.18.170.34:31588/
# 期望: 404(共享款已不管这个 Host —— 是佐证不是故障)

两个配套文件分工(实测坑:kubectl apply -f prometheus-nginx.conf 报 invalid object to validate —— .conf 根本不是 K8S 资源):

5.6 番外:ingress-nginx 命名空间的 5 个 Service 全景(那两个 443 是什么?)

kubectl -n ingress-nginx get svc 装完第三套后会看到 5 个 Service,高频疑问:"下面两个 443 的没开放端口,nginx 是怎么指定的?" —— 答案:它们不是流量入口,是 admission webhook(准入校验"安检门"),只被 API Server 在 kubectl apply Ingress 的那一瞬间集群内部调用(校验注解/snippet 语法对不对),通过即退场,与业务流量零关系,所以 ClusterIP 足够、没 NodePort 属正常:

一句话:认业务入口只看带 80:xxxxx 的 controller Service;443 的 ClusterIP 是"安检门"。这也正是 5.5 节新 controller 关 admissionWebhooks.enabled=false 的原因 —— 三扇"安检门"会抢校验(多 controller 共存的经典坑)。验证某扇门背后挂谁:

kubectl -n ingress-nginx get svc ingress-nginx-ergesanbaishou -o yaml | grep -A3 selector
kubectl get validatingwebhookconfigurations        # 看集群里有几扇"安检门"

6. 可选加固:basic auth(全开放的代价是裸奔,顺手加把锁)

# ① 生成密码文件并建 Secret(服务器没 htpasswd 就用 openssl,密码自己定)
printf "admin:$(openssl passwd -apr1 '你的密码')\n" > ~/monitor/auth
kubectl create secret generic prom-basic-auth --from-file=~/monitor/auth -n monitoring

# ② values 的 ingress.annotations 追加三行:
#      nginx.ingress.kubernetes.io/auth-type: basic
#      nginx.ingress.kubernetes.io/auth-secret: prom-basic-auth
#      nginx.ingress.kubernetes.io/auth-realm: "Prometheus Login"

# ③ 再 upgrade 一次,浏览器会弹登录框
helm upgrade prometheus prometheus-community/prometheus -n monitoring -f ~/monitor/prom-values.yaml

7. 日常运维四连(Helm 管的组件就这四条)

helm list -n monitoring                 # 装了什么、什么版本
helm history prometheus -n monitoring   # 改过几次(revision)
helm upgrade prometheus prometheus-community/prometheus -n monitoring -f ~/monitor/prom-values.yaml  # 一切变更走这里
helm rollback prometheus 1 -n monitoring  # 改坏了回第 1 版

# 卸载(注意:PVC/PV 不会被删,数据还在;重装同名 release 若 PVC 未删会沿用或报错,按需清理)
helm uninstall prometheus -n monitoring
kubectl delete pvc -n monitoring -l app.kubernetes.io/instance=prometheus

8. 坑速查(本章可能遇到)

05AlertManager 部署与对接 · 大纲 · 补充中

本章将覆盖:

1. ConfigMap:route 分组/抑制/静默 + receivers(钉钉 webhook / 企业微信 / 邮件 SMTP)
2. Deployment + Service(9093);与 Prometheus 的 alerting.alertmanagers 对接
3. 触发测试:一条必触发的规则走完全链路,钉钉群里见到消息才算通
4. 静默(silence)实操:变更窗口压制告警,避免发布期间噪音

06Grafana 部署与看板 · 大纲 · 补充中

本章将覆盖:

1. Deployment + PVC(dashboard/配置持久化)+ Service(3000),经 Ingress 暴露(复用站内证书文档)
2. 添加 Prometheus 数据源(ClusterDNS 直连,不走外网)
3. 导入社区看板 315 / 8588 / 1860,变量与时间窗使用
4. 告警面板与 OOM 类事故的关键指标图(内存 limit vs usage 一眼对比)

07生产建议:kube-prometheus-stack 一键全家桶 · 大纲 · 补充中

生产环境更推荐 Helm 一个 Chart 装齐(三件套 + Operator + 采集端),本章将覆盖:

1. helm repo / install 三条命令;monitoring 命名空间
2. 为什么多了 Prometheus Operator:ServiceMonitor / PodMonitor / PrometheusRule 声明式管理,告别手改 prometheus.yml
3. values 定制:持久化与保留期、告警接收器、Ingress 域名、资源配额
4. 与手动部署的取舍:学习原理用手动,稳定生产用 Stack