使用 Bitnami Helm Chart 部署与运维 CloudNativePG：Kubernetes 上的 PostgreSQL Operator 全攻略

CloudNativePG 是一款面向 Kubernetes 的 PostgreSQL 管理工具，覆盖从实例创建、高可用、备份恢复到日常运维的完整生命周期。本篇文章以仓库中的 bitnami/cloudnative-pg/README.md 为骨架，结合 Chart.yaml、values.yaml 与 templates/ 目录下的真实模板实现，系统讲解如何用 Bitnami 出品的 Helm Chart 在 Kubernetes 集群上部署 CloudNativePG Operator、配置 Barman Cloud 备份插件、接入 Prometheus 监控，并深入剖析每一个核心配置参数背后的实现原理。读完本文，你将能够独立完成 CloudNativePG 的生产级部署、定制与排障。

CloudNativePG 与 Bitnami Chart 概览

CloudNativePG 是用于在 Kubernetes 上管理 PostgreSQL 数据库的开源工具，从集群搭建到日常维护全部以声明式 API（CRD）方式完成。本仓库中的 Bitnami chart 将其打包为 Helm 应用，chart 的元信息定义在 Chart.yaml 中：

• chart 名称：cloudnative-pg，版本 1.0.13，对应应用版本（appVersion）1.27.0；
• 内置镜像清单：bitnami/cloudnative-pg:1.27.0-debian-12-r1（Operator）、bitnami/plugin-barman-cloud:0.6.0-debian-12-r0 及 plugin-barman-cloud-sidecar（备份插件）、bitnami/postgresql:17.6.0-debian-12-r4（托管实例使用的 PostgreSQL 镜像）；
• 依赖 common 子 chart（oci://registry-1.docker.io/bitnamicharts，版本 2.x.x），用于提供标签、亲和性预设、资源预设等公共模板能力。

从模板目录结构可以清晰看出本 chart 的两大组成部分（见 templates/operator/ 与 templates/plugin-barman-cloud/）：

1. Operator 组件：deployment.yaml、configmap.yaml、secret.yaml、clusterroles.yaml、webhook（validatingwebhookconfiguration.yaml/mutatingwebhookconfiguration.yaml）、metrics-service.yaml、servicemonitor.yaml、networkpolicy.yaml、pdb.yaml 等；
2. plugin-barman-cloud 组件：deployment.yaml、certs.yaml、tls-secret.yaml、ca-cert.yaml、service.yaml、metrics-service.yaml 等；
3. CRD 资源：chart 在 crds/ 目录下内置了 11 个 CRD 定义，包括 postgresql.cnpg.io_clusters（Cluster）、postgresql.cnpg.io_backups、postgresql.cnpg.io_scheduledbackups、postgresql.cnpg.io_poolers、postgresql.cnpg.io_databases、barmancloud.cnpg.io_objectstores 等，安装 chart 时这些 CRD 会一并注册到集群。

说明：本仓库内的 chart 默认镜像 tag 为可变 tag（如 1.27.0-debian-12-r1），生产环境建议改用不可变 tag 或 image.digest 固定版本，具体见下文「Rolling 与 Immutable Tags」小节。

快速安装（TL;DR）

前提条件（来自原文档 README.md）：

• Kubernetes 1.23+
• Helm 3.8.0+

最简安装命令：

helm install my-release oci://registry-1.docker.io/bitnamicharts/cloudnative-pg

更通用的写法是使用仓库占位符（需将 REGISTRY_NAME、REPOSITORY_NAME 替换为实际值，例如 Bitnami 官方为 registry-1.docker.io 与 bitnamicharts）：

helm install my-release REGISTRY_NAME/REPOSITORY_NAME/cloudnative-pg

安装完成后可以用 helm list 查看所有 release。使用 --set key=value 传参的示例（启用 Barman Cloud 备份插件）：

helm install my-release \
  --set pluginBarmanCloud.enabled=true \
  REGISTRY_NAME/REPOSITORY_NAME/cloudnative-pg

