📚 课程目录第2章 Kubernetes监控体系

2. Kubernetes监控体系：Prometheus与Metrics Server的部署与基础配置

Kubernetes集群的可观测性依赖于分层监控体系。本章聚焦于两个核心组件：Metrics Server（资源指标聚合层）与 Prometheus（事件与自定义指标监控系统）。理解两者的定位、部署方式及基础配置，是构建SLO作业模板的数据基础。

2.1 监控分层架构

Kubernetes官方将监控指标分为三个层次：

层次	数据来源	典型组件	用途
资源指标	kubelet / cAdvisor	Metrics Server	HPA、kubectl top、调度决策
服务指标	应用 / exporter	Prometheus + kube-state-metrics	SLO监控、告警、容量规划
事件与日志	API Server / 容器日志	EventRouter / Loki	审计、故障排查

Metrics Server 提供轻量、实时的 CPU/内存快照；Prometheus 提供持久化、多维度的指标存储与查询。两者互补，共同支撑SLO的采集与计算。

  关键原则：Metrics Server 不存储历史数据，仅保留内存中的瞬时快照；Prometheus 通过本地TSDB存储历史数据，支持聚合与长期趋势分析。

2.2 Metrics Server 部署与验证

2.2.1 部署方式

Metrics Server 通常通过 kubectl apply 或 Helm 部署。以下为官方 YAML 方式：

# 下载并应用最新 release
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 验证 Pod 状态
kubectl get pods -n kube-system -l k8s-app=metrics-server

2.2.2 常见配置调整

在部分集群（如自建、kubeadm）中，需要调整 Metrics Server 的启动参数以绕过 TLS 验证：

# 修改 deployment 添加 --kubelet-insecure-tls
kubectl edit deployment metrics-server -n kube-system

# 在 args 中添加：
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP

2.2.3 验证采集

# 查看节点资源使用
kubectl top nodes

# 查看 Pod 资源使用
kubectl top pods -A

排错提示：如果 kubectl top 返回 error: metrics not available yet，请检查 Metrics Server Pod 日志，确认 kubelet 地址可达且证书配置正确。

2.3 Prometheus 部署与基础配置

2.3.1 部署策略对比

部署方式	复杂度	可定制性	推荐场景
Helm (kube-prometheus-stack)	低	高	生产环境、SRE团队
Prometheus Operator	中	极高	大规模、多集群
手动 YAML	高	完全控制	学习、最小化部署

本课程采用 kube-prometheus-stack 作为标准部署方案，它集成了 Prometheus、Alertmanager、Grafana 及多种 exporter。

2.3.2 Helm 部署步骤

# 添加 Helm 仓库
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 创建命名空间
kubectl create namespace monitoring

# 安装 kube-prometheus-stack
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set grafana.enabled=true \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false

注意：serviceMonitorSelectorNilUsesHelmValues=false 允许 Prometheus 发现所有命名空间下的 ServiceMonitor 资源，这对后续SLO作业模板的自动发现至关重要。

2.3.3 验证部署

# 检查 Pod 状态
kubectl get pods -n monitoring

# 访问 Prometheus Web UI（端口转发）
kubectl port-forward svc/prometheus-operated -n monitoring 9090:9090

# 访问 Grafana（默认 admin/prom-operator）
kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

2.4 核心组件关系图

下图展示了 Metrics Server 与 Prometheus 在 Kubernetes 监控体系中的位置及数据流：

2.5 基础配置清单

完成部署后，需要执行以下基础配置以确保监控体系可用：

配置 Prometheus 数据保留时间：默认15天，生产环境建议调整为30天以上。
启用 ServiceMonitor 自动发现：确保 Prometheus 能自动发现带有 prometheus.io/scrape: "true" 注解的服务。
配置 Grafana 数据源：将 Prometheus 添加为默认数据源，并导入 Kubernetes 官方仪表盘（ID: 315, 6417）。
设置告警路由：在 Alertmanager 中配置接收者（如 Slack、PagerDuty）和抑制规则。
验证指标采集：在 Prometheus UI 中执行 up 查询，确认所有目标状态为 1。

  生产建议：Metrics Server 应配置资源请求与限制（通常 100m CPU / 200Mi 内存）；Prometheus 的存储卷建议使用 SSD 并配置 PVC 持久化，避免 Pod 重启导致历史数据丢失。

2.6 本章小结

Metrics Server 与 Prometheus 构成了 Kubernetes 监控体系的双引擎：前者提供实时资源快照，支撑 HPA 与调度；后者提供持久化多维指标，支撑 SLO 监控与告警。掌握两者的部署与基础配置，是后续构建 SLO 作业模板的前提条件。