kube-prometheus-stack实战：K8S监控部署、告警配置与生产避坑指南

简介：面向云原生运维、SRE 与 K8s 开发工程师，这一资源合集围绕 kube-prometheus-stack 在 Kubernetes 集群中的完整落地，整理了监控与告警系统的部署配置案例，能够帮助读者解决集群可观测性不足、告警规则难配置等问题。压缩包内共 299 个文件，其中 272 个 yaml 定义了各组件核心配置，8 个 tpl 与 1 个 json 提供模板及自定义 Grafana 面板，8 个 md 文档给出说明与部署指南，另有 helmignore、Chart.lock 等元数据，整体约 690KB，结构清晰便于对照学习。内容涵盖 Prometheus、Alertmanager、Grafana 等组件的关键配置，并包含 ServiceMonitor 示例、告警规则和仪表板模板。yaml 文件对应部署清单，tpl 与 json 可灵活调整，md 文档帮助理解整体架构，适合在测试或生产集群中直接参考复用。目前已有 783 人学习下载，适合需要为 K8S 搭建完整、可扩展监控告警体系的中高级工程师按需学习。

1. 从一条半夜的告警电话说起：为什么要用kube-prometheus-stack

凌晨两点被电话叫醒，某业务的Pod频繁重启，但等打开Dashboard看的时候，集群已经自己恢复了。这个场景在K8S运维里太常见了——不是集群没有问题，而是问题发生的时候，没有任何监控系统告诉你。后来我把Prometheus、Alertmanager、Grafana这些组件一个个手动部署到集群里，踩了一堆依赖和配置的坑，才发现有kube-prometheus-stack这样一个打包好的方案，它把监控K8S集群所需的所有组件、告警规则、Dashboard预置好，一条Helm命令就能拉起一套完整的监控告警系统。

这篇文章要解决的就是三件事：第一，kube-prometheus-stack到底是什么、值不值得用；第二，怎么在你的集群里把它部署起来并配置告警通道；第三，生产环境会遇到哪些坑，以及怎么去排查。文章覆盖从原理到命令、从默认配置到参数调优的全过程，适合已经能操作K8S集群、但对监控体系还没有系统搭建过的开发者。新手可以照着部署步骤走，熟手可以直接跳到告警配置和排错部分看边界条件。

2. kube-prometheus-stack解决了什么问题：组件架构与选型逻辑

2.1 为什么不用裸装Prometheus：依赖地狱与配置分散

如果自己手动搭建监控体系，第一步就会遇到依赖问题。Prometheus要采集K8S组件指标，需要kube-state-metrics来把集群对象的状态转成指标；要采集节点资源，需要node-exporter；告警需要Alertmanager；展示需要Grafana；还要为Prometheus配置RBAC、ServiceMonitor、PodMonitor这些CRD资源才能动态发现目标。这些组件各自有版本兼容要求，Prometheus Operator本身要适配K8S版本，kube-state-metrics要适配K8S和Prometheus的版本，Grafana又有一堆插件和依赖。手动部署一套，光理清依赖关系就要花掉半天时间，而且后续升级是更大的麻烦。

我见过某开发者的集群里，Prometheus和Alertmanager版本相差超过两个大版本，导致告警配置格式不兼容，Alertmanager的route配置写对了却一直不生效。这个问题的根源在于：K8S监控不是单个组件的事，而是一整套生态。kube-prometheus-stack之所以值得作为基准方案，就是因为它把Prometheus Operator、Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics、Prometheus Adapter等组件的版本和配置打包成一个整体，通过Helm chart进行统一管理。每个组件之间的兼容版本已经测试过，你不需要自己去对齐。

kube-prometheus-stack的另一个价值是它预置了告警规则。K8S集群该监控什么、什么情况该告警，这些经验沉淀在规则文件里：Pod频繁重启、节点NotReady、证书过期、API Server延迟过高，这些规则开箱即用。自己从零写这些规则，需要读大量官方文档和社区经验，没有半年积累写不全。

2.2 核心组件关系：Prometheus Operator、CRD与ServiceMonitor

