【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载本指南以 charts 仓库中stable/prometheus-operator目录下的 CONTRIBUTING.md 为骨架完整展开向该 Chart 提交代码变更的规范流程从 Fork 开发、版本号递增、PR 标题前缀、上游 Rules/Dashboards 同步到 minikube 本地验证、RBAC 与 CRD 变更检查以及最终通过helm lint。读完本文你将掌握向这类集成型监控 Chart 提交高质量 PR 的完整方法论并理解其背后的同步机制与校验工具链。前置认知prometheus-operator Chart 的定位与当前状态在动手贡献之前需要先清楚这个 Chart 是什么、由哪些部分构成以及它当前的维护状态。这些信息记录在 Chart.yaml 与 README.md 中。该 Chart 并不是只安装一个 operator 那么简单它是一个全家桶式的监控栈安装 prometheus-operator 来创建/配置/管理 Kubernetes 上的 Prometheus 集群同时默认附带 Prometheus、Alertmanager、node-exporter、kube-state-metrics、Grafana以及一组用于抓取集群内部组件的 ServiceMonitorkube-apiserver、kube-scheduler、kube-controller-manager、etcd、kube-dns/coredns、kube-proxy并内置配套的告警规则与 Grafana Dashboard。从 requirements.yaml 可以看到它依赖三个子 Chart依赖版本范围启用条件kube-state-metrics2.8.*kubeStateMetrics.enabledprometheus-node-exporter1.10.*nodeExporter.enabledgrafana5.3.*grafana.enabled需要注意的关键事实以当前仓库实际内容为准该 Chart 已被标记为deprecateddeprecated: trueREADME 顶部有显著声明其后续演进已迁移到其他项目chart 更名为 kube-prometheus-stack。向本仓库贡献时应基于当前快照的内容与规范并清楚它已不再继续演进。当前版本为version: 9.3.2appVersion: 0.38.1tillerVersion: 2.12.0属于 Helm v2 时代Tiller 组件的 Chart因此贡献时相关的命令语境helm install --name、helm init等也是 Helm v2 时代的写法。贡献流程总览一条 8 步检查清单CONTRIBUTING.md 将贡献流程凝练为 8 条硬性要求任何提交都应按此顺序逐条自查序号要求核心目的1Fork 本仓库开发并测试自己的 Chart 改动保证变更是可复现、经过验证的2每次改动都要递增 Chart 版本号保证 Helm 发布与回滚可追踪3PR 标题必须带[stable/prometheus-operator]前缀便于按目录维度检索与维护4改动 Rules 或 Dashboards 时遵循 README 中从上游同步的章节保证监控规则/面板有单一上游来源5检查hack/minikube目录的脚本用其搭建本地环境验证改动保证所有组件可被实际抓取到6检查 RBAC 规则的变更保证最小权限与集群安全7检查 CRD spec 的变更保证自定义资源定义与 operator 版本匹配8PR 必须通过 linterhelm lint保证模板语法与 Chart 结构合法下面逐条展开讲解并结合仓库源码、配置与脚本说明每一项背后的具体做法。Fork 开发与版本号递增贡献的地基第一条与第二条是任何 Helm Chart 贡献的通用起点。Fork 与开发从仓库 Fork 出自己的副本在分支上修改stable/prometheus-operator/目录内的 Chart 文件templates、values.yaml、crds 等并在本地完成可验证的测试。测试的手段包括下文要讲的 minikube 环境以及helm lint/helm template等静态校验。版本号递增每次变更无论是修 bug、加参数还是改模板都必须修改 Chart.yaml 中的version字段。当前为9.3.2贡献时应按语义化版本规则递增。这一点至关重要Helm 通过version区分 Chart 的不同发布若两个不同内容的提交使用同一版本号会导致helm install/helm upgrade的缓存与索引混乱无法准确回溯哪个版本对应哪次变更。README 中的升级章节如 8.x.x → 9.x.x、7.x.x → 8.x.x也印证了大版本号变化代表破坏性变更需要人工操作这一约定例如从 8.x 升到 9.x 时additionalScrapeConfigsExternal被additionalScrapeConfigsSecret取代。PR 标题前缀让变更按目录可检索第三条要求 PR 标题以[stable/prometheus-operator]开头。charts 仓库包含stable/与incubator/两大目录、数百个 Chart每个 Chart 由独立维护者关注。通过目录名作为 PR 标题前缀维护者可以快速过滤出与自己负责的 Chart 相关的 PR自动化工具也可以按前缀路由通知。类似地仓库根目录还有面向全仓库的 CONTRIBUTING.md 与 PROCESSES.md 规范含 Chart 弃用/取消弃用流程提交流程需要同时满足这两级规范。改动 Rules 与 Dashboards必须走上游同步链路第四条是 prometheus-operator 这个 Chart 最有特色的贡献约束。它的 Grafana Dashboard 与 Prometheus Rules并非在本仓库直接维护而是从上游复制、经脚本同步可能带修改而来。README 的 Developing Prometheus Rules and Grafana Dashboards 一节明确指出要改动这些内容需要先在上游仓库完成变更再通过脚本同步到本仓库。同步脚本的工作方式仓库的 hack 目录 包含两个核心脚本sync_prometheus_rules.py从上游导入格式合法的 Prometheus 规则 YAML按 group 名称拆分到 templates/prometheus/rules/ 下的多个独立规则文件如alertmanager.rules.yaml、kube-apiserver.rules.yaml、node-time.yaml等。sync_grafana_dashboards.py从上游导入 Grafana Dashboard 的 JSON拆分到 templates/grafana/dashboards/ 与dashboards-1.14/下的独立 YAML 文件。上游导入链路目前导入的规则与面板来源包括kube-prometheus 规则集与 Dashboard修改路径为 kubernetes-mixinrules/dashboards→ 上游 kube-prometheus执行jb update与make generate-in-docker生成→ 在本仓库 Fork 中运行同步脚本 → 提交 PR。etcd 规则集与 Dashboard修改路径为 etcd 项目etcd3_alert.rules.yml 与 grafana.json→ 在本仓库 Fork 中运行同步脚本 → 提交 PR。唯一例外是 dashboards-1.14/k8s-coredns.yaml它是唯一在本仓库直接维护、无需走导入流程的 Dashboard。这意味着贡献者在改动任何规则或面板前必须回答一个问题这个改动应该发生在哪里如果答案是上游就先走完上游 PR 流程再回来同步如果答案是 CoreDNS 面板才可以直接改本仓库文件。这套机制保证了监控内容的上游单一来源避免同一套规则在多个仓库中出现语义分叉。用 hack/minikube 做本地端到端验证第五条要求使用 hack/minikube 目录下的脚本搭建本地 minikube 环境验证改动后所有组件都能被真实抓取。其 README 说明该目录的配置用于在 minikube 上本地测试整套安装通过cmd.sh搭建组件并 hack 出一份可用的 etcd 抓取配置。cmd.sh 提供了按序执行的 5 个命令命令作用reset-minikube删除并重建 minikube使用适合运行 prometheus-operator 的配置--kubernetes-versionv1.13.3 --memory4096 --bootstrapperkubeadm并开启 kubelet 的 token webhook、Webhook 授权模式将 scheduler/controller-manager 的地址暴露为0.0.0.0否则默认安装无法抓取 kubelet、scheduler、controller-managerinit-helm初始化 HelmTiller并更新仓库索引仅在 minikube 装好后运行一次init-etcd-secret从 apiserver 拉取 etcd 证书在 monitoring 命名空间创建etcd-certsSecret后续安装依赖该 Secret否则 Prometheus 无法启动prometheus-operator以helm upgrade --install --debug方式安装/升级 Chart并注入随机 UUID 注解强制 Grafana 重建port-forward分别转发 Prometheus9090、Alertmanager9093、Grafana3000:80端口到 localhost便于本地查看抓取与告警效果为什么需要 init-etcd-secret 与 values.yaml 配合minikube 的 etcd 默认启用 TLS 证书认证Prometheus 抓取 etcd 需要证书。init-etcd-secret从kube-apiserver-minikube容器内读取/var/lib/minikube/certs/etcd/下的ca.crt、apiserver-etcd-client.crt、apiserver-etcd-client.key写入 monitoring 命名空间的etcd-certsSecret。配套的 values.yaml 则完成两件事prometheus: prometheusSpec: secrets: [etcd-certs] kubeEtcd: serviceMonitor: scheme: https caFile: /etc/prometheus/secrets/etcd-certs/ca.crt certFile: /etc/prometheus/secrets/etcd-certs/client.crt keyFile: /etc/prometheus/secrets/etcd-certs/client.key这里体现了 Chart 的一个关键设计prometheus.prometheusSpec.secrets把 Secret 挂载进 Prometheus Pod 的/etc/prometheus/secrets/secret-name路径而kubeEtcd.serviceMonitor的caFile/certFile/keyFile正是引用这一挂载路径。README 的 Exporters 参数表中对kubeEtcd.serviceMonitor.caFile等参数的说明Seeprometheus.prometheusSpec.secrets与此完全对应——这是理解Secret 挂载 ServiceMonitor 引用这条链路的直接源码证据。因此贡献涉及抓取配置尤其 etcd 这类 TLS 组件时应当用这套脚本实际拉起环境确认抓取目标出现在 Prometheus 的 targets 中而不是只做静态检查。RBAC 变更检查审视权限边界第六条要求检查 RBAC 规则的变更。这个 Chart 的权限面很宽RBAC 资源集中在模板目录中Prometheus Operator 的权限templates/prometheus-operator/clusterrole.yaml、clusterrolebinding.yaml以及 Pod Security Policy 相关的psp-clusterrole.yaml、psp-clusterrolebinding.yaml、psp.yamlAlertmanager 的 PSP 资源templates/alertmanager/psp.yaml、psp-role.yaml、psp-rolebinding.yaml准入 Webhook 修补 Job 的权限templates/prometheus-operator/admission-webhooks/job-patch/下的clusterrole.yaml、role.yaml、rolebinding.yaml等。贡献时若改动这些文件需要自问权限是否仍然遵循最小化原则是否引入了不必要的集群级权限是否与global.rbac.create、global.rbac.pspEnabled等开关的行为一致例如默认值表中global.rbac.createtrue、global.rbac.pspEnabledtrue意味着关闭 RBAC 时相关资源不应再生成模板中的条件渲染逻辑if .Values.rbac.create需要同步调整。CRD 变更检查与 operator 版本的匹配第七条要求检查 CRD spec 的变更。该 Chart 自带的 CRD 清单位于 crds 目录crd-alertmanager.yamlAlertmanagercrd-podmonitor.yamlPodMonitorcrd-prometheus.yamlPrometheuscrd-prometheusrules.yamlPrometheusRulecrd-servicemonitor.yamlServiceMonitorcrd-thanosrulers.yamlThanosRuler这与 README 卸载章节列出的 6 个 CRDkubectl delete crd prometheuses.monitoring.coreos.com等一一对应。贡献时若升级 operator 镜像prometheusOperator.image.tag当前默认v0.38.1或改动任何 CRD 文件必须确保二者版本匹配CRD 新增字段、apiVersion 变更或行为变化都应同步反映否则会出现operator 期待新字段、集群里却是旧 CRD的运行期问题。与 CRD 相关的还有两个容易混淆的开关来自 README 配置表prometheusOperator.createCustomResource默认trueChart 是否创建 CRD。若在 Helm v2 且版本较旧的环境需要先手动kubectl apply -f创建 CRD 再以--set prometheusOperator.createCustomResourcefalse安装README 的 Helm fails to create CRDs 工作区一节给出了完整 6 个 CRD 的 apply 命令prometheusOperator.cleanupCustomResource默认false卸载时是否尝试删除 CRD。README 明确不建议开启因为删除 CRD 会连带删除其管理的资源且 CRD 默认不会随helm delete被移除需手工清理。仓库 ci 目录 的两个测试 values 也从侧面印证了 CRD 的测试路径01-provision-crds-values.yaml 关闭了除 operator 之外的全部组件alertmanager.enabled: false、prometheus.enabled: false、defaultRules.create: false等并设置createCustomResource: false、关闭 admissionWebhooks 与 tlsProxy专门用于验证仅 operator 由它在启动时幂等创建 CRD这一最小场景02 号文件则对应不带 CRD 的安装场景。贡献涉及 CRD 时应确保这两类 CI 场景仍然通过。通过 helm lint最后一道静态关卡第八条要求 PR 必须通过helm lint。helm lint是 Helm 内置的 Chart 校验器会检查 Chart 结构是否完整Chart.yaml、values.yaml、templates 等、YAML 语法是否合法、模板能否正常渲染等。对于本 Chart由于它模板数量庞大templates 下包含 prometheus-operator、prometheus、alertmanager、exporters、grafana 等多个子目录任何模板改动都应在本地执行$ helm lint stable/prometheus-operator只有 lint 通过PR 才具备被合入的基本资格。作为补充仓库 test 目录 还提供了 e2e 测试脚本test/e2e.sh、helm-test-e2e.sh与 Chart 测试工具配置 ct.yaml贡献者可以参考这些测试基础设施了解全量校验是如何在 CI 中执行的。需要说明的是本仓库的 Helm 命令语境基于 Helm v2Tiller实际执行时请匹配自己环境中的 Helm 版本与--name等参数用法。提交前自检清单速查综合 CONTRIBUTING.md 与上文分析提交 PR 前请按此清单逐项确认改动是否在 Fork 的分支中开发完成并在本地含 minikube 环境验证过组件可被正常抓取Chart.yaml 的version是否已递增PR 标题是否以[stable/prometheus-operator]开头若涉及规则或面板是否先改上游kubernetes-mixin / kube-prometheus / etcd再通过 hack 目录 的sync_prometheus_rules.py/sync_grafana_dashboards.py同步CoreDNS 面板除外是否用 hack/minikube/cmd.sh 按序执行reset-minikube→init-helm→init-etcd-secret→prometheus-operator完成了端到端验证是否检查了 templates/prometheus-operator/ 等目录下 RBAC 文件的权限变更确保最小权限是否检查了 crds 目录 的 CRD spec 与 operator 镜像版本匹配并覆盖 ci 目录 的两种 CRD 测试场景是否已通过helm lint。这套流程的价值在于它把改代码变成改代码 同步上游 端到端验证 静态校验的完整闭环保证了监控栈这类强耦合组件的每次变更都可追溯、可复现、可回滚。即使该 Chart 当前已标记为 deprecated其贡献方法论——尤其是面板与规则必须上游同步CRD/RBAC 变更需专项检查本地全组件验证这三条原则——对任何复杂 Helm Chart 的维护者都有直接的借鉴意义。赞分享【免费下载链接】charts⚠️(OBSOLETE) Curated applications for Kubernetes项目地址https://gitcode.com/gh_mirrors/chart/charts点击查看免费下载相关推荐Prometheus Node Exporter Helm Chart 部署指南基于 charts 仓库的 Kubernetes 节点监控实践Prometheus Node Exporter Helm Chart 部署指南基于 charts 仓库的 Kubernetes 节点监控实践 导读 本文以Prometheus Operator Helm Chart 迁移指南从仓库内置 Chart 到 kube-prometheus-stackPrometheus Operator Helm Chart 迁移指南从仓库内置 Chart 到 kube prometheus stack 本文聚焦 Pro云原生可观测性Apache Solr Helm Chart 部署与配置全指南StatefulSet 集群、TLS 与 Prometheus 监控helm/charts 仓库Apache Solr Helm Chart 部署与配置全指南StatefulSet 集群、TLS 与 Prometheus 监控helm/charts 仓上一篇ECC 仓库 /build-fix 命令全解析构建系统检测、最小化修复循环与类型错误治理实战下一篇Pandoc 的 space_in_atx_header 扩展ATX 标题与 后空格的解析规则剖析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考