K8s系列第十三篇：K8s 监控告警实战：Prometheus + Grafana 部署与配置

前言：在上一篇文章中，我们聚焦K8s日志收集的核心需求，详细讲解了EFK/ELK方案的部署与配置，从日志收集原理、EFK与ELK的区别，到EFK完整实操、ELK备选部署，再到日志过滤、Kibana查询可视化、生产最佳实践和常见问题排错，全程实操、命令可复制，帮你彻底解决了"日志分散、无法快速排查故障"的难题，掌握了K8s应用日志的集中管理方法，为故障排查提供了有力支撑。​

重点回顾3点（衔接上一篇核心）：​

1. 日志收集的核心是"集中化"，EFK（轻量易部署）和ELK（功能强大）均为"收集→存储→可视化"三层架构，生产中小集群优先选EFK；
2. EFK部署核心顺序：Elasticsearch（存储）→Fluentd（收集，DaemonSet部署）→Kibana（可视化），需重点配置资源限制和日志过滤；
3. Kibana的核心作用是日志查询、筛选和可视化，通过创建索引模式、仪表盘，可快速定位故障、监控日志趋势。

正如上一篇结尾预告，本节课我们将进入K8s运维体系的另一个核心模块------监控告警，学习最主流的Prometheus + Grafana方案。在前面的教程中，我们解决了应用的"自愈、扩容、资源控制、日志收集"问题，但生产环境中，还有一个关键痛点：无法实时掌握K8s集群（节点、组件）和应用的运行状态，当集群资源耗尽、应用异常、组件故障时，无法及时发现，往往等到故障扩大才察觉，造成不必要的损失。​

Prometheus + Grafana是K8s集群中最常用的监控告警方案，二者分工明确、协同工作：Prometheus负责"数据采集、存储、查询"，采集集群节点、Pod、组件的运行指标（如CPU使用率、内存占用、Pod状态）；Grafana负责"数据可视化、告警配置"，将Prometheus采集的数据以图表形式展示，同时设置告警规则，当指标异常时及时通知运维人员。​

本文依然针对小白，延续系列"全程实操、命令可复制、yaml可复用"的风格，从"监控告警核心原理、Prometheus与Grafana的分工、Prometheus完整部署、Grafana部署与关联、监控指标配置、告警规则设置、生产环境最佳实践、常见问题排错"八个维度，手把手教你搭建K8s监控告警体系，解决"无法实时监控、故障无法及时发现"的问题，进一步完善K8s运维全流程，贴合生产环境需求，为后续故障排查、集群优化打下基础。​

前置要求：已搭建好K8s集群，掌握Pod、Deployment、DaemonSet、Service、EFK/ELK的基本概念和基础操作（参考前十二篇教程）；集群节点有足够的资源（建议至少2核4Gi内存，Prometheus+Grafana组件对资源有一定要求）；已部署基础应用（如Nginx、Redis），用于测试监控告警功能；已安装Helm（参考上一篇EFK部署的前置准备）。

一、先理解：K8s监控告警核心原理与组件分工

在开始实操之前，我们先搞清楚两个核心问题：K8s监控告警的原理是什么？Prometheus和Grafana各自负责什么？小白只需记住：监控告警的核心是"实时采集、异常识别、及时通知"，Prometheus负责采集存储，Grafana负责可视化和告警。

1.1 K8s监控告警核心原理

K8s集群中，集群节点、Pod、核心组件（如kube-apiserver、kube-controller-manager）、应用都会产生大量运行指标（如CPU使用率、内存占用、网络吞吐量、Pod重启次数），这些指标是判断集群和应用运行状态的关键。监控告警的核心流程分为4步，简单易懂：

1. 指标采集：通过Prometheus及其组件，定时采集集群节点、Pod、组件、应用的运行指标；

2. 指标存储：将采集到的指标数据，统一存储到Prometheus的时序数据库中（支持按时间维度查询）；

3. 异常识别：通过配置告警规则，设定指标的正常范围，当指标超出范围时，判定为异常；