从架构上看，kube-prometheus-stack是以Prometheus Operator为核心的控制闭环。Prometheus Operator本身是一个控制器，它监听两个核心CRD：Prometheus和Alertmanager。你在K8S里创建一个Prometheus类型的CRD资源，Operator就会自动创建并管理对应的Prometheus StatefulSet，包括配置、存储卷、安全上下文。创建Alertmanager类型的CRD，同样会自动拉起Alertmanager实例。这解决了手动维护Prometheus配置和副本的问题。

关键的指标采集机制靠ServiceMonitor和PodMonitor这两个CRD。ServiceMonitor定义了如何从一组Service发现目标并采集指标：它通过selector选中Service，然后定义endpoints里的端口、路径、间隔。Prometheus Operator会监听ServiceMonitor的创建和更新，自动把采集配置同步到Prometheus里。这意味着你部署一个新服务，只要给它写一个ServiceMonitor，Prometheus就会自动开始采集，不用重启Prometheus，不用手动编辑配置文件。

这套机制解决了动态发现的问题。K8S集群里的Pod IP是随时变化的，手动在Prometheus配置里写死target根本没有可操作性。而ServiceMonitor和PodMonitor通过标签选择器匹配目标，Pod重建后依然能被发现和采集。在kube-prometheus-stack中，核心组件的采集配置都是预置的ServiceMonitor：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、etcd、coredns等组件都有对应的采集配置。你自己部署的应用，只需要按同样方式写一个ServiceMonitor即可。

2.3 版本选择：K8S、Helm与Chart的版本对应关系

部署前第一步是确认版本兼容，这一步跳过后面必踩坑。kube-prometheus-stack的chart版本在持续更新，每个chart版本对K8S版本有最低要求，同时它内部锁定了Prometheus Operator和Prometheus等组件的版本。在实际操作中，我一般这样选版本：先查看当前K8S集群的版本，比如1.28，然后看chart的README或values.yaml里的kubeVersion字段，选择支持该K8S版本的最新的chart版本。

具体版本对应关系不会写死在代码里，但可以通过一条命令验证。把chart下载到本地后，查看values.yaml里的defaultRules和kubeVersion限制。常见做法是拉取chart仓库索引，找到与K8S版本兼容的chart版本。如果K8S是1.26到1.29这样的跨度，选择一个支持这个范围的中段版本即可，不必追求最新。

提示：优先使用和集群同大版本的chart版本，不要用太旧的chart去部署新版K8S，组件之间的兼容性在跨大版本时最容易出问题。

2.4 存储与数据持久化：StatefulSet与PVC的规划

Prometheus是StatefulSet部署，数据写在PVC里。在生产环境，监控数据本身也很重要，不能容忍Pod重建后数据全丢。kube-prometheus-stack默认可能不启用持久化存储，或者用emptyDir，这取决于你在values.yaml里的配置。我的建议是无论如何都要开启持久化，不要让监控数据承担Pod重建的风险。

存储类的选择取决于你的基础设施。如果在云厂商托管的K8S上，通常有默认的StorageClass，直接指定即可。在自建集群里，要考虑用本地存储还是网络存储。Prometheus的数据写入模式是顺序写为主，随机读取发生在查询时。本地SSD性能最好，但要处理节点故障时数据丢失的问题；网络存储比如Ceph或NFS，性能不如本地盘，但数据不随节点迁移而丢失。我的方案是：如果集群节点不多，用本地盘加副本的方式；如果追求数据可靠性，用网络存储，但要为PVC设置合理的requests大小。

Prometheus的存储参数有两个关键配置：retention（数据保留时间）和retentionSize（数据保留大小）。在values.yaml里通过prometheus.prometheusSpec.retention设置保留时间，比如30d。retentionSize控制最大存储量，比如50GB，达到上限后Prometheus会删除最旧的数据。这两个参数要配合PVC大小来规划，否则可能出现PVC没满但retentionSize先达到、数据被提前删除的情况，也可能出现PVC写满导致Prometheus无法写入的情况。

3. 完整部署流程：从values.yaml到生产可用

3.1 添加Helm仓库与下载Chart：最小准备动作

部署kube-prometheus-stack的第一步是准备Helm环境。确认Helm版本在3.8以上，然后添加Prometheus社区仓库。使用下面的命令：

# 添加prometheus-community仓库并更新索引 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 查看可用的版本号 helm search repo prometheus-community/kube-prometheus-stack