也可以把全部参数写入 YAML 文件后一次导入：

helm install my-release -f values.yaml REGISTRY_NAME/REPOSITORY_NAME/cloudnative-pg

仓库内默认的完整参数文件就是 values.yaml，可直接作为定制起点。

Operator 配置：ConfigMap 与 Secret 双通道

CloudNativePG Operator 支持通过 ConfigMap 和 Secret 注入运行配置。chart 通过 operator.configuration 与 operator.secretConfiguration 两个参数分别生成 ConfigMap 与 Secret（templates/operator/configmap.yaml 和 templates/operator/secret.yaml），这两个参数可以同时使用，且 operator.secretConfiguration 的优先级高于 operator.configuration（Secret 通常用于存放证书类敏感配置）。

operator:
  configuration:
    EXPIRING_CHECK_THRESHOLD: 12
  secretConfiguration:
    CERTIFICATE_DURATION: 120

也可以直接复用集群中已存在的 ConfigMap / Secret，通过 operator.existingConfigMap 与 operator.existingSecret 指定名称。注意：existingConfigMap / existingSecret 与 configuration / secretConfiguration 互不兼容，两者不可同时使用。

从部署模板 templates/operator/deployment.yaml 可以看到底层接线逻辑：

• 当 operator.configuration 非空且未指定 existingConfigMap 时渲染 ConfigMap；
• 容器 args 中会追加 --config-map-name=<名称> 与 --secret-name=<名称> 参数，让 Operator 从对应对象读取配置；
• Pod 注解中会写入 checksum/config 与 checksum/secret（基于渲染内容计算的 SHA-256），一旦配置内容变化，Helm 会自动触发滚动更新，保证配置变更即时生效；
• 其余核心启动参数也由该模板生成：controller --leader-elect（启用 leader 选举，多副本时保证只有一个主控制器）、--max-concurrent-reconciles=<值>（对应 operator.maxConcurrentReconciles，默认 10）、--webhook-port（默认 9443）、--metrics-bind-address=:<端口>（默认 8080），开启 operator.image.debug 时还会追加 --log-level=trace。

环境变量方面，模板固定注入了 OPERATOR_IMAGE_NAME（Operator 自身镜像）与 POSTGRES_IMAGE_NAME（托管实例将使用的 PostgreSQL 镜像，由 operator.postgresqlImage.* 控制）；当 operator.watchAllNamespaces=false 时注入 WATCH_NAMESPACE（用逗号连接 watchNamespaces 列表）；OPERATOR_NAMESPACE 取自 Pod 所在命名空间。

资源请求与限制（Resources）

生产负载必须为容器设置资源请求（requests）与上限（limits）。本 chart 中相关参数位于 operator.resources 与 pluginBarmanCloud.resources 下（两者结构相同）：

operator:
  resources:
    requests:
      cpu: 2
      memory: 512Mi
    limits:
      cpu: 3
      memory: 1024Mi

为降低配置门槛，chart 还提供了 operator.resourcesPreset 与 pluginBarmanCloud.resourcesPreset 预设，可选值：none、nano、micro、small、medium、large、xlarge、2xlarge，默认 nano。预设的具体取值由 common 子 chart 的 common.resources.preset 模板生成（见 common/templates/_resources.tpl）。其生效逻辑在 deployment.yaml 中很明确：

• 若显式设置了 operator.resources，则直接使用该值；
• 否则若 resourcesPreset != "none"，则套用对应预设；
• 两者都为空则不设置资源。

需要提醒的是：原文档明确建议生产环境优先使用显式的 resources 而非 resourcesPreset，因为预设值是为通用场景设计的，未必贴合你的实际业务负载。

备份与恢复：plugin-barman-cloud 插件

CloudNativePG 通过 Barman Cloud 插件（plugin-barman-cloud）实现向 S3 等对象存储的备份能力。本 chart 通过 pluginBarmanCloud.enabled 控制插件部署（默认 true）：