4. 及时通知：当检测到异常时，通过Grafana（或Prometheus自身）发送告警通知（如邮件、企业微信、钉钉），提醒运维人员及时处理。

补充说明：Prometheus采集指标的方式是"主动拉取"，即Prometheus主动向被监控对象（如节点、Pod）发送请求，获取指标数据，无需被监控对象主动推送，配置简单、易于维护。

1.2 Prometheus与Grafana的核心分工（小白必记）

Prometheus和Grafana是监控告警体系的"黄金搭档"，二者分工明确、缺一不可，小白需清晰区分二者的作用，避免混淆：

组件	核心作用	核心功能	通俗理解
Prometheus	指标采集、存储、查询	1. 主动拉取被监控对象的指标；2. 存储时序指标数据；3. 提供PromQL查询语言，查询指标数据	相当于"数据采集员+数据库"，负责把所有监控数据收集起来、存好，供人查询
Grafana	数据可视化、告警配置	1. 关联Prometheus，读取指标数据；2. 以图表（折线图、柱状图等）形式展示数据；3. 配置告警规则，发送告警通知	相当于"数据展示员+告警员"，负责把枯燥的数据变成直观的图表，同时在异常时及时提醒

关键说明：Prometheus自身也支持简单的告警配置，但功能有限，无法实现复杂的告警规则和多渠道通知；Grafana的可视化和告警功能更强大、更灵活，是生产环境的首选搭配，本文将重点讲解Prometheus+Grafana的协同部署与配置。

二、实战1：Prometheus 完整部署（核心，指标采集与存储）

Prometheus部署分为"核心组件部署、监控目标配置、持久化配置"三部分，我们使用Helm部署（简化部署流程，命令可直接复制），同时配置资源限制、健康检查，确保Prometheus稳定运行，能够正常采集集群和应用的指标数据。

2.1 前置准备：添加Prometheus Helm仓库

若之前未添加Prometheus相关Helm仓库，先执行以下命令添加（已添加可跳过）：

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

# 查看仓库是否添加成功
helm repo list

2.2 部署Prometheus核心组件

Prometheus核心组件包括：Prometheus Server（核心，负责采集、存储、查询）、Node Exporter（采集节点指标，如CPU、内存）、kube-state-metrics（采集K8s核心组件指标，如Pod状态、Deployment副本数）。我们一次性部署所有核心组件，简化配置。

# 1. 创建命名空间（用于隔离监控组件，便于管理）
kubectl create namespace monitoring

# 2. 部署Prometheus（包含Server、Node Exporter、kube-state-metrics）
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring \
  --set prometheus.prometheusSpec.resources.requests.cpu=1 \
  --set prometheus.prometheusSpec.resources.requests.memory=2Gi \
  --set prometheus.prometheusSpec.resources.limits.cpu=2 \
  --set prometheus.prometheusSpec.resources.limits.memory=4Gi \
  --set grafana.enabled=false  # 先不部署Grafana，后续单独部署，便于分步讲解
  --set persistence.enabled=true  # 开启持久化，避免指标数据丢失（生产环境必开）
  --set persistence.size=10Gi  # 持久化存储大小，可根据需求调整

# 3. 查看Prometheus相关Pod状态，确保所有Pod处于Running状态
kubectl get pods -n monitoring
# 重点查看3类Pod：prometheus-server-xxx、node-exporter-xxx（每个节点1个）、kube-state-metrics-xxx

# 4. 查看Prometheus Service状态，确认服务正常暴露
kubectl get svc -n monitoring | grep prometheus-server

关键说明：

• Node Exporter以DaemonSet方式部署，每个节点部署一个Pod，确保能采集所有节点的硬件和系统指标（CPU、内存、磁盘、网络）；

• kube-state-metrics以Deployment方式部署，负责采集K8s核心组件的指标（如Pod重启次数、Deployment副本数、Service状态）；

• 生产环境必须开启持久化（persistence.enabled=true），否则Prometheus重启后，之前采集的指标数据会丢失；

• Prometheus默认端口9090（用于Web界面访问和指标查询）。

