1. Kubernetes集群监控实验概述在云原生技术栈中Kubernetes已经成为容器编排的事实标准。随着集群规模扩大和业务复杂度提升对集群运行状态的实时监控成为保障系统稳定性的关键环节。本次实验将搭建完整的Kubernetes监控体系覆盖从基础指标采集到可视化告警的全流程。监控系统的核心价值在于实时掌握集群资源利用率CPU/Memory/Disk快速定位Pod异常重启、节点故障等问题基于历史数据进行容量规划和性能优化满足企业级SLA要求的可观测性需求2. 监控方案设计与组件选型2.1 主流监控技术对比当前Kubernetes监控领域主要有三种技术路线方案类型代表工具适用场景优缺点分析开源组合方案PrometheusGrafana需要深度定制的中大型集群功能强大但部署复杂商业监控平台Datadog/New Relic企业级付费解决方案开箱即用但成本高昂Kubernetes原生Metrics ServerDashboard快速验证的小型测试环境功能有限但部署简单本实验选择Prometheus Operator方案因其具有完整的指标采集链node-exporter/kube-state-metrics原生PromQL查询语言支持与Grafana的无缝集成能力CRD定义的灵活配置方式2.2 核心组件架构完整的监控栈包含以下组件├── 数据采集层 │ ├── node-exporter节点资源指标 │ ├── kube-state-metricsK8s对象状态 │ └── cAdvisor容器运行时指标 ├── 存储计算层 │ └── Prometheus时间序列数据库 └── 可视化层 ├── Grafana仪表盘展示 └── Alertmanager告警管理3. 详细部署流程3.1 环境准备使用kubeadm搭建的v1.28集群节点配置要求至少2核CPU/4GB内存Prometheus节点持久化存储卷建议50GB以上网络策略开放9090/3000端口# 验证集群状态 kubectl get nodes -o wide kubectl get pods -A3.2 使用Helm快速部署推荐使用Helm 3进行一键化部署# 添加Prometheus社区仓库 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 安装Prometheus Stack helm install monitoring prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --create-namespace \ --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.storageClassNamestandard \ --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage50Gi关键参数说明storageClassName根据实际存储类调整retention指标保留周期默认15天scrapeInterval采集频率通常30s3.3 组件验证部署完成后检查关键Pod状态kubectl -n monitoring get pods预期看到以下组件运行正常prometheus-monitoring-kube-prometheus-prometheus-0alertmanager-monitoring-kube-prometheus-alertmanager-0monitoring-grafana4. 监控指标深度解析4.1 核心监控指标分类指标类别示例指标告警阈值建议节点资源node_cpu_utilization 80%持续5分钟触发Pod状态kube_pod_status_ready ! 1立即触发工作负载deployment_replicas_unavailable 0持续2分钟触发存储性能volume_io_latency 100ms持续10分钟触发4.2 PromQL实战示例计算节点CPU使用率100 - (avg by(instance)(rate(node_cpu_seconds_total{modeidle}[5m])) * 100)查找内存使用最高的Podtopk(3, sum by(pod)(container_memory_working_set_bytes{container!}))监控Pending状态的Podsum(kube_pod_status_phase{phasePending}) by(namespace)5. Grafana仪表盘配置5.1 导入官方仪表盘访问Grafana端口3000导入以下模板ID315Kubernetes集群概览6417节点资源详情13105工作负载监控5.2 自定义告警规则在PrometheusRule CRD中定义业务告警apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: custom-alerts spec: groups: - name: node-alerts rules: - alert: HighNodeCPU expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90 for: 5m labels: severity: critical annotations: summary: High CPU usage on {{ $labels.instance }}6. 生产环境优化建议6.1 性能调优参数prometheus: prometheusSpec: retention: 30d # 数据保留周期 scrapeInterval: 1m # 采集间隔 resources: limits: memory: 16Gi requests: cpu: 2 memory: 8Gi6.2 高可用方案Prometheus分片按namespace/功能划分采集任务Thanos长期存储解决历史数据查询问题Alertmanager集群避免单点故障7. 常见问题排查7.1 指标采集失败检查步骤验证ServiceMonitor选择器匹配kubectl get servicemonitor -n monitoring检查Target状态kubectl port-forward svc/prometheus-operated 9090 # 访问http://localhost:9090/targets7.2 Grafana登录问题默认凭证用户名admin密码kubectl get secret -n monitoring monitoring-grafana -o jsonpath{.data.admin-password} | base64 --decode8. 进阶监控场景8.1 自定义应用指标在Deployment中添加注解实现自动发现annotations: prometheus.io/scrape: true prometheus.io/port: 8080 prometheus.io/path: /metrics8.2 日志监控集成通过LokiPromtail构建日志监控体系helm install loki grafana/loki-stack \ --namespace monitoring \ --set promtail.enabledtrue关键提示生产环境建议将监控组件部署在独立的基础设施节点避免监控系统本身影响业务稳定性。同时需要定期检查Prometheus的存储增长情况建议配置自动清理策略。