pluginBarmanCloud:
  enabled: true

插件组件包含两个镜像：主镜像 plugin-barman-cloud 与 sidecar 镜像 plugin-barman-cloud-sidecar（分别对应 pluginBarmanCloud.image.* 与 pluginBarmanCloud.sidecarImage.*，版本均为 0.6.0-debian-12-r0）。其核心端口（pluginBarmanCloud.containerPorts）包括：metrics 8080、grpc 9443、health 8921；对外 Service 的 gRPC 端口为 9090（见 templates/plugin-barman-cloud/service.yaml）。

关于插件编排，值得注意两点（均体现在模板实现中）：

1. TLS 是硬性要求：CloudNativePG 官方插件机制要求插件具备 TLS 证书（插件校验逻辑在 CloudNativePG 源码 internal/controller/plugin_predicates.go 中），因此 values.yaml 专门辟出 pluginBarmanCloud.tls 参数段。默认 tls.autoGenerated.enabled=true 且 engine: helm（由 Helm 自动生成自签证书，对应 templates/plugin-barman-cloud/certs.yaml 与 tls-secret.yaml）；也可切换为 cert-manager 引擎（需提供 existingIssuer），或通过 tls.server.existingSecret / tls.client.existingSecret 直接挂载自有证书。
2. 插件使用 gRPC 与 Operator 通信，Service 的 ports.grpc 默认 9090，nodePorts.grpc 支持在 30000-32767 区间内开放 NodePort。

启用插件后，备份的具体行为由用户自行创建 BarmanObjectStore 等 CRD 对象来驱动（chart 已在 crds/barmancloud.cnpg.io_objectstores.yaml 中注册该 CRD），备份目标、保留策略等均在该对象上声明。

Prometheus 指标监控

本 chart 为两个组件（Operator 与 plugin-barman-cloud）都提供了监控接入能力，相关参数在 operator.metrics.* 与 pluginBarmanCloud.metrics.* 下，结构一致。

开启指标暴露

operator:
  metrics:
    enabled: true

开启后，chart 会渲染一个 metrics Service（见 templates/operator/metrics-service.yaml），它暴露 CloudNativePG 原生 Prometheus 端点 /metrics，并自动带上三个抓取注解：

prometheus.io/scrape: "true"
prometheus.io/port: "<metrics.service.ports.metrics>"
prometheus.io/path: "/metrics"

这样即使不用 Prometheus Operator，使用默认的 Prometheus 配置也能自动发现并抓取。Service 端口通过 operator.metrics.service.ports.metrics 配置，默认 80，后端指向容器端口 http-metrics（默认 8080）。

数据库监控查询（Monitoring Queries）

除了 Operator 自身的指标，chart 还为 PostgreSQL 实例部署一组监控查询 ConfigMap/Secret，对应 operator.metrics.monitoringQueries 段：

• useSecret：默认 false，即使用 ConfigMap；设为 true 则改用 Secret 存放查询；
• overrideConfiguration：用于覆盖/合并默认查询的某个 section；
• existingQueries：直接指定一个已存在的 ConfigMap 或 Secret 名称，此时 chart 不再自动生成查询资源。

默认查询的完整 SQL 定义在 templates/operator/monitoring-queries.yaml 中（来自 CloudNativePG 上游 config/manager/default-monitoring.yaml），包括：

• backends：按数据库/用户/应用名/状态统计连接数（pg_stat_activity）与最大事务时长；
• backends_waiting：通过 pg_locks 自连接统计被阻塞的后端数；
• pg_database：各库容量 size_bytes、xid_age、mxid_age；
• pg_postmaster：实例启动时间；
• pg_replication / pg_replication_slots：主备复制延迟（秒/字节）、流复制副本数；
• pg_stat_archiver：WAL 归档成功/失败次数与最近归档时间；
• pg_stat_bgwriter（含 PostgreSQL 17 专用变体 pg_stat_bgwriter_17，通过 runonserver 字段区分版本）与 pg_stat_checkpointer（>= 17）；
• pg_stat_database：事务提交/回滚、块读写、元组操作、死锁、临时文件等；
• pg_stat_replication（标注 primary: true）：各 standby 的写/刷/回放延迟字节数与秒数；
• pg_settings：数值类 GUC 参数当前值；
• pg_extensions：已安装扩展及其版本是否落后。

