一、Prometheus监控K8s的核心架构

Prometheus监控K8s集群的核心在于其服务发现机制与指标采集模型的深度适配。K8s的动态资源特性（如Pod的弹性伸缩、Service的负载均衡）要求监控系统具备自动发现和动态更新的能力。Prometheus通过三种服务发现方式实现这一目标：

1. 基于K8s API的发现：通过kubernetes_sd_config配置，Prometheus定期轮询K8s API Server获取Endpoints、Pod、Service等资源对象。例如，以下配置可发现所有命名空间中带有prometheus.io/scrape=true注解的Service：

   scrape_configs:
   - job_name: 'kubernetes-service-endpoints'
    kubernetes_sd_configs:
      - role: endpoints
    relabel_configs:
      - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
        action: keep
        regex: true

2. 基于Pod的发现：直接监控Pod暴露的指标端口，适用于无Service中间层的场景。通过__meta_kubernetes_pod_annotation_prometheus_io_port注解指定端口。
3. 基于CRD的扩展：通过Operator模式（如Prometheus Operator）使用ServiceMonitor和PodMonitor自定义资源，实现声明式监控配置。

二、指标采集的深度优化

1. 核心指标分类

K8s监控指标可分为四类：

• 基础设施指标：Node资源使用率（CPU、内存、磁盘I/O）、网络带宽
• 工作负载指标：Pod状态（Ready/NotReady）、容器重启次数、资源请求/限制
• 集群服务指标：API Server请求延迟、Etcd存储操作耗时、Controller Manager队列深度
• 应用自定义指标：通过Prometheus Exporter暴露的业务指标（如Redis QPS、MySQL连接数）

2. 采集策略设计

• 短周期指标：对CPU、内存等高频变化指标，设置scrape_interval: 15s
• 长周期指标：对PV使用率等稳定指标，可延长至1m
• 关键路径优化：对API Server的apiserver_request_latencies_bucket指标，建议单独配置Job并启用honor_labels: true避免标签冲突

3. 标签管理最佳实践

• 统一标签命名：遵循__meta_kubernetes_前缀规范，如__meta_kubernetes_namespace、__meta_kubernetes_pod_name
• 标签精简策略：通过relabel_configs过滤非必要标签，例如：

  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_app]
    target_label: app
    action: replace
  - regex: __meta_kubernetes_pod_label_(.+)
    action: labelmap

三、告警规则的工程化实现

1. 告警分类体系

• 基础设施告警：Node磁盘剩余空间<10%、节点NotReady状态持续5分钟
• 工作负载告警：Pod CrashLoopBackOff次数>3、容器内存使用率>90%持续1分钟
• 服务可用性告警：Service Endpoints数量为0、Ingress 5xx错误率>5%

2. 告警表达式设计

以Node磁盘告警为例，完整的Recording Rule和Alert Rule配置：

groups:
- name: node.rules
  rules:
  - record: node:node_filesystem_avail_bytes:percent
    expr: |
      100 - (
        node_filesystem_avail_bytes{fstype=~"ext4|xfs"}
        /
        node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100
      )
  - alert: NodeDiskSpaceCritical
    expr: node:node_filesystem_avail_bytes:percent > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Node {{ $labels.instance }} disk space critical"
      description: "Disk space on {{ $labels.mountpoint }} is {{ $value }}% full"

3. 告警抑制策略

• 依赖关系抑制：当Node处于NotReady状态时，抑制该节点上所有Pod的告警
• 时间窗口抑制：对频繁重启的Pod，设置首次告警后30分钟内不再重复告警
• 等级压制：Critical告警自动抑制Warning告警

四、可视化与运维实践

1. Grafana仪表盘设计

推荐构建三级仪表盘体系：

• 集群概览盘：展示Node数量、Pod分布、资源使用率热力图
• 组件详情盘：针对API Server、Etcd等核心组件的深度监控
• 业务关联盘：将应用指标与基础设施指标关联展示（如订单处理延迟与CPU负载的关联分析）

2. 运维自动化集成

• Prometheus Alertmanager与Webhook集成：将告警推送至钉钉/企业微信机器人
• Thanos查询增强：部署Thanos Query实现多集群指标聚合查询
• Prometheus Operator自动修复：通过PrometheusRule CRD实现告警规则的版本化管理

3. 性能调优建议

• 存储优化：使用TSDB压缩（--storage.tsdb.retention.time=30d）和WAL分段（--storage.tsdb.wal-segment-size=128MB）
• 查询优化：对高频查询添加Recording Rule，避免实时计算
• 水平扩展：当Series数量超过10M时，考虑采用Thanos Sidecar或Cortex分片架构

五、典型问题解决方案

1. 指标丢失问题

• 现象：部分Pod指标间歇性丢失
• 诊断：通过prometheus_tsdb_head_series检查Series数量是否达到上限
• 解决：调整--storage.tsdb.retention.size参数或优化标签设计

2. 告警风暴问题

• 现象：短时间内产生大量重复告警
• 诊断：检查group_wait和repeat_interval配置
• 解决：设置合理的group_interval（如5m）和repeat_interval（如1h）

3. 跨集群监控问题

• 现象：需要监控多个K8s集群
• 方案：
  • 方案一：每个集群部署独立Prometheus，通过Thanos Query聚合
  • 方案二：使用Prometheus Federation集中采集关键指标

六、进阶实践建议

1. eBPF集成：通过BPF Exporter采集高级网络指标（如TCP重传率）
2. 服务网格监控：结合Istio Telemetry API采集服务间通信指标
3. AI预测：基于历史指标数据训练资源使用预测模型（如Prophet算法）
4. 混沌工程验证：在注入节点故障时验证监控系统的告警响应能力

通过上述架构设计与优化实践，Prometheus可实现对K8s集群的全方位监控，既保障基础设施的稳定性，又为业务运维提供深度洞察能力。实际部署时建议从核心指标开始，逐步扩展至应用层监控，最终形成完整的可观测性体系。