这段命令执行后，你先看到仓库添加成功的提示，然后update会拉取最新索引，最后search会列出所有可用的chart版本。在做下一步之前，建议先记录当前K8S版本，再对照chart版本。你可以在values.yaml里后续改动所有配置，但现在先不直接install，因为默认配置大概率不适合你的集群。

3.2 生成定制values.yaml：四个必改参数

直接使用默认values部署可以跑起来，但生产环境有几个参数必须定制。我不会从头写整个values文件，而是用默认values做底子，然后通过自定义覆盖。先导出默认值到文件里：

helm show values prometheus-community/kube-prometheus-stack > /tmp/kps-values.yaml

导出后不要直接编辑这个文件再install，这样后续升级chart时容易丢失定制内容。推荐的方式是创建一个只包含你修改项的values.yaml，Helm会把默认值和你的修改合并。下面这个文件是我在一套生产集群上的最小定制：

# custom-values.yaml prometheus: prometheusSpec: retention: 30d retentionSize: 40GB storageSpec: volumeClaimTemplate: spec: storageClassName: local-path accessModes: ["ReadWriteOnce"] resources: requests: storage: 50Gi resources: requests: cpu: 500m memory: 2Gi limits: cpu: 2 memory: 8Gi alertmanager: enabled: true alertmanagerSpec: storage: volumeClaimTemplate: spec: storageClassName: local-path accessModes: ["ReadWriteOnce"] resources: requests: storage: 10Gi resources: requests: cpu: 100m memory: 256Mi grafana: persistence: enabled: true storageClassName: local-path size: 10Gi adminPassword: "YourStrongPassword" grafana.ini: [server] root_url: http://grafana.example.com

这个定制文件里，prometheus.prometheusSpec.retention和retentionSize控制数据保留策略，storageSpec声明了存储卷的大小、类型和访问模式。resources为Prometheus设置了资源请求和限制，防止它在指标采集量大时耗尽节点内存。alertmanager部分同样启用了持久化和资源限制。grafana的adminPassword覆盖默认密码，root_url用于后续接域名反代时保证回调地址正确。

执行安装命令前需要注意命名空间。kube-prometheus-stack的组件有一些集群级资源（比如CRD和ClusterRole），所以建议把整个部署放在monitoring命名空间：

helm install kps prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --create-namespace \ -f custom-values.yaml

安装过程会创建CRD、RBAC资源、各个组件的Deployment和StatefulSet。等一分钟后，查看Pod状态：

kubectl -n monitoring get pods

正常状态下，prometheus-operator、alertmanager、grafana、kube-state-metrics、node-exporter这几个组件的Pod都会进入Running状态。如果某个Pod一直Pending，优先查看事件：kubectl -n monitoring describe pod 。最常见的原因是PVC没有绑定到可用的StorageClass。

3.3 ServiceMonitor示例：为你的应用接入监控

kube-prometheus-stack部署好之后，你最先想做的是监控自己的业务应用。以部署在default命名空间的一个Web服务为例，假设这个Service叫web-service，它暴露了/metrics端口。要接入Prometheus采集，需要创建一个ServiceMonitor：

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

这里selector.matchLabels必须匹配Service的标签，endpoints里的port是Service里定义的端口名，不是端口号数字。如果Service端口没有命名，要在Service定义里先补上name: metrics。创建后，查看Prometheus的采集目标：

kubectl -n monitoring port-forward svc/kps-prometheus-operated 9090:9090

浏览器打开localhost:9090，在Status -> Targets页面里搜索namespace="default"，就能看到新的采集目标出现，状态为UP。这一步能通，说明ServiceMonitor的机制在起作用。如果状态是DOWN，最常见的错误是端口名不匹配或Service的标签没对上。

3.4 Grafana接入：预置Dashboard与数据源验证

安装完成后，Grafana一般不需要手动配置数据源，因为kube-prometheus-stack的初始化配置里已经把prometheus数据源写好。但你需要确认Grafana的Dashboard是否都正常加载。访问Grafana的方式，我先用端口转发验证：

kubectl -n monitoring port-forward svc/kps-grafana 80:80