这些查询由 CloudNativePG 实例通过 MonitoringQueries 机制执行，将 pg_catalog 系统视图数据转换为 Prometheus 指标。模板合并逻辑为：将默认配置 fromYaml 化后，用 overrideConfiguration 通过 mergeOverwrite 覆盖，因此你可以在不丢失内置查询的前提下，精确替换某一条查询的 SQL。

Prometheus 前置要求与 Prometheus Operator 集成

该监控能力依赖集群中已存在可用的 Prometheus 或 Prometheus Operator。若集群尚未部署，可通过同仓库下的 Bitnami prometheus 或 kube-prometheus chart 快速补齐。

若要与 Prometheus Operator 集成，则开启 ServiceMonitor：

operator:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

（pluginBarmanCloud.metrics.serviceMonitor.enabled 同理。）ServiceMonitor 模板见 templates/operator/servicemonitor.yaml，它会对 app.kubernetes.io/component: metrics 的 Service 抓取 /metrics 端点，并支持自定义 interval、scrapeTimeout、honorLabels、relabelings、metricRelabelings、selector 等。前提是集群必须已安装 Prometheus Operator 的 CRD（monitoring.coreos.com/v1），否则部署会报错：

no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

此时通过安装 Bitnami kube-prometheus chart 可一次性获得所需 CRD 与完整的 Prometheus Operator 栈。

Rolling 与 Immutable Tags（生产镜像选择）

原文档强烈建议生产环境使用不可变 tag（immutable tags），避免同一 tag 被更新后，部署在无感知的情况下拉取到新镜像而改变行为。

• 若使用可变 tag（如 latest 或 Chart 默认的 1.27.0-debian-12-r1 这类滚动构建 tag），某次 helm upgrade 或 Pod 重建时可能拉取到内容不同的同名镜像；
• 更稳妥的做法是通过 operator.image.digest 固定镜像摘要（格式 sha256:aa....），digest 一旦设置会覆盖 tag；pluginBarmanCloud.image.digest、pluginBarmanCloud.sidecarImage.digest、operator.postgresqlImage.digest 同理；
• Bitnami 会在上游容器发布新版本、出现重大变更或修复关键漏洞时发布新 chart 更新镜像，因此关注 CHANGELOG.md 及时升级同样重要。

附加环境变量、Sidecar 与 Init 容器

附加环境变量

需要注入自定义环境变量（例如定制启动脚本）时，可使用 operator.extraEnvVars（pluginBarmanCloud.extraEnvVars 同理）：

operator:
  extraEnvVars:
    - name: LOG_LEVEL
      value: error

如果变量较多，也可以把整组变量收敛到 ConfigMap 或 Secret 中，再通过 operator.extraEnvVarsCM 或 operator.extraEnvVarsSecret 引用（模板中以 envFrom.configMapRef / envFrom.secretRef 注入，见 deployment.yaml）。

Sidecar 容器

需要为 Operator（或插件）Pod 附加日志/指标导出等辅助容器时，使用 operator.sidecars：

operator:
  sidecars:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
    - name: portname
      containerPort: 1234

如果 sidecar 还要对外暴露额外端口，可通过 operator.service.extraPorts 在 Service 上补端口定义（插件组件对应 pluginBarmanCloud.service.extraPorts）：

operator:
  service:
    extraPorts:
    - name: extraPort
      port: 11311
      targetPort: 11311

Init 容器

同样地，可用 initContainers 在 Pod 启动前执行前置任务（如等待依赖就绪、初始化配置）：