2.3 访问Prometheus Web界面，验证指标采集

Prometheus提供Web界面，可用于查询指标、查看监控目标、验证采集状态，我们通过端口转发访问Web界面：

# 端口转发，访问Prometheus Web界面（默认端口9090）
kubectl port-forward svc/prometheus-server -n monitoring 9090:80

# 打开浏览器，访问http://localhost:9090，进入Prometheus Web界面

验证步骤（小白必做）：

1. 查看监控目标：点击Web界面顶部"Status"→"Targets"，查看所有监控目标的状态，若"State"均为"UP"，说明指标采集正常；

2. 查询节点CPU使用率：在顶部搜索框中输入PromQL查询语句node_cpu_seconds_total{mode!="idle"}，点击"Execute"，即可看到所有节点的CPU使用指标；

3. 查询Pod重启次数：输入查询语句 kube_pod_container_restarts_total，即可看到所有Pod的重启次数指标。

补充说明：若部分监控目标状态为"Down"，需查看对应Pod的日志（如node-exporter），排查采集失败原因（如权限不足、网络问题）。

2.4 配置监控目标（自定义应用监控）

默认情况下，Prometheus会自动采集K8s节点、核心组件的指标，但我们部署的自定义应用（如Nginx、Redis），需要手动配置监控目标，让Prometheus采集其指标。以Nginx为例，讲解自定义应用监控配置。

# 创建nginx-monitor.yaml文件（配置Nginx监控目标）
apiVersion: v1
kind: ServiceMonitor
metadata:
  name: nginx-monitor
  namespace: monitoring
  labels:
    release: prometheus  # 与Prometheus的release标签一致，确保能被Prometheus识别
spec:
  selector:
    matchLabels:
      app: nginx-log  # 匹配Nginx Pod的标签（需与Nginx Deployment的labels一致）
  namespaceSelector:
    matchNames:
      - default  # Nginx应用所在的命名空间（根据实际情况调整）
  endpoints:
  - port: http  # Nginx Service的端口名称（需与Nginx Service的port名称一致）
    path: /metrics  # Nginx指标暴露的路径（需部署Nginx监控插件，见下文）
    interval: 15s  # 采集间隔，每15秒采集一次指标

# 1. 部署Nginx监控插件（nginx-prometheus-exporter），用于暴露Nginx指标
kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-prometheus-exporter/master/deployments/kubernetes/nginx-prometheus-exporter.yaml

# 2. 修改Nginx Deployment，添加监控插件关联（确保能采集Nginx指标）
kubectl edit deployment nginx-log-test  # 编辑之前部署的Nginx Deployment
# 在containers中添加以下内容（与nginx容器同级）
- name: nginx-exporter
  image: nginx/nginx-prometheus-exporter:1.1.0
  ports:
  - containerPort: 9113
  env:
  - name: NGINX_STATUS_URI
    value: "http://localhost:80/nginx_status"

# 3. 部署ServiceMonitor，配置Prometheus监控Nginx
kubectl apply -f nginx-monitor.yaml

# 4. 验证：访问Prometheus Web界面，查看Targets，确认nginx-monitor的状态为UP
# 5. 查询Nginx指标：输入查询语句 nginx_http_requests_total，查看Nginx请求总数

关键说明：不同应用的监控配置类似，核心是"部署对应应用的监控插件、创建ServiceMonitor、匹配Pod标签和命名空间"，确保Prometheus能主动拉取应用指标。

三、实战2：Grafana 部署与关联Prometheus（可视化与告警）

部署完Prometheus后，我们部署Grafana，关联Prometheus数据源，实现指标可视化，同时配置告警规则，确保异常时能及时收到通知。Grafana的部署同样使用Helm，配置简单、可直接复用。

3.1 部署Grafana

# 部署Grafana（与Prometheus同命名空间，便于管理）
helm install grafana prometheus-community/grafana -n monitoring \
  --set resources.requests.cpu=500m \
  --set resources.requests.memory=1Gi \
  --set resources.limits.cpu=1 \
  --set resources.limits.memory=2Gi \
  --set persistence.enabled=true \
  --set persistence.size=5Gi \
  --set adminPassword="Admin@123"  # 自定义Grafana管理员密码，生产环境建议修改为复杂密码

