前言

经过上次周的迁移，我们已经把业务完整跑在标准 K8s 集群上。但目前集群属于黑盒状态：Pod 重启不知道、CPU 飙高看不到、日志散落在各个节点、故障只能瞎猜。

对于生产 K8s 集群，没有可观测 = 裸奔上线。这周从零搭建一套 2026 年生产标准、轻量化、高可用、可落地的 K8s 可观测体系：指标监控（Prometheus+Thanos）、可视化（Grafana）、日志系统（Loki+Promtail）、告警体系全覆盖。全程生产可用，所有 YAML、命令可直接复制，踩坑部分附带现象、根因、详细解决步骤 + 完整代码。

一、为什么不使用传统单机监控？

很多新手搭建监控还在用单 Prometheus、ELK，在大规模 K8s 集群完全不适用：

1. 单 Prometheus 数据丢点、无法持久化、宕机监控直接断档
2. ELK 资源消耗极高，集群大了日志存储爆炸
3. 没有统一采集，组件杂乱、维护成本极高
4. 无法区分节点、Pod、Namespace 维度数据，排查问题极慢

2026 云原生标准可观测架构：OpenTelemetry 统一采集 + Prometheus+Thanos 指标高可用 + Loki 轻量日志 + Grafana 统一展示 + 分级告警

特点：

• 比 ELK 节省 70% 资源
• 支持指标长期存储、多集群聚合
• 支持容器、节点、内核级观测
• 日志、指标联动排障

二、整体架构介绍

分层架构

1. 采集层

• Promtail：采集所有容器日志、节点日志
• OTel Collector：统一采集指标、事件、链路
• K8s 自动服务发现，无需手动加监控项

1. 存储层

• Prometheus：实时短期指标存储
• Thanos：指标去重、压缩、长期存储、高可用查询
• Loki：轻量日志存储，只索引标签，不索引全文

1. 展示告警层

• Grafana：统一大盘、多维度视图
• Alertmanager：分级告警、告警收敛、防止轰炸

三、前置环境准备

• 标准 K8s 1.28+ 集群
• Helm3 最新版
• 集群正常 StorageClass、可正常创建 PVC
• 集群可访问外网拉取镜像
• 已准备 MinIO/S3 对象存储（Thanos/Loki 持久化必备）

# 校验helm版本
helm version
# 校验存储类可用
kubectl get storageclasses
# 校验集群节点时间同步，后面会踩坑
chronyc sources

四、Step1：部署高可用 Prometheus（kube‑prometheus‑stack）

生产集群绝对不能单实例 Prometheus，必须部署 Prometheus Operator 托管。

1. 添加官方仓库

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

2. 生产级 values.yaml（优化后完整配置）

prometheus:
  prometheusSpec:
    replicas: 2
    retention: 15d
    scrapeInterval: 30s
    evaluationInterval: 30s
    resources:
      requests:
        cpu: 1000m
        memory: 2Gi
      limits:
        cpu: 2000m
        memory: 4Gi
    thanos:
      sidecar:
        enabled: true
        image: quay.io/thanos/thanos:v0.35.1
        objectStorageConfig:
          name: thanos-objstore
          key: thanos.yaml

alertmanager:
  alertmanagerSpec:
    replicas: 2
    retention: 120h

grafana:
  enabled: true
  adminPassword: Admin@2026
  persistence:
    enabled: true
    storageClassName: "你的存储类名称"

3. 部署命令

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

部署完成校验：

kubectl get pods -n monitoring
kubectl get svc -n monitoring

五、Step2：Thanos 高可用长期指标存储

默认 Prometheus 只能存短期数据，生产需要半年、一年历史趋势排查，必须上 Thanos。Thanos 解决三大痛点：

1. Prometheus 数据不能持久化
2. 单集群数据无法聚合
3. 监控数据无法压缩、占用磁盘大

配置对象存储 Secret

thanos-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: thanos-objstore
  namespace: monitoring
type: Opaque
stringData:
  thanos.yaml: |
    type: s3
    config:
      endpoint: minio.monitoring.svc.cluster.local:9000
      bucket: k8s-metrics
      access_key: minioadmin
      secret_key: minio密码
      insecure: true

hanos Sidecar 自动同步所有监控指标到对象存储，实现指标持久保存。

六、Step3：Loki+Promtail 轻量级日志系统（替代 ELK）

2026 年生产 K8s 主流日志方案已经全面偏向 Loki

• 资源极低
• 支持海量容器日志
• 支持按 Pod/Namespace/ 标签精准过滤
• 完美联动 Grafana

1. 部署 Loki 分布式版

. 部署 Promtail（节点级日志采集 DaemonSet）

promtail-values.yaml

config:
  snippets:
    pipelineStages:
      - docker: {}
      - match:
          selector: '{app!=""}'
          stages:
            - drop:
                expression: ".*healthcheck.*"

bash

helm install promtail grafana/promtail -n monitoring -f promtail-values.yaml

校验采集 Pod 是否每个节点运行一份：

kubectl get daemonset promtail -n monitoring

采集范围：

• 所有容器运行日志
• 节点系统日志
• K8s 事件日志
• 应用异常崩溃日志

七、Step4：Grafana 大盘配置

获取 Grafana 访问地址

用生产大盘 ID（直接导入即用）

• 1860：K8s Node 节点监控大盘
• 7249：K8s Pod 监控大盘
• 15759：K8s Deployment 资源监控
• 13613：Loki 日志可视化大盘

八、Step5：生产级告警规则配置

prometheus-rule.yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  namespace: monitoring
  name: k8s-alert-rules
  labels:
    prometheus: kube-monitor