initContainers:
  - name: your-image-name
    image: your-image
    imagePullPolicy: Always
    ports:
      - name: portname
        containerPort: 1234

通过 extraDeploy 部署 PostgreSQL Cluster 等自定义对象

Operator 本身只负责管理，实际使用的 PostgreSQL 集群实例是通过 Cluster 等 CRD 对象创建的。chart 提供了 extraDeploy 参数，允许随 chart 一起部署任意额外对象（渲染逻辑见 templates/extra-list.yaml）。原文档给出的完整示例同时创建了角色凭证 Secret 与一个 3 实例的 Cluster：

extraDeploy:
- apiVersion: v1
  kind: Secret
  metadata:
    name: my-cluster-example-user
    labels:
      cnpg.io/reload: "true"
  type: kubernetes.io/basic-auth
  stringData:
    username: my_user
    password: bitnami1234
- apiVersion: postgresql.cnpg.io/v1
  kind: Cluster
  metadata:
    name: my-cluster-example
  spec:
    instances: 3
    storage:
      size: 1Gi
    managed:
      roles:
        - name: my_user
          ensure: present
          comment: MY User
          login: true
          superuser: true
          passwordSecret:
            name: my-cluster-example-user

几点说明：

• Secret 上的 cnpg.io/reload: "true" 标签是 CloudNativePG 的约定：当 Secret 内容变化时，实例会自动重新加载配置；
• managed.roles 用于声明式管理数据库角色（ensure: present 表示确保存在），角色密码从 passwordSecret 引用的 Secret 中读取；
• 本仓库的 crds/postgresql.cnpg.io_clusters.yaml 已定义 Cluster CRD 的完整字段结构，instances、storage、managed.roles 等均可在其中核对，其他可用对象（如 ImageCatalog、ScheduledBackup、Pooler 等）同样以 CRD 形式提供，完整对象清单参见 CloudNativePG 官方文档。

Pod 亲和性（Affinity）配置

本 chart 允许通过 operator.affinity 与 pluginBarmanCloud.affinity 传入完全自定义的亲和性/反亲和性规则（对应 Kubernetes 的 affinity 与 anti-affinity 语法）。更省事的方案是使用 common 子 chart 提供的三类预设（见 common/templates/_affinities.tpl 相关实现）：

• operator.podAffinityPreset：Pod 亲和性预设，可选 soft / hard，默认 ""；
• operator.podAntiAffinityPreset：Pod 反亲和性预设，默认 soft；
• operator.nodeAffinityPreset.type / .key / .values：节点亲和性预设，例如匹配 e2e-az1、e2e-az2 等节点标签。

这三类预设与自定义 affinity 的优先级在 deployment.yaml 中明确：一旦设置了 affinity，预设值会被整体忽略。

参数总览

以下汇总全部可配置参数，均以 values.yaml 中的默认值为准。

Global 参数

参数	说明	默认值
global.imageRegistry	全局镜像仓库	""
global.imagePullSecrets	全局镜像拉取 Secret 名称数组	[]
global.defaultStorageClass	全局默认 StorageClass	""
global.security.allowInsecureImages	允许跳过镜像校验	false
global.compatibility.openshift.adaptSecurityContext	OpenShift restricted-v2 SCC 兼容适配：auto（检测到 OpenShift 时应用）/force/disabled	auto

Common 参数

参数	说明	默认值
kubeVersion	覆盖 Kubernetes 版本	""
apiVersions	覆盖 .Capabilities 报告的 API 版本	[]
nameOverride / fullnameOverride / namespaceOverride	覆盖默认名称与命名空间	""
commonLabels / commonAnnotations	附加到所有对象的标签/注解	{}
clusterDomain	集群域名	cluster.local
extraDeploy	随 release 额外部署的对象数组	[]

Operator 核心参数（节选）

