企业官网建设流程全解析

• 云原生
• 可观测性

本文聚焦 Prometheus Operator 仓库中 Helm Chart 的历史演进与当前使用方式：原本内置在该仓库的多个 Chart 已整体迁移并合并为社区维护的kube-prometheus-stack单一 Chart。读者读完本文后，将清楚了解迁移的来龙去脉、为何没有直接迁移路径、如何在当前版本下正确安装与使用kube-prometheus-stack，以及如何在单集群中运行多个 Prometheus 实例。

现状速览：helm 目录发生了什么

当前仓库的 helm/README.md 只保留了一份"迁移通知"。全文的核心信息如下：

• 原本在 Prometheus Operator 仓库中开发的 Helm Charts 已迁移到 prometheus-community 维护的kube-prometheus-stackChart；
• 原仓库中分散的多个 Chart 被合并为单一 Chart，该 Chart 一次安装即可部署 Prometheus Operator、Prometheus、Alertmanager、Grafana 以及监控集群所需的众多 exporter；
• 不存在从旧 Chart 到kube-prometheus-stack的直接迁移路径，两者之间存在大量变更与能力增强；
• 依然可以在单个集群中运行多个 Prometheus 实例，做法是禁用 Chart 中你不希望部署的部分；
• 相关问题与 Pull Request 的跟踪统一迁移到了 prometheus-community/helm-charts 仓库；
• 本次变更对应的历史记录为 prometheus-operator/prometheus-operator#592 与 helm/charts#6765。

从仓库现状看，这一迁移已经彻底完成：helm/目录下仅剩这份 README，仓库内已不再包含任何Chart.yaml或其他 Helm Chart 资源，官方安装文档也不再引导用户从本仓库安装 Helm Chart。

为什么发生这次迁移

结合仓库内文档可以梳理出迁移动机。本次迁移与 kube-prometheus 的独立化是同一趋势下的两个动作：

• Chart 与项目核心解耦：Helm Chart 本质上是 Kubernetes manifests 的打包分发形式，维护成本与 Prometheus Operator 本身的演进节奏不同，将其交给专门的 Helm 社区仓库（prometheus-community/helm-charts）可以独立发布版本、独立演进；
• 统一分发形态：原仓库的多个 Chart 被合并为一个kube-prometheus-stackChart，用户不再需要分别安装 operator、prometheus、alertmanager 等组件各自的 Chart，而是通过一个 Chart 的开关（values）按需启用/禁用组件，降低了部署心智负担；
• 与 kube-prometheus 项目分工明确：仓库中 contrib/kube-prometheus/README.md 同样记载了 kube-prometheus 移出主仓库的历史。当时给出的理由（"让项目独立演进、发布带版本号的 release"）与 Helm Chart 迁移的动机一脉相承。仓库根目录的 README.md 也专门区分了Prometheus Operator vs. kube-prometheus vs. 社区 Chart三个概念，帮助用户选择合适的分发方式。

需要特别说明：迁移不是简单的"改名"或"换地址"。官方明确提示"there is no direct migration path"——新旧 Chart 之间的 values 结构、组件组织、默认行为均有大量差异，因此不能把旧 values 文件直接搬到新 Chart 上运行，需要按新 Chart 的文档重新梳理配置。

当前官方推荐的 Helm 安装方式

虽然 Helm Chart 已从本仓库移除，但安装 Prometheus Operator 的 Helm 路径依然存在，只是入口变成了社区 Chart。官方安装文档 Documentation/getting-started/installation.md 的 "Install Using Helm Chart" 一节（对应安装方式列表中的第三条）对此有明确说明：

安装Kube-Prometheus-StackHelm chart，它提供了一套 Kubernetes manifests、Grafana dashboards 与 Prometheus rules 的组合，配合文档和脚本，可以基于 Prometheus Operator 轻松实现开箱即用的端到端 Kubernetes 集群监控。

注意：该 Helm Chart 已不再属于 Prometheus-Operator，现由 Prometheus Community Helm Charts 维护。