# 查看Grafana Pod状态，确保处于Running状态
kubectl get pods -n monitoring | grep grafana

# 查看Grafana Service状态
kubectl get svc -n monitoring | grep grafana

3.2 访问Grafana Web界面，登录并关联Prometheus数据源

Grafana默认端口3000，我们通过端口转发访问Web界面，然后关联Prometheus数据源，让Grafana能读取Prometheus的指标数据。

# 端口转发，访问Grafana Web界面（默认端口3000）
kubectl port-forward svc/grafana -n monitoring 3000:80

# 打开浏览器，访问http://localhost:3000，进入Grafana登录界面
# 用户名：admin，密码：Admin@123（刚才部署时设置的密码）

关联Prometheus数据源步骤（小白一步一步来）：

1. 登录Grafana后，点击左侧"Configuration"（齿轮图标）→"Data Sources"；

2. 点击"Add data source"，选择"Prometheus"；

3. 在"URL"字段中，输入Prometheus Service的地址：http://prometheus-server.monitoring.svc.cluster.local:80（格式：http://<service名称>.<命名空间>.svc.cluster.local:<端口>）；

4. 其他配置保持默认，点击底部"Save & Test"，若提示"Data source is working"，说明关联成功。

3.3 导入Grafana仪表盘（可视化指标，无需手动配置）

Grafana社区提供了大量现成的仪表盘模板（针对K8s节点、Pod、Nginx等），我们无需手动创建图表，直接导入模板即可实现指标可视化，节省时间。

# 导入K8s节点监控仪表盘（模板ID：8919，最常用的节点监控模板）
1. 登录Grafana，点击左侧"Dashboards"→"Import"；
2. 在"Import via grafana.com"输入框中，输入模板ID：8919，点击"Load"；
3. 在"Data source"下拉框中，选择我们刚才关联的Prometheus数据源，点击"Import"；
4. 导入成功后，即可看到K8s所有节点的监控图表（CPU使用率、内存占用、磁盘使用率、网络吞吐量等）。

# 导入Nginx监控仪表盘（模板ID：9614）
1. 再次点击"Dashboards"→"Import"，输入模板ID：9614，点击"Load"；
2. 选择Prometheus数据源，点击"Import"；
3. 导入成功后，即可看到Nginx的监控图表（请求总数、请求延迟、错误率等）。

补充说明：Grafana模板市场（https://grafana.com/grafana/dashboards/）有大量现成模板，可根据需要搜索导入（如Redis、MySQL监控模板），模板ID在模板详情页可查看。

3.4 配置告警规则（核心，异常及时通知）

可视化完成后，我们配置告警规则，当监控指标超出正常范围时，Grafana会发送告警通知。以"节点CPU使用率过高""Nginx请求错误率过高"为例，讲解告警配置方法。

# 配置告警规则步骤（以节点CPU使用率过高为例）
1. 进入节点监控仪表盘（模板ID：8919），点击图表右上角的"Edit"；
2. 切换到"Alert"标签页，点击"Create Alert"；
3. 配置告警名称：Node CPU Usage Too High（节点CPU使用率过高）；
4. 配置告警条件：
   - Query：选择Prometheus数据源，输入查询语句：avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) * 100
   - Condition：Is above，阈值设置为80（即CPU使用率超过80%触发告警）；
   - For：5m（持续5分钟超过阈值才触发告警，避免误告警）；
5. 配置告警通知：
   - 点击"Notifications"→"Add notification channel"；
   - 选择通知方式（如企业微信、钉钉、邮件），填写对应配置（以企业微信为例，需填写企业微信机器人WebHook地址）；
   - 保存通知渠道后，选择该渠道作为告警通知方式；
6. 点击"Save"，完成告警规则配置。