参数	说明	默认值
operator.image.registry/repository/digest	Operator 镜像仓库与摘要	docker.io / bitnami/cloudnative-pg / ""
operator.image.pullPolicy	镜像拉取策略	IfNotPresent
operator.image.debug	开启 debug（追加 --log-level=trace）	false
operator.postgresqlImage.*	托管实例的 PostgreSQL 镜像	bitnami/postgresql:17.6.0-...
operator.replicaCount	Operator 副本数	1
operator.containerPorts.metrics / webhook	metrics/webhook 容器端口	8080 / 9443
operator.livenessProbe.* / readinessProbe.* / startupProbe.*	三类探针的开关与阈值	默认启用（startup 默认关闭）
operator.watchAllNamespaces	是否监视所有命名空间	true
operator.watchNamespaces	限定监视的命名空间列表（watchAllNamespaces=false 时生效）	[]
operator.maxConcurrentReconciles	最大并发协调数	10
operator.configuration / secretConfiguration	注入 Operator 配置（ConfigMap/Secret）	{}
operator.existingConfigMap / existingSecret	复用已有配置对象（与上两者互斥）	""
operator.resourcesPreset	资源预设（none/nano/micro/small/medium/large/xlarge/2xlarge）	nano
operator.resources	显式资源请求与限制	{}
operator.podSecurityContext.fsGroup	Pod 文件系统组	1001
operator.containerSecurityContext.*	容器安全上下文：runAsUser/runAsGroup=1001、runAsNonRoot=true、readOnlyRootFilesystem=true、allowPrivilegeEscalation=false、capabilities.drop=["ALL"]、seccompProfile=RuntimeDefault	—
operator.extraArgs	追加命令行参数	[]
operator.podAffinityPreset / podAntiAffinityPreset / nodeAffinityPreset.*	亲和性预设	"" / soft / ""
operator.pdb.create / minAvailable / maxUnavailable	Pod 中断预算	true / "" / ""
operator.updateStrategy.type	更新策略	RollingUpdate
operator.topologySpreadConstraints	拓扑分布约束（按模板渲染）	[]
operator.sidecars / initContainers	附加 sidecar / init 容器	[]
operator.extraEnvVars / extraEnvVarsCM / extraEnvVarsSecret	附加环境变量及其来源	[] / "" / ""
operator.extraVolumes / extraVolumeMounts	附加卷与挂载	[]
operator.webhook.validating.create / failurePolicy	校验 Webhook 开关与失败策略	true / Fail
operator.webhook.mutating.create / failurePolicy	变更 Webhook 开关与失败策略	true / Fail
operator.autoscaling.hpa.enabled / minReplicas / maxReplicas / targetCPU / targetMemory	HPA 自动扩缩	false / ""
operator.autoscaling.vpa.enabled / updateMode	VPA 垂直扩缩（updateMode 可选 Off/Initial/Recreate/Auto）	false / Auto
operator.service.type / ports.webhook / extraPorts	Service 类型、webhook 端口与附加端口	ClusterIP / 443 / []
operator.networkPolicy.enabled / kubeAPIServerPorts	网络策略开关与 kube-apiserver 端口	true / [443, 6443, 8443]
operator.rbac.create / rules	RBAC 开关与自定义规则	true / []
operator.serviceAccount.create / name / annotations	ServiceAccount 配置	true / "" / {}
operator.metrics.enabled	启用 Prometheus 指标	false
operator.metrics.monitoringQueries.useSecret / overrideConfiguration / existingQueries	监控查询配置	false / {} / ""
operator.metrics.service.ports.metrics	指标 Service 端口	80
operator.metrics.serviceMonitor.enabled	创建 ServiceMonitor（需 metrics.enabled=true）	false
operator.metrics.serviceMonitor.interval / scrapeTimeout / relabelings 等	ServiceMonitor 抓取细节	""

plugin-barman-cloud 参数（节选）