spec:
  groups:
  - name: node.rules
    rules:
    - alert: NodeCpuHigh
      expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) *100) > 85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "节点CPU使用率超过85%"
    - alert: NodeMemoryHigh
      expr: 100 - (100 * node_memory_MemFree_bytes / node_memory_MemTotal_bytes) >85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "节点内存使用率超过85%"
    - alert: PodCrashLoop
      expr: kube_pod_status_phase{phase="Failed"} ==1
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "Pod异常崩溃 CrashLoopBackOff"

kubectl apply -f prometheus-rule.yaml

Alertmanager 配置推送钉钉机器人，alertmanager-config.yaml

global:
  resolve_timeout: 5m
route:
  receiver: 'dingtalk-webhook'
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
receivers:
- name: 'dingtalk-webhook'
  webhook_configs:
  - url: 'https://dingtalk机器人webhook地址'

九、本周真实踩坑记录（生产实测，附带详细解决方法 + 代码）

坑 1：单 Prometheus 部署，节点重启监控断档

现象：单实例 Prometheus 一旦重启 / 节点宕机，监控数据断层，无法查看历史指标排查故障。根因：单副本 Prometheus 内存存储，Pod 删除数据全部丢失，没有持久化。详细解决方法

1. Prometheus 设置 replicas:2 双副本
2. 开启 thanos sidecar，配置 S3 对象存储 Secret，指标落盘对象存储
3. 不允许生产环境 replicas=1

上面部署的 values.yaml 与 thanos‑secret.yaml 就是完整修复配置，直接 apply 即可。校验命令：

kubectl get pods -n monitoring | grep prometheus
# 查看sidecar是否正常启动
kubectl describe pod kube-monitor-prometheus-0 -n monitoring

坑 2：直接用 ELK 收集容器日志，磁盘爆满

现象：集群运行几天磁盘打满，ES 索引占用几十上百 G 磁盘。根因：Elasticsearch 做全文索引，每一条日志全部建立索引，日志量大存储成本极高。详细解决方法

1. 卸载原有 ELK 组件

helm uninstall elasticsearch -n logging
helm uninstall kibana -n logging

1. 改用 Loki+Promtail 方案，只对标签索引，不对日志全文索引
2. 在 loki values 配置日志保留时间，自动清理旧日志loki-values.yaml 片段

loki:
  limits_config:
    retention_period: 72h

helm upgrade loki grafana/loki-distributed -n monitoring -f loki-values.yaml

坑 3：Promtail 日志采集重复、漏采

现象：Grafana 里面日志重复输出，部分 Pod 日志完全看不到。根因 1：集群各个节点系统时间不一致，时间戳错乱导致采集重复。根因 2：Promtail 采集规则冲突，部分日志被 drop 过滤。

详细解决方法

1. 所有节点同步系统时间，所有服务器安装 chrony

# centos
yum install chrony -y
systemctl enable --now chronyd
# 验证时间同步
chronyc tracking

1. 修改 promtail 配置，关闭冲突过滤规则，增加采集调试输出promtail-fix.yaml

config:
  snippets:
    pipelineStages:
      - docker: {}
      - output:
          source: stdout

helm upgrade promtail grafana/promtail -n monitoring -f promtail-fix.yaml

1. 查看 promtail 日志排查采集问题

kubectl logs -f daemonset/promtail -n monitoring

坑 4：Grafana 大盘数据错乱、数据重复、历史数据丢失

现象：双 Prometheus 副本，Grafana 图表同一个时间点出现两套不一样指标，曲线抖动重复。根因：两个 Prometheus 实例同时抓取相同目标，查询时两份数据同时返回，没有开启 Thanos 去重。

详细解决方法修改 prometheus values，开启 Thanos 查询层 deduplicate 去重。thanos-query-values.yaml

thanos:
  query:
    enabled: true
    replicaLabel: prometheus_replica
    deduplicate: true

helm upgrade kube-monitor prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml -f thanos-query-values.yaml

然后 Grafana 数据源地址改为 Thanos‑query 服务地址，不再直接对接 Prometheus。

获取 thanos‑query service 名称

kubectl get svc -n monitoring

坑 5：告警风暴，短时间几百条告警轰炸钉钉

现象：节点宕机一瞬间，衍生几十条关联告警，钉钉疯狂刷屏。根因：没有告警分组、没有告警抑制规则，子告警和根告警同时发送。

详细解决方法修改 Alertmanager 配置，增加 inhibit_rules 抑制规则，当节点离线告警触发，抑制该节点下所有 Pod 告警。alertmanager-fix.yaml

global:
  resolve_timeout: 5m
route:
  receiver: 'dingtalk-webhook'
  group_by: ['alertname','instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
inhibit_rules:
  - source_match:
      severity: critical
      alertname: NodeNotReady
    target_match:
      severity: warning
    equal: ['instance']
receivers:
- name: 'dingtalk-webhook'
  webhook_configs:
  - url: '你的钉钉webhook'

kubectl apply -f alertmanager-fix.yaml
# 重载alertmanager配置
kubectl rollout restart statefulset/kube-monitor-alertmanager -n monitoring

十、本周总结

本周我们完成了标准 K8s 生产集群完整可观测体系：

• 指标高可用（Prometheus+Thanos）
• 轻量级日志（Loki+Promtail）
• 统一可视化（Grafana）
• 企业级告警体系

从此集群不再是黑盒，CPU 飙高、Pod 重启、日志报错、网络异常全部可视化，线上问题排查速度提升 10 倍。这一套是 2026 年中大型企业 K8s 标准可观测方案，面试非常加分。

下周预告

第 7 周：K8s 集群高可用架构深度实战，ETCD 备份恢复、主备切换、节点替换、灾备演练，彻底搞定集群不死能力。