Kube-Prometheus部署后，别忘了做这3步：开放访问、检查面板、理解监控对象

Kube-Prometheus部署后必做的3个关键步骤：从安装到实战的完整指南

当你看到所有Pod都处于Running状态时，可能以为大功告成了——但真正的挑战才刚刚开始。部署成功只是第一步，要让这套监控系统真正发挥作用，还需要完成几个关键操作。本文将带你深入理解部署后的必要配置，让你不仅能访问监控界面，更能真正读懂数据。

1. 开放访问：正确处理网络策略与安全权衡

很多人在删除prometheus-networkPolicy.yaml文件时心里都会打鼓：这会不会带来安全隐患？实际上，kube-prometheus默认的网络策略确实会阻止外部访问，这是出于安全考虑的设计。但在开发测试环境中，我们通常需要临时开放访问。

1.1 为什么需要删除网络策略

默认安装会创建三个关键的网络策略：

• prometheus-networkPolicy.yaml
• grafana-networkPolicy.yaml
• alertmanager-networkPolicy.yaml

这些策略限制了只有monitoring命名空间内的Pod才能访问这些服务。执行以下命令删除它们：

kubectl delete -f manifests/prometheus-networkPolicy.yaml kubectl delete -f manifests/grafana-networkPolicy.yaml kubectl delete -f manifests/alertmanager-networkPolicy.yaml

提示：在生产环境中，建议保留网络策略并通过Ingress或API网关控制访问，而不是完全删除。

1.2 验证服务可访问性

删除策略后，检查服务类型和端口：

kubectl get svc -n monitoring

重点关注以下服务：

访问格式为：http://<节点IP>:<NodePort>

2. 首次访问指南：关键面板与核心指标解读

面对琳琅满目的监控面板，新手常感到无所适从。以下是首次访问时应重点关注的几个方面。

2.1 Grafana预置仪表板解析

Grafana默认提供了丰富的仪表板，这几个最为关键：

1. Kubernetes / Compute Resources / Cluster

   • 集群整体CPU/内存使用情况
   • 节点资源分配与利用率对比
   • 工作负载资源请求与实际使用对比

2. Kubernetes / Compute Resources / Namespace (Pods)

   • 按命名空间查看Pod资源消耗
   • 快速定位资源异常增长的Pod

3. Kubernetes / Compute Resources / Workload

   • 按工作负载(Deployment,StatefulSet等)查看资源
   • 识别配置不合理的请求/限制

2.2 Prometheus原生界面重点

在Prometheus的Graph页面，这些指标值得特别关注：

• kube_pod_container_resource_requests：容器资源请求
• kube_pod_container_resource_limits：容器资源限制
• kube_node_status_allocatable：节点可分配资源
• kube_pod_status_phase：Pod状态统计
• up：监控目标健康状态

尝试在PromQL中输入以下查询，感受监控数据的威力：

sum(kube_pod_container_resource_requests{resource="cpu"}) by (namespace)

2.3 Alertmanager默认告警规则

系统预置了一些实用的告警规则，可以通过以下命令查看：

kubectl get prometheusrules -n monitoring

重点关注：

• KubernetesAbsent：关键组件缺失告警
• KubernetesResources：资源不足告警
• KubernetesHealth：健康状态告警

3. 理解监控对象：系统自动采集了哪些数据

kube-prometheus部署后，已经自动配置了对Kubernetes核心组件的监控。了解这些监控对象，才能更好地利用数据。

3.1 系统监控的四大维度

1. 节点级监控

   • 通过node-exporter采集
   • CPU/内存/磁盘/网络等基础指标
   • 内核和系统服务状态

2. Pod和容器监控

   • cAdvisor自动采集容器指标
   • 资源使用率(CPU,内存,IO)
   • 网络流量统计

3. Kubernetes组件监控

   • API Server性能指标
   • Scheduler和Controller Manager健康状态
   • etcd存储性能指标

4. 服务发现监控

   • Service和Endpoint状态
   • Ingress请求统计
   • 自定义Pod监控发现

3.2 关键监控目标清单

以下是系统自动发现和监控的主要目标：

3.3 自定义服务发现机制

kube-prometheus通过ServiceMonitor和PodMonitor两种CRD实现灵活的服务发现。查看已配置的监控规则：

kubectl get servicemonitors -n monitoring kubectl get podmonitors -n monitoring

典型的ServiceMonitor配置示例：

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app namespace: monitoring spec: selector: matchLabels: app: example-app endpoints: - port: web interval: 30s

4. 进阶配置：从可用到好用的关键调整

基础监控运行后，还需要一些优化才能真正发挥系统威力。

4.1 持久化存储配置

默认安装使用emptyDir，重启会丢失数据。修改prometheus-prometheus.yaml添加持久卷：

spec: storage: volumeClaimTemplate: spec: storageClassName: standard resources: requests: storage: 50Gi

4.2 告警通知集成

配置Alertmanager发送告警到常用渠道（如Slack、邮件）：

receivers: - name: 'slack-notifications' slack_configs: - channel: '#monitoring-alerts' api_url: 'https://hooks.slack.com/services/...'

4.3 资源请求优化

监控系统本身也需要合理配置资源，避免影响集群性能。修改以下部署的资源请求：

• prometheus-operator
• prometheus-adapter
• grafana
• alertmanager

示例配置：

resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "1"

5. 常见问题排查指南

即使按照步骤操作，仍可能遇到各种问题。以下是几个典型场景的解决方法。

5.1 访问服务返回超时

可能原因及解决方案：

1. 网络策略未正确删除
   • 确认已删除所有networkPolicy资源
2. NodePort端口被防火墙拦截
   • 检查云平台安全组规则
3. 服务未正确暴露
   • 验证Service的type是否为NodePort

5.2 Grafana面板显示"No Data"

排查步骤：

1. 检查Prometheus数据源配置
2. 验证Prometheus是否采集到目标数据
3. 检查ServiceMonitor/PodMonitor选择器是否匹配

5.3 Prometheus容器不断重启

常见原因：

• 资源不足导致OOM
• 存储卷权限问题
• 配置语法错误

查看详细日志定位问题：

kubectl logs -f prometheus-k8s-0 -n monitoring -c prometheus

6. 监控策略最佳实践

要让监控系统真正发挥作用，需要遵循一些基本原则。

6.1 黄金指标法则

针对不同服务类型关注的四大黄金指标：

1. 延迟：服务处理请求的时间
2. 流量：服务的请求量或并发量
3. 错误：失败请求的比例
4. 饱和度：资源使用的程度

6.2 有效的告警策略

避免告警疲劳的几个技巧：

• 设置合理的阈值和持续时间
• 区分不同严重级别
• 实现告警抑制和分组
• 定期回顾和优化规则

6.3 容量规划参考

根据集群规模推荐的资源配置：