1. Kubernetes 监控体系概述
在云原生时代,Kubernetes 已成为容器编排的事实标准,而监控则是保障集群稳定运行的基石。Prometheus 作为 CNCF 毕业项目,凭借其强大的时序数据收集能力和灵活的查询语言 PromQL,成为 Kubernetes 监控的首选方案。
1.1 为什么选择 Prometheus 监控栈
Prometheus 监控栈(kube-prometheus-stack)是一个完整的解决方案,它整合了以下核心组件:
- Prometheus Operator:通过 CRD 简化 Prometheus 的部署和管理
- Prometheus:负责指标收集、存储和告警
- Grafana:提供可视化仪表板
- Alertmanager:处理告警通知
- Node Exporter:收集节点级指标
- Kube State Metrics:转换 Kubernetes 对象状态为指标
这套方案相比单独部署各组件有以下优势:
- 声明式配置:通过 Helm Chart 实现一键部署
- 自动发现:自动监控 Kubernetes 服务、Pod 和节点
- 预置仪表板:包含 100+ 开箱即用的 Grafana 面板
- 高可用支持:可配置多副本和持久化存储
2. 环境准备与工具安装
2.1 Helm 客户端安装详解
Helm 是 Kubernetes 的包管理工具,使用 Helm Chart 可以简化复杂应用的部署。以下是详细的安装步骤和注意事项:
bash复制# 下载指定版本的 Helm 二进制包(建议使用最新稳定版)
curl -LO https://get.helm.sh/helm-v4.1.1-linux-amd64.tar.gz
# 解压时建议添加-v参数查看进度
tar -zxvf helm-v4.1.1-linux-amd64.tar.gz -v
# 移动至系统路径前建议先检查权限
ls -l linux-amd64/helm
sudo mv linux-amd64/helm /usr/local/bin/helm
# 验证安装并检查版本兼容性
helm version
安装注意事项:
- 生产环境建议固定 Helm 版本以避免兼容性问题
- 如果服务器无法直接访问 GitHub,可先下载到本地再上传
- 确保 /usr/local/bin 在系统的 PATH 环境变量中
2.2 Kubernetes 集群要求
在部署前,请确认集群满足以下要求:
| 组件 | 最低要求 | 推荐配置 |
|---|---|---|
| Kubernetes 版本 | 1.16+ | 1.22+ |
| 节点 CPU | 2核 | 4核+ |
| 节点内存 | 4GB | 8GB+ |
| 存储 | 10GB | 50GB+ |
特别需要注意:
- 确保 kubelet 启用了认证/授权
- 工作节点需要开放必要的端口(如 9100 用于 Node Exporter)
- 如果有网络策略限制,需要放行监控组件的通信
3. 监控栈部署实战
3.1 获取和准备 Chart 包
kube-prometheus-stack 的 Helm Chart 由 Prometheus 社区维护,获取方式有两种:
方法一:从 GitHub Release 下载
bash复制# 查找最新稳定版本
curl -s https://api.github.com/repos/prometheus-community/helm-charts/releases/latest | grep browser_download_url
# 下载特定版本(示例使用64.5.0)
wget https://github.com/prometheus-community/helm-charts/releases/download/kube-prometheus-stack-64.5.0/kube-prometheus-stack-64.5.0.tgz
# 解压并进入目录
tar -zxvf kube-prometheus-stack-*.tgz
cd kube-prometheus-stack-*
方法二:通过 Helm 仓库添加
bash复制helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm search repo prometheus-community/kube-prometheus-stack
版本选择建议:
- 生产环境建议使用稳定版而非最新版
- 注意 Chart 版本与 Kubernetes 版本的兼容性
- 下载后建议校验 SHA256 确保文件完整性
3.2 深度配置解析
以下是针对生产环境的详细配置说明(my-config.yaml):
yaml复制# ================= Grafana 配置 =================
grafana:
adminPassword: "StrongPassword@123" # 建议使用复杂密码
persistence:
enabled: true
storageClassName: "longhorn"
accessModes: ["ReadWriteOnce"]
size: 5Gi
sidecar:
dashboards:
enabled: true
label: grafana_dashboard
plugins:
- grafana-piechart-panel # 常用插件示例
# ================= Prometheus 核心配置 =================
prometheus:
prometheusSpec:
scrapeInterval: 30s
evaluationInterval: 30s
retention: 15d # 数据保留时间
ruleSelectorNilUsesHelmValues: false
serviceMonitorSelectorNilUsesHelmValues: false
# 资源限制配置(根据集群规模调整)
resources:
requests:
memory: 2Gi
cpu: 1
limits:
memory: 4Gi
cpu: 2
# 存储配置(生产环境必须配置持久化)
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: "longhorn"
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 50Gi
# ================= Alertmanager 告警配置 =================
alertmanager:
config:
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 12h
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: 'alerts@example.com'
from: 'prometheus@example.com'
smarthost: 'smtp.example.com:587'
auth_username: 'user'
auth_password: 'password'
send_resolved: true
关键配置说明:
-
镜像仓库:如果使用私有仓库,确保:
- 所有工作节点已配置仓库认证
- 镜像版本与 Chart 默认版本一致
- 网络策略允许访问私有仓库
-
存储配置:
- 生产环境必须配置持久化存储
- 根据监控数据量调整存储大小
- 多副本部署需要 ReadWriteMany 存储
-
资源限制:
- 根据集群规模调整 CPU/内存限制
- 监控组件本身也会消耗资源
3.3 安装与验证
执行安装命令并添加详细参数说明:
bash复制helm install my-monitoring . \
--namespace monitoring \
-f my-config.yaml \
--create-namespace \
--timeout 10m \
--atomic \ # 失败时自动回滚
--wait \ # 等待资源就绪
--debug # 调试模式
安装后检查清单:
- 检查 Pod 状态:
bash复制kubectl get pods -n monitoring -w
所有 Pod 应处于 Running 状态,READY 列显示为 1/1 或 2/2
- 检查持久化卷:
bash复制kubectl get pvc -n monitoring
应显示 Bound 状态
- 检查服务发现:
bash复制kubectl get servicemonitors -n monitoring
kubectl get prometheusrules -n monitoring
- 验证指标采集:
bash复制kubectl port-forward svc/my-monitoring-prometheus 9090 -n monitoring
访问 localhost:9090 查看 Targets 页面,确认所有采集目标为 UP 状态
4. 访问与集成配置
4.1 Ingress 访问配置最佳实践
生产环境通常通过 Ingress 暴露 Grafana 和 Alertmanager:
yaml复制grafana:
ingress:
enabled: true
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: grafana-basic-auth
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
hosts:
- "grafana.example.com"
tls:
- secretName: grafana-tls
hosts:
- "grafana.example.com"
alertmanager:
ingress:
enabled: true
hosts:
- "alert.example.com"
tls:
- secretName: alert-tls
hosts:
- "alert.example.com"
安全建议:
- 必须启用 HTTPS
- 建议添加基础认证或集成 OAuth
- 限制访问 IP 范围
- 为不同环境使用不同的子域名
4.2 Grafana 初始配置
首次登录 Grafana 后建议进行以下配置:
-
数据源配置:
- 检查 Prometheus 数据源是否自动配置
- 测试数据源连接
-
仪表板管理:
- 导入官方仪表板(ID:315)
- 根据业务需求定制关键仪表板
-
告警渠道:
- 配置邮件、Slack 等通知方式
- 测试告警流程
-
用户权限:
- 创建只读用户用于查看
- 限制管理员权限
5. 生产环境调优指南
5.1 性能优化参数
yaml复制prometheus:
prometheusSpec:
# 优化查询性能
queryLogFile: /var/log/prometheus/query.log
enableAdminAPI: false # 禁用管理API
# 优化内存使用
retentionSize: "50GB" # 最大存储大小
walCompression: true
# 调整采集配置
scrapeInterval: 1m
evaluationInterval: 1m
5.2 高可用配置
yaml复制prometheus:
prometheusSpec:
replicas: 2 # 多副本
shards: 2 # 数据分片
# 多副本存储需要 ReadWriteMany
storageSpec:
volumeClaimTemplate:
spec:
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 100Gi
alertmanager:
alertmanagerSpec:
replicas: 3 # 奇数个节点
5.3 监控项优化
-
关键指标监控:
- Kubernetes 资源使用率
- Pod 重启次数
- 节点磁盘空间
- 网络流量
-
自定义指标:
- 业务特定指标
- 应用性能指标
- 数据库连接数
-
黑盒监控:
- HTTP 端点健康检查
- TCP 端口检测
- ICMP ping 检测
6. 日常维护与故障排查
6.1 常用维护命令
查看 Release 状态:
bash复制helm list -n monitoring
helm status my-monitoring -n monitoring
升级配置:
bash复制helm upgrade my-monitoring . \
--namespace monitoring \
-f my-config.yaml \
--reuse-values \
--history-max 5
回滚操作:
bash复制helm history my-monitoring -n monitoring
helm rollback my-monitoring 1 -n monitoring # 回滚到版本1
资源清理:
bash复制helm uninstall my-monitoring -n monitoring
kubectl delete namespace monitoring
# 注意:持久化数据需要手动删除PVC
6.2 常见问题排查
问题1:Pod 处于 CrashLoopBackOff 状态
- 检查日志:
kubectl logs -f <pod-name> -n monitoring - 常见原因:镜像拉取失败、配置错误、权限问题
问题2:Prometheus 磁盘空间不足
- 解决方案:
- 增加 PVC 大小
- 调整数据保留时间
- 启用数据压缩
问题3:指标采集失败
- 检查步骤:
- 查看 ServiceMonitor 配置
- 检查目标服务是否暴露 /metrics 端点
- 验证网络连通性
问题4:Grafana 登录问题
- 重置密码:
bash复制kubectl exec -it <grafana-pod> -n monitoring -- grafana-cli admin reset-admin-password "newpassword"
6.3 监控数据备份策略
-
定期备份 Prometheus 数据:
- 使用 VolumeSnapshot 备份 PVC
- 配置备份到对象存储
-
备份 Grafana 配置:
- 定期导出仪表板 JSON
- 备份 Grafana 数据库
-
备份告警规则:
- 导出 PrometheusRule CRD
- 版本控制配置文件
7. 安全加固建议
7.1 网络隔离
- 为监控组件创建专用网络策略
- 限制 Prometheus 的访问权限
- 禁用不必要的端口
7.2 认证授权
- 为 Grafana 配置 SSO 集成
- 为 Prometheus 启用 TLS
- 限制 Alertmanager 的访问
7.3 审计日志
- 记录所有管理操作
- 监控异常访问模式
- 定期审查权限设置
8. 扩展与集成
8.1 自定义指标采集
通过 ServiceMonitor 添加自定义指标采集:
yaml复制apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: custom-app-monitor
namespace: monitoring
spec:
selector:
matchLabels:
app: custom-app
endpoints:
- port: web
interval: 30s
path: /metrics
8.2 与外部系统集成
-
告警通知集成:
- Slack
- PagerDuty
- 企业微信
-
数据导出:
- 远程写入到 Thanos
- 导出到 Elasticsearch
- 集成到数据仓库
-
CI/CD 集成:
- 部署前检查监控状态
- 金丝雀发布监控
9. 版本升级策略
-
测试环境验证:
- 先在非生产环境测试新版本
- 验证所有仪表板和告警规则
-
滚动升级:
- 分阶段升级组件
- 监控升级过程中的系统状态
-
回滚计划:
- 准备旧版本配置
- 确保备份可用
10. 监控体系演进
随着业务发展,监控体系可能需要:
-
多集群监控:
- 使用 Thanos 或 VictoriaMetrics 实现全局视图
- 集中化管理告警
-
指标分层:
- 关键指标实时监控
- 历史数据分析
-
与日志、链路追踪集成:
- 关联指标与日志
- 端到端性能分析
在实际运维中,我们还需要根据业务特点不断调整监控策略。比如对于有状态服务,需要特别关注持久化卷的使用情况;对于无状态服务,则更关注副本数和请求延迟。每个 Kubernetes 集群都有其独特性,监控方案也需要相应调整。