在 Kubernetes 里跑 PostgreSQL 19 Beta：用 CloudNativePG 快速上手

预计阅读时间：8 分钟

PostgreSQL 19 已进入 beta 阶段，社区开放了 beta 测试计划，邀请用户提前验证新特性与兼容性。如果你的工作负载已经跑在 Kubernetes 上，CloudNativePG operator 是目前最顺手的路径——它原生支持指定 PostgreSQL 版本镜像，一条声明就能拉起一个完整的 PG 集群，不需要手动拼 PVC、ConfigMap 和 init 脚本。

下面直接进入实操。

CloudNativePG 的版本管理机制

CloudNativePG（简称 CNPG）把 PostgreSQL 版本当作 operator 的核心配置维度。operator 内置了一份版本 catalogue，每个版本对应一组容器镜像标签和默认参数。当你声明 cluster.spec.postgres.version 为 "19" 时，operator 会自动选择对应的 beta 镜像（目前是 19beta1 标签），并完成实例初始化、PVC 绑定、Service 暴露等全部工作。

需要注意：beta 版本不在默认 catalogue 的稳定列表里，你需要确认 operator 版本是否已收录 19 beta 的镜像引用。如果尚未收录，可以手动指定镜像标签来绕过。

最小化部署：一个 YAML 拉起 PG 19 Beta

假设你已经安装了 CNPG operator（最低建议 v1.24+，该版本已包含 PG 19 beta 支持）。以下 YAML 是一个可直接复制运行的集群声明：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg19-beta-demo
spec:
  instances: 3
  postgres:
    version: "19"
  storage:
    size: 1Gi
    storageClass: standard
  monitoring:
    enablePodMonitor: true
  backup:
    enabled: false   # beta 测试阶段先关掉备份，减少依赖
  affinity:
    nodeSelector:
      kubernetes.io/os: linux

保存为 pg19-beta-cluster.yaml，然后执行：

# 确认 operator 已安装
kubectl get deployment -n cnpg-system cnpg-controller-manager

# 创建命名空间（建议隔离）
kubectl create ns pg19-beta

# 部署集群
kubectl apply -n pg19-beta -f pg19-beta-cluster.yaml

# 观察集群状态，等待 Ready
kubectl get cluster -n pg19-beta pg19-beta-demo -w

几分钟后，三个实例会依次进入 Ready 状态。你可以用以下命令确认 PostgreSQL 版本：

# 获取 primary Pod 名称
PRIMARY=$(kubectl get cluster -n pg19-beta pg19-beta-demo \
  -o jsonpath='{.status.currentPrimary}')

# 进入 Pod 查询版本
kubectl exec -n pg19-beta "$PRIMARY" -c postgres \
  -- psql -U postgres -c "SELECT version();"

预期输出会包含 PostgreSQL 19beta1 字样。

手动指定镜像标签（适配未收录场景）

如果你的 operator 版本 catalogue 还没有 PG 19 beta 条目，可以显式指定镜像：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg19-beta-manual
spec:
  instances: 1
  imageName: ghcr.io/cloudnative-pg/postgresql:19beta1
  postgres:
    version: "19"
  storage:
    size: 1Gi

imageName 字段会覆盖 catalogue 的默认选择。镜像地址以 CloudNativePG 官方 GHCR 仓库为准；如果你在国内环境拉取慢，可以提前 mirror 到私有仓库，再把 imageName 改为私有地址。

连接集群与跑测试

CNPG 会自动创建 Service。默认 -rw Service 指向 primary，-r Service 指向 replicas。连接方式：

# 获取 Service 名称
kubectl get svc -n pg19-beta -l cnpg.io/cluster=pg19-beta-demo

# 用 psql 通过 Service 连接（集群内部）
kubectl run -n pg19-beta psql-client --image=postgres:17 --rm -it --restart=Never \
  -- psql -h pg19-beta-demo-rw -U postgres

如果你想在集群外部访问，可以临时用 port-forward：

kubectl port-forward -n pg19-beta svc/pg19-beta-demo-rw 5432:5432 &
psql -h localhost -p 5432 -U postgres

连接成功后，可以针对 PG 19 的新特性编写测试 SQL。比如验证新增的系统视图、参数默认值变化、或你业务依赖的扩展兼容性：

-- 检查关键扩展是否可用
SELECT name, default_version FROM pg_available_extensions
WHERE name IN ('pg_stat_statements', 'pgvector', 'btree_gist');

-- 检查新参数默认值
SHOW logical_decoding_work_mem;

Beta 测试的注意事项

跑 beta 不是日常运维，有几件事必须提前想清楚：

数据不要用于生产。 Beta 版本可能存在未公布的 bug，存储格式也可能在正式发布前变更。一旦升级到 RC 或正式版，in-place 升级路径不一定保证可用。建议用测试数据集，或从生产快照 restore 一份到隔离命名空间。

版本回退困难。 PostgreSQL 不支持跨 major 版本 downgrade。如果 19 beta 出问题，你需要删掉 PVC 重建集群，用旧版本镜像从备份恢复。所以上面示例里我默认关掉了备份——如果你有真实数据，反而应该打开并验证备份流程本身。

扩展兼容性。 很多第三方扩展（pgvector、PostGIS 等）需要等维护者发布对应 19 的编译版本。在 CNPG 里，你可以通过 spec.postgres.extensions 声明需要加载的扩展，但前提是镜像里已经编译了对应版本。如果缺失，需要自行构建自定义镜像。

资源与监控。 CNPG 默认会创建 PodMonitor 对象对接 Prometheus。beta 测试期间建议开启，重点关注 WAL 积压、replication lag 和连接数突增——这些指标能帮你快速定位是 PG 19 的行为变化还是 operator 配置问题。

上手清单

在动手之前，按这个清单逐项确认：

Kubernetes 集群版本 ≥ 1.28，节点有足够磁盘和内存。
CNPG operator ≥ v1.24 已安装，确认 cnpg-system 命名空间下 controller 正常运行。
StorageClass 可用，PVC 能正常绑定（kubectl get sc 确认）。
镜像可拉取：国内环境提前 mirror ghcr.io/cloudnative-pg/postgresql:19beta1。
测试数据集准备完毕，不使用生产数据。
监控栈（Prometheus + Grafana）就位，或至少准备好 kubectl top pod 观察资源。

PostgreSQL 19 beta 是一个窗口期，提前在 Kubernetes 里跑一遍，既能帮社区发现问题，也能让你在正式发布时无缝切换。用 CNPG 把部署成本压到一条 YAML，剩下的精力就该全部放在验证业务逻辑和扩展兼容性上。