一、Prometheus监控K8s的核心原理

Prometheus监控K8s集群的核心机制基于Kubernetes的元数据暴露与Prometheus的灵活抓取能力。K8s通过kubelet内置的cAdvisor组件持续收集节点和容器的资源指标（CPU、内存、磁盘、网络等），并通过/metrics/cadvisor端点暴露。同时，K8s的API Server、Scheduler、Controller Manager等核心组件也通过/metrics端点提供自身运行状态指标。

Prometheus通过ServiceMonitor或PodMonitor（需配合Prometheus Operator使用）定义抓取规则，动态发现K8s中的目标服务。例如，通过kube-state-metrics服务可以将K8s资源对象（Deployment、Pod、Service等）的状态转换为可监控的指标，如Pod的重启次数、就绪状态等。这种设计使得Prometheus能够无缝适配K8s的动态特性，即使Pod因缩容或故障被重建，也能通过Service的DNS名称或标签选择器持续抓取新实例的指标。

二、部署Prometheus监控K8s集群的完整步骤

1. 环境准备与组件安装

在K8s集群中部署Prometheus需先安装Prometheus Operator（推荐使用kube-prometheus-stack Helm Chart），该Operator通过CRD（Custom Resource Definitions）简化了监控配置。安装命令如下：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
  --set grafana.enabled=true

此命令会同时部署Prometheus、Grafana（可视化面板）、Alertmanager（告警管理）和kube-state-metrics、node-exporter等核心组件。serviceMonitorSelectorNilUsesHelmValues=false确保Prometheus能发现所有命名空间的ServiceMonitor。

2. 配置ServiceMonitor抓取K8s组件指标

以监控kube-apiserver为例，需创建ServiceMonitor资源：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-apiserver
  namespace: monitoring
  labels:
    k8s-app: kube-apiserver
spec:
  jobLabel: k8s-app
  selector:
    matchLabels:
      component: apiserver
      provider: kubernetes
  namespaceSelector:
    matchNames:
      - default
  endpoints:
    - port: https
      interval: 30s
      scheme: https
      tlsConfig:
        caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        serverName: kubernetes
      bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

该配置通过标签选择器匹配kube-apiserver的Service，使用TLS加密和ServiceAccount令牌认证，每30秒抓取一次指标。类似地，可为kube-scheduler、kube-controller-manager等组件配置ServiceMonitor。

3. 自定义指标监控

对于业务Pod的自定义指标（如应用内部业务指标），需在Pod中暴露/metrics端点（通常使用Prometheus Client库实现），并通过PodMonitor抓取：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: business-app
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: business-app
  podMetricsEndpoints:
    - interval: 15s
      path: /metrics
      port: http

此配置会监控所有标签为app=business-app的Pod，每15秒抓取一次/metrics端点的数据。

三、关键监控指标与告警规则设计

1. 核心资源监控指标

• 节点资源：node_memory_MemAvailable_bytes（可用内存）、node_cpu_seconds_total{mode="system"}（系统CPU使用率）、node_disk_io_time_seconds_total（磁盘IO时间）。
• Pod资源：container_cpu_usage_seconds_total（容器CPU使用量）、container_memory_working_set_bytes（容器内存工作集）。
• K8s资源对象：kube_pod_status_ready（Pod就绪状态）、kube_deployment_status_replicas_available（Deployment可用副本数）。

2. 告警规则示例

在Prometheus的alert.rules.yml中定义告警规则，例如：

groups:
- name: k8s.rules
  rules:
  - alert: HighCPUUsage
    expr: sum(rate(container_cpu_usage_seconds_total{namespace!="kube-system"}[5m])) by (pod) > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has high CPU usage"
      description: "CPU usage is {{ $value }} (80%+ of limit) for 10 minutes."
  - alert: PodNotReady
    expr: kube_pod_status_ready{condition="true"} == 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.pod }} is not ready"
      description: "Pod has been in non-ready state for 5 minutes."

第一条规则监控非系统命名空间中Pod的CPU使用率，超过80%持续10分钟则触发警告；第二条规则监控Pod的就绪状态，若5分钟内未就绪则触发严重告警。

四、性能优化与故障排查

1. 抓取效率优化

• 分批抓取：将ServiceMonitor按组件分组，避免单次抓取任务过大。例如，将kube-system命名空间的组件与其他业务服务分开。
• 缩短抓取间隔：对关键指标（如kube_pod_status_ready）设置更短的抓取间隔（如15s），非关键指标可延长至1分钟。
• 使用Relabeling：通过relabel_configs过滤无关指标，减少数据存储量。例如，仅保留特定命名空间的指标：

relabel_configs:
  - source_labels: [__meta_kubernetes_namespace]
    regex: '^(production|staging)$'
    action: keep

2. 存储优化

• 保留策略：在Prometheus配置中设置--storage.tsdb.retention.time=30d，保留30天数据，避免磁盘占满。
• 远程存储：集成Thanos或Cortex实现长期存储，通过Sidecar模式将数据上传至对象存储（如S3）。

3. 常见故障排查

• 抓取失败：检查Prometheus的Targets页面，确认端点是否可达。若返回401 Unauthorized，检查ServiceAccount的RBAC权限。
• 指标缺失：使用promtool query instant命令手动查询指标，例如：

kubectl exec -it prometheus-prometheus-0 -n monitoring -- promtool query instant 'http://localhost:9090' 'kube_pod_status_ready{namespace="default"}'

若无结果，检查kube-state-metrics的日志或ServiceMonitor配置。

五、高级监控场景

1. 自定义Exporter集成

对于不支持Prometheus协议的遗留应用，可通过Node Exporter的Textfile Collector或独立Exporter（如jmx_exporter监控Java应用）收集指标。例如，在Node Exporter的/var/lib/node_exporter/目录下创建custom.prom文件，写入自定义指标：

# HELP custom_app_requests Total requests processed
custom_app_requests{job="custom-app"} 1024

Node Exporter会自动读取该文件并暴露指标。

2. 多集群监控

使用Prometheus Federation将多个集群的指标汇总至中央Prometheus。在子集群的Prometheus配置中添加federation抓取任务：

scrape_configs:
  - job_name: 'federate'
    scrape_interval: 1m
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{__name__=~"kube_.*"}'
        - '{__name__=~"node_.*"}'
    static_configs:
      - targets:
          - 'prometheus-subcluster:9090'

中央Prometheus通过此配置抓取子集群的关键指标。

六、总结与最佳实践

Prometheus监控K8s集群的核心优势在于其与K8s生态的深度集成和灵活性。通过合理配置ServiceMonitor/PodMonitor、设计有效的告警规则、优化抓取与存储性能，可实现高可用的集群监控。建议遵循以下最佳实践：

1. 分层监控：将指标分为基础设施层（节点、网络）、K8s控制层（API Server、Etcd）和应用层，分别设置不同的抓取间隔和保留策略。
2. 告警分级：按严重程度划分告警级别（如P0-P3），确保关键告警（如Pod崩溃）能立即通知。
3. 定期演练：模拟节点故障或Pod崩溃，验证监控和告警的有效性。
4. 版本兼容：关注Prometheus Operator和K8s版本的兼容性，避免因版本不匹配导致监控失效。

通过以上方法，Prometheus可成为K8s集群运维的“眼睛”，帮助团队快速发现和解决问题，保障集群稳定运行。