浏览器打开localhost:80，用admin和你在values里设置的密码登录。左侧Dashboards菜单里应该能看到Kubernetes相关的预置面板，比如Kubernetes / Pods、Kubernetes / Nodes等。打开Kubernetes / Pods，如果数据源连接正常，图表里会有数据在动。

如果某个Dashboard显示No data，不要慌。先切到数据源页面，用Explore功能查一下查询是否返回数据。比如执行up这个查询，看是否有时序数据返回。如果Explore也没有数据，说明Prometheus采集本身就出了问题，需要回到ServiceMonitor和目标状态去排查，先确认核心的kubelet和apiserver采集目标都是UP状态。

3.5 参数调优清单：按集群规模设置资源

不同规模的集群，资源需求量差很多。以下是一套按节点数量分级的参数建议，可以作为初始配置的参考：

采集间隔和指标量的关系是：间隔越短，每秒写入的数据点越多，存储增长越快。如果retention时间较长，采集间隔就不要设太短。节点数量多的时候，kube-state-metrics产生的指标数量也会上升，它本身也会吃CPU和内存，需要留意它的资源使用。

4. 告警系统配置：从默认规则到业务级告警

4.1 默认告警规则的生效机制与覆盖范围

kube-prometheus-stack内置的告警规则是按defaultRules这个开关来控制的。默认开启，规则覆盖了K8S核心组件、节点状态、Prometheus自身运行状态、ETCD、证书过期等维度。这些规则的表达式和阈值是社区经验沉淀下来的，比如KubePodCrashLooping、KubeNodeNotReady、KubeCPUOvercommit等，触发后对应一个告警名称，Alertmanager根据route决定发给谁。

