一、K8s监控的核心挑战与Prometheus的适配性

K8s动态资源调度特性（如Pod自动扩缩容、节点迁移）导致传统监控工具（如Zabbix）难以精准追踪资源状态。Prometheus通过以下特性实现高效监控：

1. 服务发现机制：支持K8s原生API发现（通过--kubelet-service和--config-file参数），自动识别Node、Pod、Service等资源变化
2. 时序数据库优势：基于时间序列的压缩存储算法，单节点可存储数百万时间序列数据（实测16核64G节点可支撑5万+Pod监控）
3. Pull模式优化：通过ServiceMonitor/PodMonitor自定义资源（CRD）实现监控目标动态管理，避免Push模式带来的配置同步问题

典型案例：某金融企业K8s集群（3000+Pod）通过Prometheus联邦架构实现跨区域监控，数据采集延迟<5s，存储成本较ELK方案降低60%

二、监控架构设计与实践

2.1 基础组件部署方案

方案一：CoreDNS+NodeExporter核心监控

# prometheus-deployment.yaml示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-server
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.47.2
        args:
        - --config.file=/etc/prometheus/prometheus.yml
        - --storage.tsdb.retention.time=30d
        ports:
        - containerPort: 9090

关键配置项说明：

• storage.tsdb.retention.time：建议生产环境设置≥30天
• --web.enable-admin-api：需谨慎开启，用于TSDB维护操作
• --web.external-url：配置Ingress时必须设置，解决Alertmanager跳转问题

方案二：Thanos+Prometheus高可用架构

通过Thanos Query实现多Prometheus实例聚合查询，组件配置要点：

1. Sidecar模式部署（与Prometheus同Pod）
2. Object Storage配置（推荐MinIO或S3兼容存储）
3. 查询降级策略（--query.auto-downsampling参数控制）

2.2 核心指标采集策略

2.2.1 资源指标采集

• Node级别：通过NodeExporter采集CPU/内存/磁盘IO（建议配置--collector.disable-defaults排除无用指标）
• Pod级别：cAdvisor自动集成，关键指标包括：

  container_cpu_usage_seconds_total{container="",pod="",namespace=""}
  container_memory_working_set_bytes{container="",pod="",namespace=""}

• K8s组件监控：
  • kubelet：/metrics端点（需开启--authentication-token-webhook）
  • etcd：通过--endpoints参数指定集群地址

2.2.2 自定义业务指标

通过Prometheus Client库（Go/Python/Java）暴露业务指标，示例Go代码：

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)
var (
    requestCount = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total HTTP requests",
        },
        []string{"method", "path"},
    )
)
func init() {
    prometheus.MustRegister(requestCount)
}
func handler(w http.ResponseWriter, r *http.Request) {
    requestCount.WithLabelValues(r.Method, r.URL.Path).Inc()
    // ...业务逻辑
}

三、告警规则设计与优化

3.1 基础告警策略

3.1.1 资源阈值告警

# prometheus-rules.yaml示例
groups:
- name: k8s.resource.rules
  rules:
  - alert: HighCPUUsage
    expr: sum(rate(container_cpu_usage_seconds_total{container!="POD"}[5m])) by (pod) > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} CPU usage high"

3.1.2 可用性告警

• Pod CrashLoopBackOff检测：

  kube_pod_container_status_restarts_total > 3

• 服务不可达告警：

  probe_success{job="blackbox-exporter"} == 0

3.2 告警降噪优化

1. 重复告警抑制：通过for字段设置持续触发时间（建议5-10min）
2. 标签聚合：使用by (namespace,pod)减少告警数量
3. 沉默规则：在Alertmanager配置中设置：

   route:
     group_by: ['alertname', 'cluster']
     repeat_interval: 1h

四、生产环境最佳实践

4.1 性能优化方案

1. 采集间隔调整：
   • 资源指标：15-30s（scrape_interval）
   • 业务指标：60s（避免频繁变更）
2. 存储优化：
   • 启用WAL压缩：--storage.tsdb.wal-compression
   • 分块存储：--storage.tsdb.path=/data/prometheus（单独挂载SSD）
3. 查询优化：
   • 限制查询范围：&step=60s
   • 使用Recording Rules预计算常用指标

4.2 故障排查指南

4.2.1 常见问题处理

现象	排查步骤
目标不可达	检查ServiceAccount权限、NetworkPolicy
指标缺失	验证Pod annotations：prometheus.io/scrape: "true"
内存溢出	调整--storage.tsdb.retention.size限制

4.2.2 日志分析技巧

1. Prometheus启动日志关键字段：

   level=info msg="Loading configuration file" file=/etc/prometheus/prometheus.yml
   level=error msg="Error reloading config" err="1 error in configuration"

2. 目标健康检查：

   curl -v http://<prometheus-ip>:9090/api/v1/targets

五、扩展生态集成

5.1 Grafana可视化方案

1. 推荐仪表盘：
   • K8s集群概览（ID：3119）
   • Node资源详情（ID：1860）
   • Pod性能分析（ID：9614）
2. 变量配置技巧：

   Label: namespace
   Query: label_values(kube_pod_info, namespace)

5.2 长期存储方案对比

方案	成本	查询性能	适用场景
Thanos	中等	高	跨集群聚合
VictoriaMetrics	低	极高	超大规模集群
InfluxDB	高	中等	时序+日志混合存储

六、总结与展望

Prometheus监控K8s集群已形成完整生态链，从基础资源监控到业务指标采集均可通过标准化方案实现。未来发展方向包括：

1. eBPF技术集成（实现更细粒度的网络监控）
2. AI异常检测（基于历史数据训练预测模型）
3. 服务网格监控（与Istio/Linkerd深度整合）

建议运维团队定期进行监控系统健康检查（每月一次），重点关注存储增长趋势、告警规则有效性以及采集延迟指标，确保监控体系持续稳定运行。