该文档同时指出，Prometheus Operator v0.84.0 及以上版本由于在 CRD 中使用了 CEL（Common Expression Language），要求 Kubernetes 集群版本 >= v1.25.0（启用CustomResourceValidationExpressionsfeature gate 时可为 >= v1.23.0）；v0.84.0 之前的版本要求 Kubernetes >= v1.16.0。安装前应先参考 Documentation/getting-started/compatibility.md 核对各组件版本兼容性。

典型安装流程（以社区 Chart 的常规用法为例，详细参数以 kube-prometheus-stack 的 Chart README 为准）：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install prometheus-stack prometheus-community/kube-prometheus-stack \ --namespace monitoring --create-namespace

安装完成后，可用以下命令确认 Prometheus Operator 相关 Pod 已就绪（标签与仓库 Documentation/getting-started/installation.md 中 YAML 安装方式一致）：

kubectl wait --for=condition=Ready pods -l app.kubernetes.io/name=prometheus-operator

单集群运行多个 Prometheus 实例

原 README 中特别强调了一个仍然成立的能力：在单个集群中运行多个 Prometheus 实例。这在使用旧多 Chart 形态时是"分别部署多个 release"，在合并后的kube-prometheus-stack中则通过禁用不需要的组件实现。

具体做法是在安装时通过--set覆盖 values，关掉你不需要的部分。例如只想要 Operator 加自己的 Prometheus，而不需要 Alertmanager 或 Grafana：

helm install prometheus-stack prometheus-community/kube-prometheus-stack \ --namespace monitoring --create-namespace \ --set alertmanager.enabled=false \ --set grafana.enabled=false

之后再按需创建第二套实例时，可另起一个 release，并通过prometheusOperator.enabled等开关精确控制每个 release 部署的组件，避免组件冲突。组件级开关的具体名称与默认值请以当前 Chart 版本为准——这正是迁移后"能力增强"的一部分：单 Chart + 细粒度开关取代了原来的多 Chart 拼装。

迁移时需要注意的关键点

结合 README 与仓库内安装文档，迁移到kube-prometheus-stack时有几个容易踩坑的点：

1. 不要期望无缝迁移：旧的 Chart values 结构不会自动兼容，需要按新 Chart 的 values 文档逐项核对，尤其是命名空间、默认组件、ServiceMonitor 与告警规则的组织方式；
2. 组件集合扩大：新 Chart 除 Operator 外还包含 Prometheus、Alertmanager、Grafana 及大量 exporter。若沿用旧配置，默认安装的组件集会明显多于从前，需要显式禁用不需要的部分；
3. 版本与集群要求：Chart 内嵌的 Operator 版本对应 CEL 要求（Kubernetes >= v1.25.0，见上文），升级前先确认集群版本满足要求；
4. 问题反馈渠道变化：与 Chart 相关的 Issue 与 PR 一律提交到 prometheus-community/helm-charts 仓库，提交到本仓库不会被 Chart 维护者跟踪。

与其他安装方式的关系

官方文档列出了三种主流安装方式，Helm Chart 只是其中一种，理解它们的边界有助于选择：

需要注意的是，官方安装文档中还有"移除 kube-prometheus"一节（kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup），它针对的是 kube-prometheus 项目而非 Helm Chart；卸载kube-prometheus-stack应使用helm uninstall并考虑 CRD 的独立管理策略。

结语

Prometheus Operator 仓库中 Helm Chart 的故事以"迁移 + 合并"收尾：多个内置 Chart 整合为社区单一 Chartkube-prometheus-stack，功能更强、维护更独立，但代价是没有直接迁移路径。对当前用户而言，安装与使用 Helm Chart 的正确入口是 prometheus-community 维护的 kube-prometheus-stack；本仓库则继续以 YAML/Kustomize 和 kube-prometheus 两种方式提供安装能力，并为 Helm 路径提供指引。若你在部署中遇到 Chart 相关问题，请直接到 prometheus-community/helm-charts 仓库提交 Issue 或 PR。

• 云原生
• 可观测性