默认规则在values.yaml里的结构是defaultRules.rules，每个子项代表一个规则组。以节点内存压力为例，规则表达式大概形式是sum by (node) (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1，触发条件持续2分钟后产生告警，等级是warning。这些规则对于刚部署的集群来说是足够用的，不建议开始就大改。默认规则的意义在于先兜底，保证集群出大问题时无论如何都能收到告警。

4.2 自定义告警规则：PrometheusRule写法和触发条件调参

业务监控要接入告警，需要创建PrometheusRule资源。和ServiceMonitor一样，这也是Prometheus Operator的CRD。下面是一个针对业务应用设计自定义告警的例子：

apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: web-service-rules namespace: default spec: groups: - name: web-service-alerts rules: - alert: WebServiceHighErrorRate expr: | sum(rate(http_requests_total{job="web-service", status=~"5.."}[5m])) / sum(rate(http_requests_total{job="web-service"}[5m])) > 0.05 for: 10m labels: severity: critical annotations: summary: "Web Service 5xx error rate high" description: "当前5xx比例已超过5%，持续10分钟"

表达式里http_requests_total需要在应用中暴露，status是一个标签。表达式算的是最近5分钟内5xx请求数占总请求数的比例，超过5%后持续10分钟触发告警。labels里的severity字段会在Alertmanager里被用于路由判断。annotations里的summary和description是在告警通知里显示的字段，必须写清楚。

规则写好后，创建资源并等待Prometheus重载配置。Prometheus Operator会自动同步PrometheusRule，不需要手动重启Prometheus。可以在Prometheus UI的Alerts页面验证规则是否加载，规则列表里应该能看到WebServiceHighErrorRate这条规则，状态为inactive。

4.3 Alertmanager路由设置：分组、抑制与静默配置

Alertmanager的route配置决定告警发给谁、怎么合并。kube-prometheus-stack里Alertmanager的配置通过alertmanager.config这一段在values.yaml里定制。一个典型的生产配置如下：

alertmanager: config: global: resolve_timeout: 5m slack_api_url: "https://hooks.slack.com/services/xxx" route: group_by: ["namespace"] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: "default" routes: - matchers: - "severity=critical" receiver: "critical-team" group_by: ["namespace"] receivers: - name: "default" slack_configs: - channel: "#ops-warning" send_resolved: true - name: "critical-team" slack_configs: - channel: "#ops-critical" send_resolved: true

route里group_by控制按什么维度合并告警，这里选了namespace，意思是同一命名空间下的多个告警会在一个通知里。group_wait是窗口期内的告警合并等待时间，group_interval是合并后再次检查并发送新告警的间隔，repeat_interval是相同告警重复发送的间隔。如果不想半夜被同一告警疯狂轰炸，repeat_interval至少设置在12小时以上。matchers里的severity=critical会把高等级告警分流到不同的接收通道。

slack_api_url和channel需要替换成你实际使用的Webhook地址和频道。除了Slack，Alertmanager支持邮件、企业微信、钉钉等多种方式，配置逻辑相同。如果某一种通道配置失败，可以先用snmp webhook或者简单的WeChat模板做测试，确认路由逻辑是否正确。

4.4 告警触发的验证流程：模拟故障与检查通知链路

告警系统配置完必须验证，不能等真正出故障了才发现链路不通。最常见的验证方法是造一个假故障，比如临时停掉一个Pod，制造CrashLooping，看告警是否按预期触发并发送到通道。具体操作：创建一个测试用的Deployment，镜像设置为一个不存在的tag，让Pod一直拉取失败进入反复重启状态。

创建一个叫alert-test的Deployment，容器的镜像故意写错tag，Pod会一直处于ImagePullBackOff状态。接着Promeetheus的默认规则KubePodCrashLooping应该会在几分钟内触发，通知到配置的通道。如果一直没收到告警，按这个顺序排查：第一，在Prometheus UI的Alerts页面看这条规则是否已经触发，没触发说明规则条件不满足，先看规则运行情况；第二，Alertmanager UI的status页面，输入告警名称看路由是否匹配到了receiver；第三，检查receiver的Webhook配置是否正确，Slack API是否返回了错误信息。

这样的验证要建一个固定的测试流程，每次集群大版本升级或者Alertmanager配置变更后都重新验证一遍链路。

5. 生产部署避坑指南：5个高频问题的现象与排查

5.1 PVC一直Pending：StorageClass没配对

现象：安装后prometheus-statefulset的Pod一直显示Pending，describe看到event提示volume claim not bound。

原因：values里写了storageClassName，但集群里不存在这个StorageClass。我在一套自建集群上遇到过，明明集群用Rancher管理，worker节点上装的是local-path-provisioner，但values里填成了fast-storage，集群里根本找不到这个类，PVC自然一直Pending。

解决：先查集群里的可用存储类：kubectl get storageclass，看到名字后把storageClassName改成实际存在的名字。如果集群里确实没有StroageClass，临时方案是把storageClassName字段删掉，使用默认StorageClass。注意删掉之后PVC的绑定行为取决于默认StorageClass是否存在，不存在照样Pending。

5.2 Prometheus内存持续上涨导致OOM：采集目标太多

现象：Prometheus Pod内内存使用率超过limit，容器被OOMKilled，反复重启。查看监控面板发现采集目标数量在增加。

原因：接入的ServiceMonitor数量太多，或者某些target暴露的指标基数过大。常见场景是启用了Prometheus Adapter后，HPA相关的指标也会被采集，还有一些应用自己暴露的指标没有做标签白名单，导致高基数的标签组合产生海量时间序列。

解决：先看Prometheus自身的采集状态，在Targets页面按采集样本数排序，找到指标量最大的target。对应用侧的指标做过滤，在ServiceMonitor的endpoints里加metricRelabelings，丢弃不需要的高基数标签。另外控制每个ServiceMonitor的采集间隔，比如从15s放松到30s，可以直接降低采样次数。如果内存还是不够，最后的手段是调整Prometheus的limits，但要同时给足PVC容量，内存和存储增长是同步的。

5.3 告警风暴：同一个问题被重复推送

现象：节点故障时，同一个节点相关的几十条告警同时发送，微信和邮件被刷屏，手机一直震动。

原因：Alertmanager的group_by没有合理配置，或者repeat_interval设得太短。当告警按pod维度分组时，一个节点上几十个Pod同时异常，自然产生几十条告警。

解决：把group_by改为["alertname", "cluster"]，让相同告警名称的告警合并成一条。repeat_interval设置到6小时以上。还有一个有用的参数是inhibit_rules，它定义抑制关系：高等级告警触发时，低等级告警自动被抑制。典型场景是节点NotReady时抑制该节点上所有Pod相关的告警，在alertmanager.config里配一组inhibit_rules，source_matchers匹配severity=critical的节点告警，target_matchers匹配namespace下的全部告警。这样通知量能减少八成。

5.4 Grafana图表无数据但Prometheus有数据：数据源或Dashboard变量问题

现象：Prometheus的Explore能查到数据，但某个Dashboard面板显示No data。

原因：Dashboard自带的变量和Prometheus里的标签不匹配。比如Kubernetes / Pods面板的变量是namespace和pod，如果你的Prometheus里kube_pod_info这个指标没有pod标签，或者命名空间里存在特殊字符导致变量正则匹配失败，图表就出不来。

解决：打开Dashboard的设置页面，查看模板变量里每个变量的Query，直接在Prometheus里执行这个查询，看返回值的格式是否正常。如果变量查询本身报错，就是Prometheus里缺少对应的指标。如果变量有值但图表没数据，看Panel的查询语句，把变量改成常量测试一下。kube-prometheus-stack自带的Dashboard在默认部署下是能出数据的，出问题多半是集群版本太老导致某些指标不存在。

5.5 Chart升级后CRD没更新：Operator和CRD版本不匹配

现象：执行helm upgrade之后，Prometheus Operator还在跑，但新的ServiceMonitor创建后不生效，controller报错看不懂类似unable to recognize类型的日志。

原因：kube-prometheus-stack的chart里CRD是独立管理的，有些chart版本升级时CRD不会自动更新。之前CRD的schema和新的Operator代码预期不一致，导致新的字段不被识别。

解决：升级chart之前，手动更新CRD。官方建议是在升级chart时同时应用新版本的CRD文件。在安装目录下找到crds目录或使用kubectl apply -f命令强制更新，然后再执行helm upgrade。注意先把CRD备份，升级后验证CRD的apiVersion和chart期望的一致。以后再升级的时候把这一步固化成脚本，不要每次手动。

现象与解决这几个过程往往能省下两三个小时的排查时间。这些坑我大多在测试集群和线下环境都踩过，网上不少讨论串也指向这些原因，你如果遇到类似问题不要第一时间怀疑代码，先按这个顺序查配置。

6. 让这套监控系统更好用：告警自愈与Grafana运维技巧

监控系统能出告警只是第一步，真正有价值的是让告警能促进自动化处理。kube-prometheus-stack生态里可以配合事件驱动工具做自愈，比如在收到KubePodCrashLooping告警时，自动触发一次工作负载的滚动重启。做法是写一个监听Alertmanager Webhook的轻量服务，收到指定告警名称后调用API执行更新，比如对一个Deployment执行一次滚动升级。我第一次在测试环境做这件事时，用的就是一个几十行代码的简单服务，配合K8S的patch接口，效果出奇地好。

Grafana侧有一个日常运维技巧值得专门说：定期把Dashboard的JSON配置备份到代码仓库里。kube-prometheus-stack的Grafana在升级时可能会覆盖自定义的Dashboard。我在一次升级后丢失了一个自定义面板，从那以后养成了把每个自定义面板的JSON导出来提交到Git的习惯。具体操作很简单，在Grafana的Dashboard页面点击分享，然后选择Export JSON，把文件提交到配置仓库。如果有GitOps的工作流，也可以直接把Grafana的配置文件里dashboard目录挂载到ConfigMap。

另一个验证技巧是周期性检查Prometheus规则的运行状态。你可以配置一个健康检查Dashboard，里面放上几条关键的自定义告警规则，每天看一次它们是否正常加载。如果哪天发现规则数量少了，或者某条规则的表达式状态变成了ERR，说明配置里引入了语法错误，立即去查最近一次修改。

给新接手这套系统的人提一个建议：在values.yaml里每个自定义配置项旁边写注释，说明为什么这么调，当时的集群状态是什么。一个月后再来看，这些注释比任何文档都有用。我自己在接手某套集群时，就是因为前任留下的注释足够详细，省掉了大半的摸索时间。

最后一次踩坑是某天Prometheus突然重启，排查后确认是ConfigMap变更触发的滚动重启。这类操作本身没有错，但如果你希望避免数据写入中断，可以在升级窗口之外进行，并且提前确认PVC的容量余量足够。希望这一篇的经验，能让你在部署kube-prometheus-stack时少走几段弯路，祝顺利。

本文还有配套的精品资源，点击获取