# 配置Nginx请求错误率过高告警（类似步骤）
1. 进入Nginx监控仪表盘（模板ID：9614），编辑错误率图表；
2. 配置查询语句：sum(nginx_http_requests_total{status=~"5..|4.."}) / sum(nginx_http_requests_total) * 100
3. 条件：Is above，阈值设置为5（错误率超过5%触发告警），持续时间3m；
4. 选择相同的通知渠道，保存告警规则。

关键说明：

• 告警阈值需根据生产环境实际情况调整（如CPU使用率阈值可设置为70%-80%）；

• 持续时间（For）用于避免误告警，防止指标短暂波动导致的不必要通知；

• 生产环境建议配置多渠道通知（如企业微信+邮件），确保运维人员能及时收到告警。

3.5 测试告警功能（验证是否正常通知）

配置完告警规则后，我们模拟异常场景，测试告警是否能正常触发并发送通知：

# 模拟节点CPU使用率过高（在节点上执行以下命令，消耗CPU资源）
kubectl exec -it <node-exporter-pod名称> -n monitoring -- stress --cpu 2  # 模拟2个CPU核心满负载

# 查看Grafana告警状态：
1. 访问Grafana，点击左侧"Alerting"→"Alerts"；
2. 查看刚才配置的告警规则，等待5分钟后，状态会从"OK"变为"Alerting"；
3. 检查通知渠道（如企业微信），是否收到告警通知。

# 测试完成后，停止CPU消耗命令
kubectl exec -it <node-exporter-pod名称> -n monitoring -- pkill stress

验证结果：若Grafana告警状态变为"Alerting"，且能收到通知，说明告警配置正常；若未收到通知，需检查通知渠道配置（如WebHook地址是否正确）、告警规则条件是否合理。

四、进阶配置：Prometheus指标存储优化与告警优化

默认配置下，Prometheus的指标存储和告警可能存在"存储占用过大、误告警过多"等问题，本节讲解进阶配置，优化存储和告警，适配生产环境需求。

4.1 Prometheus指标存储优化（避免磁盘满）

Prometheus存储的时序指标数据会不断积累，若不进行优化，会导致磁盘空间耗尽，影响Prometheus正常运行。主要优化方式有3种：

# 1. 配置指标保留时间（删除过期指标）
# 编辑Prometheus配置，设置指标保留时间为7天（生产环境可根据需求调整，如30天）
kubectl edit prometheus prometheus-server -n monitoring
# 在spec中添加以下内容：
retention: 7d  # 指标保留7天，超过7天的指标自动删除
retentionSize: 10Gi  # 存储大小限制，超过10Gi自动删除最早的指标

# 2. 过滤无用指标（减少存储压力）
# 编辑Prometheus配置，添加指标过滤规则，只保留有用的指标
kubectl edit prometheus prometheus-server -n monitoring
# 在spec.serviceMonitorSelector.matchLabels中，添加标签过滤，只匹配需要的ServiceMonitor
# 或在ServiceMonitor中，配置指标过滤，排除无用指标

# 3. 开启指标采样（降低采集频率）
# 编辑ServiceMonitor，调整采集间隔（interval），如从15s改为30s，减少指标数量
kubectl edit servicemonitor nginx-monitor -n monitoring
# 修改endpoints.interval为30s

# 配置完成后，重启Prometheus，使配置生效
kubectl rollout restart statefulset prometheus-server -n monitoring

4.2 告警优化（减少误告警，提升准确性）

生产环境中，误告警会增加运维人员的负担，我们可以通过以下方式优化告警，提升准确性：

• 合理设置阈值和持续时间：根据应用和集群的实际运行情况，调整告警阈值，避免设置过低导致误告警；持续时间设置为3-5分钟，过滤短暂波动；

• 配置告警分组：将同一类型的告警（如节点相关告警、应用相关告警）分组，避免大量告警同时发送，便于运维人员分类处理；

• 配置告警抑制：当某个核心告警触发时（如节点宕机），抑制该节点相关的其他告警（如CPU使用率过高），避免重复告警；

• 定期调整告警规则：根据集群运行状态，定期优化告警规则，删除无用告警，调整阈值和持续时间。