参数	说明	默认值
pluginBarmanCloud.enabled	启用 Barman Cloud 插件	true
pluginBarmanCloud.image.*	插件主镜像	bitnami/plugin-barman-cloud:0.6.0-...
pluginBarmanCloud.sidecarImage.*	插件 sidecar 镜像	bitnami/plugin-barman-cloud-sidecar:0.6.0-...
pluginBarmanCloud.replicaCount	插件副本数	1
pluginBarmanCloud.containerPorts.metrics/grpc/health	容器端口	8080 / 9443 / 8921
pluginBarmanCloud.tls.server.* / tls.client.*	服务端/客户端 TLS 证书（existingSecret 优先于 cert/key）	""
pluginBarmanCloud.tls.autoGenerated.enabled / engine	自动生成证书（helm / cert-manager）	true / helm
pluginBarmanCloud.tls.autoGenerated.certManager.*	cert-manager 引擎参数：existingIssuer、keyAlgorithm=RSA、keySize=2048、duration=2160h、renewBefore=360h	—
pluginBarmanCloud.resources / resourcesPreset	资源设置（与 Operator 同构）	{} / nano
pluginBarmanCloud.service.ports.grpc	gRPC Service 端口	9090
pluginBarmanCloud.metrics.enabled	启用插件指标	false
pluginBarmanCloud.metrics.allowedServiceAccounts	允许访问 metrics 端点的 ServiceAccount（含命名空间）列表	[]
pluginBarmanCloud.metrics.serviceMonitor.enabled	插件 ServiceMonitor	false
pluginBarmanCloud.rbac.* / serviceAccount.* / networkPolicy.* / autoscaling.*	与 Operator 同构的 RBAC、网络策略、自动扩缩参数	—

说明：以上参数映射到 bitnami/cloudnative-pg 容器镜像 中定义的环境变量，安装时既可用 --set key=value 逐项传入，也可用 -f values.yaml 整体导入。

需要特别留意的一点（原文档强调）：chart 部署完成后，无法通过 Helm 直接修改应用访问凭据。若部署后需要更换用户名/密码等凭据，应删除 chart 使用的持久卷（PV）后重新部署，或使用应用自带的运维工具进行修改。

升级注意事项：1.0.0 版本的结构重构

本 chart 在升级到 1.0.0 时进行了一次大的参数结构重构（详见 CHANGELOG.md）：

• 所有 CloudNativePG 设置被迁移到 operator.* 段下；
• 新增 pluginBarmanCloud.* 段，收纳 plugin-barman-cloud 部署的全部参数（该插件默认启用）。

只要把原有参数引用迁移到新结构，升级过程通常不会遇到大问题。

故障排查

遇到 Bitnami Helm chart 常见问题时，可参考 Bitnami 官方的 Helm chart 故障排查指南（docs.bitnami.com 上的 "troubleshoot-helm-chart-issues" 主题），覆盖诸如探针失败、镜像拉取失败、RBAC 权限不足、Webhook 未注册、ServiceMonitor CRD 缺失（即上文 no matches for kind "ServiceMonitor"）等典型场景。

小结

通过本仓库的 Bitnami CloudNativePG chart，你可以用 Helm 在 Kubernetes 上快速获得：

1. 声明式 PostgreSQL 生命周期管理：通过内置 CRD（Cluster、Backup、Pooler 等）与 extraDeploy 直接编排实例；
2. 生产级安全基座：非 root 运行、只读根文件系统、丢弃全部 capabilities、seccomp RuntimeDefault、默认 NetworkPolicy 与 PDB；
3. 可观测性：Operator 与数据库双轨 Prometheus 指标、内置 pg_catalog 监控查询，以及可选的 ServiceMonitor 集成；
4. 云备份能力：通过 plugin-barman-cloud 插件对接对象存储，且 TLS 证书自动生成开箱即用；
5. 灵活扩展：sidecar、init 容器、额外环境变量、自定义亲和性与资源控制一应俱全。

深入阅读 values.yaml 与 templates/ 下的模板文件，可以进一步掌握每个参数到最终 Kubernetes 清单的映射关系，从而在真实生产环境中做出精准调优。