五、生产环境最佳实践（面试必问）

结合前面的实操，本节总结Prometheus + Grafana生产环境最佳实践，帮助小白规范配置，避免踩坑，同时应对面试提问，重点关注"稳定性、可靠性、可维护性"三个核心。

5.1 组件部署最佳实践

• Prometheus：

  • 生产环境建议部署Prometheus集群（高可用），避免单节点故障导致监控中断；

  • 开启持久化存储（PV/PVC），选择高性能存储（如SSD），确保指标数据安全，同时配置保留时间和存储大小限制；

  • 配置资源限制（至少1核2Gi内存），根据集群规模调整，避免资源不足导致Prometheus崩溃；

  • 定期备份Prometheus数据，避免数据丢失。

• Grafana：

  • 配置登录认证和权限管理，创建不同角色的用户（如管理员、运维人员），分配不同的权限（如查看权限、编辑权限）；

  • 开启持久化存储，备份仪表盘和告警规则配置，避免配置丢失；

  • 定期升级Grafana版本，修复漏洞，提升稳定性和功能。

• 监控组件：

  • Node Exporter必须部署在所有节点，确保能采集所有节点的指标；

  • 针对不同应用，部署对应的监控插件（如Nginx Exporter、Redis Exporter），确保能采集应用层面的指标；

  • 使用ServiceMonitor统一管理监控目标，便于维护和扩展。

5.2 监控指标最佳实践

• 监控范围全覆盖：需监控K8s集群（节点、核心组件）、应用（Pod、Service）、基础设施（磁盘、网络），确保无监控盲区；

• 指标筛选精细化：过滤无用指标，只保留能反映集群和应用运行状态的关键指标，减少存储压力；

• 采集间隔合理化：核心指标（如CPU、内存）采集间隔设置为15-30s，非核心指标（如磁盘使用率）可设置为1-5分钟，平衡监控精度和资源消耗。

5.3 告警最佳实践

• 告警分级：将告警分为紧急告警（如节点宕机、应用不可用）、重要告警（如CPU使用率过高）、一般告警（如Pod重启），不同级别告警采用不同的通知方式和处理优先级；

• 多渠道通知：配置企业微信、钉钉、邮件等多渠道通知，确保运维人员能及时收到告警，避免遗漏；

• 定期演练：定期模拟异常场景，测试告警功能是否正常，及时发现并修复告警配置问题；

• 告警复盘：对触发的告警进行复盘，分析告警原因，优化告警规则，减少误告警。

六、常见问题排错（小白必看）

Prometheus + Grafana的部署和配置过程中，小白很容易遇到指标采集失败、Grafana无法关联Prometheus、告警不触发等问题。本节整理了7个最常见的问题，给出详细的原因分析和解决方法，帮你快速排错。

1. 问题1：Prometheus监控目标状态为"Down"，无法采集指标

原因：1. 被监控对象（如Node Exporter、Nginx）未正常运行；2. 网络问题，Prometheus无法访问被监控对象；3. 监控目标配置错误（如标签不匹配、端口错误）。

解决：1. 查看被监控对象的Pod状态，确保处于Running状态，查看日志排查启动失败原因；2. 检查Prometheus Pod与被监控对象Pod之间的网络连通性（kubectl exec -it -- ping <被监控对象IP>）；3. 核对ServiceMonitor配置，确保标签、命名空间、端口正确。

2. 问题2：Grafana无法关联Prometheus数据源，提示"Data source is not working"

原因：1. Prometheus未正常运行，或Service地址错误；2. 网络策略限制，Grafana无法访问Prometheus；3. Prometheus端口配置错误。

解决：1. 查看Prometheus Pod和Service状态，确保正常运行；2. 核对Prometheus Service地址（格式：http://<service名称>.<命名空间>.svc.cluster.local:<端口>）；3. 检查网络策略，允许Grafana所在命名空间访问Prometheus所在命名空间；4. 确认Prometheus端口正确（默认80，对应Service的端口）。

3. 问题3：Grafana仪表盘无数据，显示"No data"

原因：1. Prometheus未采集到对应指标（监控目标状态为Down）；2. 仪表盘模板ID错误，或模板与Prometheus指标不匹配；3. 时间范围选择错误（仪表盘时间范围与指标产生时间不匹配）。

解决：1. 检查Prometheus监控目标状态，确保指标采集正常；2. 核对仪表盘模板ID，选择与Prometheus版本、监控组件匹配的模板；3. 调整Grafana仪表盘的时间范围（如选择"最近1小时"）。

4. 问题4：告警不触发，或触发后未收到通知

原因：1. 告警规则配置错误（如查询语句错误、阈值设置过高、持续时间过长）；2. 通知渠道配置错误（如WebHook地址错误、权限不足）；3. 指标未达到告警阈值。

解决：1. 检查告警规则的查询语句，在Prometheus中执行，确认能查询到指标；2. 调整告警阈值和持续时间，模拟异常场景测试；3. 核对通知渠道配置（如企业微信机器人WebHook是否正确），测试通知渠道是否能正常发送消息。

5. 问题5：Prometheus磁盘空间满，无法正常运行

原因：1. 未配置指标保留时间，日志长期积累；2. 未过滤无用指标，指标数量过多；3. 持久化存储大小设置过小。

解决：1. 手动删除过期的指标数据（进入Prometheus Pod，删除/data目录下的旧数据）；2. 配置指标保留时间和存储大小限制；3. 过滤无用指标，减少指标采集量；4. 扩大持久化存储大小。

6. 问题6：Node Exporter启动失败，报错"permission denied"

原因：Node Exporter需要访问节点的系统文件（如/proc、/sys），获取节点指标，但权限不足。

解决：编辑Node Exporter DaemonSet，添加权限配置（如添加securityContext字段，设置privileged: true），重启Node Exporter Pod。

7. 问题7：Prometheus重启后，之前的指标数据丢失

原因：未开启持久化存储，或持久化配置错误（如PV/PVC未正确挂载）。

解决：1. 重新部署Prometheus，开启持久化（--set persistence.enabled=true）；2. 检查PV/PVC状态，确保正常挂载；3. 定期备份Prometheus数据，避免数据丢失。

七、总结及下一篇预告

本文详细讲解了K8s监控告警的核心------Prometheus + Grafana部署与配置，从监控告警核心原理、组件分工，到Prometheus完整部署、Grafana部署与关联，再到监控指标配置、告警规则设置、生产环境最佳实践和常见问题排错，全程实操、命令可复制，帮你彻底解决了"无法实时监控集群状态、故障无法及时发现"的难题，掌握了K8s集群和应用的监控告警方法，进一步完善了K8s运维体系。

重点记住3点：

1. 监控告警的核心是"实时采集、异常识别、及时通知"，Prometheus负责指标采集与存储，Grafana负责可视化与告警，二者协同工作；

2. Prometheus部署核心：部署核心组件（Server、Node Exporter、kube-state-metrics）、配置监控目标、开启持久化，确保指标采集正常；

3. 生产环境中，需优化指标存储和告警规则，配置多渠道通知，定期维护，确保监控告警体系稳定、可靠，能及时发现并通知故障。

截至本文，我们已完成K8s系列13篇内容的学习，从K8s基础入门，到核心组件、服务暴露、应用调度、健康检查、资源限制、日志收集，再到本节课的监控告警，已覆盖K8s运维的核心模块，后续2篇将聚焦故障排查和集群优化，带你彻底掌握K8s运维全流程，实现从"会用K8s"到"用好K8s"的跨越。

下一篇文章，我们将学习K8s运维的核心技能------《K8s 故障排查实战：常见故障定位与解决方法》，带你深入掌握K8s集群和应用的常见故障（如Pod启动失败、Service无法访问、集群节点异常）的定位思路和解决方法，结合前面的日志收集、监控告警知识，形成"监控→告警→排查→解决"的完整闭环，贴合生产环境需求，敬请期待！

最后，如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注，后续会持续更新K8s系列实战文章（共15篇），从入门到精通，带你轻松搞定K8s！