CloudNativePG 1.30 发布说明：Primary Lease 安全选举、DatabaseRole 独立 CRD 与安全加固全面解析

CloudNativePG 1.30 发布说明Primary Lease 安全选举、DatabaseRole 独立 CRD 与安全加固全面解析【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg本篇技术指南基于 CloudNativePG 1.30 官方发布说明仓库 docs/src/release_notes/v1.30.md逐条梳理该版本引入的破坏性变化、核心新特性、增强项与安全修复并对照当前仓库源码api/v1、internal/controller、internal/management等给出实现层面的佐证与解读。读者读完本篇后将掌握 1.30 中primaryLease主节点选举机制、DatabaseRole声明式角色管理、PgBouncer 镜像目录化、三项安全公告的防护原理以及一批直接影响集群稳定性的 Bug 修复细节可作为从 1.29 及更早版本升级前的重要决策参考。版本概览CloudNativePG 1.30 是 1.x 系列的一个重要功能版本发布于2026 年 6 月 29 日即Version 1.30.0的 Release date。本版本的核心叙事可以概括为四条主线主节点选举机制的显式化引入 KubernetesLease对象作为主节点提升的互斥锁把谁有资格成为主节点的时序决策交给可配置的.spec.primaryLease节stanza为更快的干净切换clean switchover铺路。声明式角色管理的独立化新增DatabaseRole自定义资源CRD把原先内嵌在Cluster.spec.managed.roles中的角色管理拆分成独立的 Kubernetes 对象每个角色拥有独立的生命周期、状态与 RBAC。安全公告集中落地本版本同时修复/缓解了三个安全公告CVE-2026-55769/GHSA-x8c2-3p4r-v9r6、GHSA-7qwx-x8ff-3px9、CVE-2026-55765/GHSA-w3gf-xc94-wvmj涉及search_path固定、操作者到实例管理器的双向认证、SCRAM 密码编码等底层机制。平台基线前移支持 Kubernetes 1.36默认 PostgreSQL 镜像更新为 18.4。支持版本矩阵依据发布说明1.30 版本支持Kubernetes1.36、1.35、1.34PostgreSQL18、17、16、15、14其中18.4 为默认镜像注意PostgreSQL 14 的支持将于 2026 年 11 月 12 日结束仍在 14 上运行的用户应提前规划升级窗口重要变化Breaking ChangesBarman Cloud 原生支持弃用时间线延后1.30 更新了原生in-treeBarman Cloud 支持的弃用公告其移除时间从 1.30.0 调整为1.31.0。官方仍强烈建议用户迁移到 Barman Cloud 插件Barman Cloud Plugin。对于在集群上直接配置barmanObjectStore并通过操作者内置逻辑对接 S3/Azure Blob/Google Cloud Storage 的用户这意味着还有一个次要版本的缓冲期来规划迁移新部署应直接使用插件方案。cluster引用在多个 CRD 上变为不可变从 1.30 起Database、Pooler、Publication、Subscription、ScheduledBackup这五类资源中的cluster引用在创建后不可修改。此前将这些对象指向另一个集群在语义上没有明确定义且会让控制器处于不一致状态现在更新操作会在 API Server 层被CELCommon Expression Language校验规则直接拒绝。在仓库中可以看到同源的 CEL 规则实现例如 api/v1/database_types.go// The name of the PostgreSQL cluster hosting the database. // kubebuilder:validation:XValidation:ruleself oldSelf,messagecluster reference is immutable after creation ClusterRef corev1.LocalObjectReference json:clusterDatabaseRole同样带有cluster reference is immutable after creation的 CEL 规则见 api/v1/databaserole_types.go。这一类创建后不可变校验由kubebuilder标记生成到 CRD 的x-kubernetes-validations中可对照 config/crd/bases/postgresql.cnpg.io_databases.yaml 等生成产物在对象更新请求进入 etcd 之前就完成拦截。新特性详解主节点Lease基于 Kubernetes 互斥锁的安全主节点选举1.30 引入了一个以集群名命名的 KubernetesLease对象作为串行化主节点提升的互斥锁mutex。其工作机制如下持有实例管理器instance manager必须先持有该Lease才有资格以主节点身份运行释放主节点在干净停机clean shutdown时显式释放Lease副本无需等待完整的租约 TTL 即可触发提升从而显著缩短切换窗口边界官方明确该Lease是提升门控promotion gate而非围栏fence——主节点隔离primary isolation的围栏职责仍由既有机制fencing承担两者不可混为一谈。Lease的创建与归属由操作者侧完成。在 internal/controller/primary_lease.go 中reconcilePrimaryLease确保一个与集群同名的coordinationv1.Lease存在且归属于集群并使用继承的数据与所有权SetInheritedDataAndOwnership管理其元数据同一文件中的primaryLeasePredicate只对Lease的删除事件入队父级Cluster避免每几秒一次的续租更新触发协调风暴。.spec.primaryLease配置节所有时序均可通过新的.spec.primaryLease节配置其类型定义位于 api/v1/cluster_types.go字段默认值语义leaseDurationSeconds15主节点租约在被其他实例接管前的有效时长必须大于renewDeadlineSeconds最小 1renewDeadlineSeconds10当前主节点持续尝试续租直至放弃的截止时间必须小于leaseDurationSeconds最小 1retryPeriodSeconds2非持有者尝试获取/续租的间隔最小 1值越小干净释放的租约被候选者感知得越快切换越快releasedLeaseDurationSeconds1主节点干净停机时写入的 TTL使副本无需等待完整租约时长即可提升最小 1四个字段均直接映射到底层 Kubernetes leader-election 参数操作者侧通过 api/v1/cluster_funcs.go 中的GetPrimaryLeaseDuration、GetPrimaryLeaseRenewDeadline、GetPrimaryLeaseRetryPeriod、GetPrimaryLeaseReleasedDuration读取未配置时回落到默认常量DefaultPrimaryLeaseDurationSeconds 15、DefaultPrimaryLeaseRenewDeadlineSeconds 10等见 api/v1/cluster_types.go。配置示例apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example spec: primaryLease: leaseDurationSeconds: 15 renewDeadlineSeconds: 10 retryPeriodSeconds: 2 releasedLeaseDurationSeconds: 1官方提醒这些参数与故障切换时序直接相关仅在充分理解其对 failover 时序影响的前提下调整。DatabaseRoleCRD声明式角色管理的独立对象1.30 新增DatabaseRole自定义资源将 PostgreSQL 角色作为独立的 Kubernetes 对象管理替代原先内嵌在Cluster.spec.managed.roles中的声明方式。每个角色拥有独立的生命周期、状态和 RBAC特别适合 GitOps 工作流——角色定义可以和应用放在一起由拥有该应用的团队独立维护。从源码看DatabaseRoleSpecapi/v1/databaserole_types.go内嵌复用了与 inline 方式完全相同的RoleConfiguration结构因此迁移一个角色的成本极低把Cluster中managed.roles里对应的角色条目搬到独立 manifest 即可。apiVersion: postgresql.cnpg.io/v1 kind: DatabaseRole metadata: name: role-dante spec: cluster: name: cluster-example name: dante comment: Dante Alighieri login: true superuser: false createdb: true databaseRoleReclaimPolicy: delete inRoles: - pg_monitor passwordSecret: name: cluster-example-dante示例结构可对照 docs/src/declarative_role_management.md回收策略databaseRoleReclaimPolicy该字段控制DatabaseRole被删除时角色的归宿语义对标 Kubernetes Persistent Volume 的回收策略retain默认角色保留在数据库中。这是生产环境最安全的选择——即使 manifest 被误删数据库用户及其拥有的对象也不受影响delete操作者在 Kubernetes 对象终结前尝试执行DROP ROLE适合临时或自动化环境。需要注意的是如果角色拥有对象表、schema 等DROP ROLE会失败DatabaseRole会停留在Terminating状态并周期性重试操作者不会替你删除被拥有的对象——需要先在 PostgreSQL 中 reassign/drop 这些对象或改用retain策略放行删除。角色预置校验DatabaseRoleSpec上还叠加了多条 CEL 预置校验api/v1/databaserole_types.go在创建时即拦截非法配置name不可变ensure不接受absent删除角色应通过删除资源配合回收策略完成postgres、streaming_replica为保留角色名pg_前缀PostgreSQL 保留与cnpg_前缀操作者保留均被禁止角色名不允许为空passwordSecret与disablePassword互斥clientCertificate要求角色启用login。状态与可观测性DatabaseRoleStatusapi/v1/databaserole_types.go提供了逐角色的可观测性applied角色是否被正确协调message协调错误信息secretResourceVersion最近一次应用到角色的密码 Secret 的 resourceVersion其变化会触发重新协调conditions例如PasswordSecretChange条件见 docs/src/declarative_role_management.md其 message 携带操作者观察到的密码 Secret 的resourceVersion作为实例管理器重新应用密码的内部信号clientCertificateTLS 客户端证书的签发状态有效期、说明。DatabaseRole是命名空间级资源spec.cluster指向的Cluster与passwordSecret必须与它同命名空间。另外需要留意共存优先级规则若同一角色名同时出现在Cluster.spec.managed.roles与DatabaseRole中Cluster 内联声明始终优先DatabaseRole不会被协调并在状态中报告database role is already managed by the CNPG cluster。TLS 客户端证书免密cert认证配合DatabaseRole1.30 支持在角色上配置clientCertificate块由操作者自动签发并续期 TLS 客户端证书证书由集群的client CA签发存储在名为databaserole-name-client-cert的 Secret 中后缀常量见 api/v1/databaserole_types.go该能力使得 PostgreSQL 的cert认证无需密码即可工作当该功能被禁用或DatabaseRole被删除时对应 Secret 会被清理。配置形式apiVersion: postgresql.cnpg.io/v1 kind: DatabaseRole metadata: name: role-cert spec: cluster: name: cluster-example name: appuser login: true clientCertificate: enabled: true对应配置类型ClientCertificateConfiguration含默认enabled: true与状态类型ClientCertificateStateExpiration、Message均定义在 api/v1/databaserole_types.go。启用客户端证书要求角色具有login权限CEL 规则强制。PgBouncer 镜像目录化Pooler通过 ImageCatalog 管理镜像1.30 为Pooler增加了spec.pgbouncer.imageCatalogRef字段使 PgBouncer 镜像可以引用ImageCatalog或ClusterImageCatalog中的条目实现镜像的集中管理自动滚动更新当目录条目更新时所有引用它的Pooler会被自动协调并滚动到新镜像无需修改任何Poolerspec解析结果上报解析后的镜像被报告在status.image生命周期阶段新增status.phase取值为active、paused、inactive、failed并作为kubectl get pooler输出中的Phase列展示。从源码可以看到完整的字段约束与阶段定义。在 api/v1/pooler_types.go 中PgBouncerSpec声明image与imageCatalogRef互斥CEL 规则image and imageCatalogRef are mutually exclusiveImageCatalogRef类型即ImageCatalogComponentRef。四种阶段的语义在 api/v1/pooler_types.go 中有明确注释activePgBouncer 正常运行并服务流量pausedPgBouncer 已启动但持有新客户端连接spec.pgbouncer.paused: trueDeployment 仍持续协调解除暂停即回到activeinactive因前置资源缺失Cluster、Secret、证书无法推进控制器周期性重试具体原因见status.phaseReasonfailed因配置错误无法协调详见status.phaseReason。PoolerStatus相应新增phase、phaseReason与image字段api/v1/pooler_types.go并通过kubebuilder:printcolumn:namePhase,JSONPath.status.phase暴露到kubectl get pooler输出api/v1/pooler_types.go。增强项pg_upgrade原地大版本升级支持 Image Volume 扩展1.30 允许使用Image Volume 扩展的集群通过pg_upgrade原地升级到 PostgreSQL 19 及更高版本。这建立在 PostgreSQL 19 为pg_upgrade增加的 extension-path 支持之上升级Job运行期间源版本与目标版本的扩展镜像会被并排挂载因此旧服务端保留其库文件一旦升级失败可以干净地回滚。Pooler 指标端点支持 TLSPooler新增.spec.monitoring.tls.enabled开启后指标服务器以 HTTPS 提供服务复用.spec.pgbouncer.clientTLSSecret中的证书与私钥每次握手都会重新加载证书支持轮换而无需重启生成的PodMonitor相应地以https协议抓取。Cluster 成为 VPA/HPA 的合法targetRefCluster的 scale 子资源新增标签选择器status.selector使Cluster成为 Vertical Pod AutoscalerVPA与 Horizontal Pod AutoscalerHPA的合法targetRef——它们现在可以将Cluster映射到其实例 Pod 上。该功能由社区贡献者 sebv004 提供。PrimaryStatusCheckFailed告警事件当主 Pod 在 kubelet 视角已Ready但操作者的/pg/status检查失败、故障切换被推迟时操作者会在Cluster上发出Warning级别的PrimaryStatusCheckFailed事件。这样通过kubectl describe cluster即可看到切换延迟的原因。相关实现位于 internal/controller/cluster_controller.go操作者将 kubelet 的 readiness 探针视为事实来源在 Kubernetes 确认主节点未 Ready 之前不自行发起故障切换并通过事件记录器event recorder按原因 消息去重使持续故障汇总为一条计数增长的逻辑事件。对应的单元测试断言事件以Warning PrimaryStatusCheckFailed前缀产生见 internal/controller/cluster_controller_test.go。ENABLE_WEBHOOK_NAMESPACE_SUFFIX多实例共存新增ENABLE_WEBHOOK_NAMESPACE_SUFFIX标志为操作者的 webhook 配置名追加-OPERATOR_NAMESPACE后缀从而允许同一集群上并存多个操作者实例。注意操作者只负责查找这些配置创建与维护仍需用户自行完成。该功能由 maxlengdell 贡献。CNPG-i 插件随 Pod 滚动自动重载操作者现在会监听支撑插件Service的EndpointSlices当插件的 Pod 被滚动、新 Pod 变为Ready后操作者会重新入队所有使用该插件的集群使升级后的插件无需等待下一次 resync即被拾取。实例序号复用与Initialized条件实例序号serial的分配从全局计数器递增改为复用已有实例名中的最低空闲槽位Pod 与 PVC 名称在实例重建后保持稳定例如节点 drain 后重建的实例仍沿用原名被删除实例释放的序号会被回收复用新增Initialized集群条件报告集群是否完成首次 bootstrapstatus.latestGeneratedNode被弃用不再写入但保留在 CRD 上以兼容旧版本。协调期默认值与校验回退当准入 webhook 不可用或被配置为忽略失败时默认值与校验现在会在协调过程中作为回退机制运行操作者不再对无效或不完整的 spec 进行协调缺失的默认值会被直接补全校验失败会在资源状态中显式暴露而不是在后期静默失败。安全公告与加固1.30 集中处理了三项安全公告均与底层连接与认证机制相关建议所有部署认真对待。CVE-2026-55769/GHSA-x8c2-3p4r-v9r6search_path固定问题数据库所有者可以在publicschema 中植入重载的内建操作符并修改search_path使以集群超级用户身份运行的操作符自省探测operator introspection probes在pg_catalog之前解析到这些重载——这是一条CWE-426不受信任的搜索路径特权提升链与CVE-2018-1058同类最坏可通过COPY ... FROM PROGRAM升级为 Pod 内任意代码执行RCE。修复操作者在每条池化连接上固定search_path pg_catalog, public, pg_temp使其随启动消息startup message下发并优先于租户可控的默认值。GHSA-7qwx-x8ff-3px9操作者到实例管理器的认证调用问题实例管理器的远程 Web 服务在仅操作者可用的控制端点上依赖网络隔离而非认证任何能触达 Pod 状态端口status port的第三方都能调用这些端点干扰备份编排与 WAL 归档并读取运行期元数据。升级端点做了 SHA-256 固定因此本问题不允许任意代码执行。修复操作者启动时生成内存中的 ECDSA P-256 客户端证书并将其 SHA-256 指纹协调进集群状态实例管理器会拒绝未携带匹配证书的敏感端点请求。注意此加固未回移植到更早版本旧版本应继续通过NetworkPolicy限制状态端口的访问。CVE-2026-55765/GHSA-w3gf-xc94-wvmj操作者侧 SCRAM-SHA-256 密码编码问题此前操作者以明文向CREATE/ALTER ROLE ... PASSWORD下发角色密码明文会被 PostgreSQL 解析并可能被pg_stat_statements、pgaudit等扩展捕获。修复操作者在签发CREATE/ALTER ROLE ... PASSWORD前先将明文密码做SCRAM-SHA-256 编码使 PostgreSQL 解析到的字面量是 SCRAM 验证器而非明文。已在数据库中预哈希MD5 或 SCRAM的值会原样透传。退出开关在 Secret 上添加注解cnpg.io/passwordPassthrough: enabled可退出该行为。源码佐证在 internal/management/controller/roles/contract.go 中passwordPassthrough字段注释明确说明其由 Secret 上的cnpg.io/passwordPassthrough注解填充在 internal/management/controller/roles/postgres.go 中角色协调逻辑只有在未开启 passthrough 时才调用postgresutils.EnsureEncryptedPassword(literal)对明文做加密编码否则原样发送字面量。平台与默认版本变化Kubernetes 1.36加入支持矩阵默认 PostgreSQL 版本更新为 18.4同步更新了公有云提供商上用于测试操作者的 Kubernetes 版本组合。修复盘点按主题归类1.30 的 Fixes 数量较多这里按影响域归类方便对照自身环境评估升级收益。声明式对象与副本集群replica cluster修复Database、Publication、Subscription在集群降级为副本后永久上报陈旧的主节点侧状态的问题——控制器现在会重新检查副本条件并监听Cluster从而及时感知降级修复副本集群上Database、Publication、Subscription删除卡在Terminating的问题此前副本门控先于 finalizer 协调器运行导致 finalizer 永不释放在副本上PostgreSQL 对象交由主集群处理修复重复的Database或Subscription冲突时delete回收策略误删幸存 CR 所拥有的 PostgreSQL 对象的问题——删除操作现在以一次已记录的协调为前置条件。实例生命周期与存储修复非连续 Pod 名称如-1、-3实例序号计数器此前在对应Job与 PVC 创建之前就递增现在仅在那些资源存在后才持久化递增修复删除实例 PVC 时的竞态若数据 PVC 被移除而 WAL PVC 仍在 Terminating操作者会重建绑定到终止中卷的实例导致 Pod 不可调度并阻塞后续协调——现在操作者会等待终止中的 PVC 完全移除后再重建/重挂实例并通过日志行与集群 phase 暴露等待状态修复pg_basebackupbootstrap 路径覆盖或失败于已存在的PGDATA例如副本 Pod 重启后的问题——现在强制实施与其他 bootstrap 方式相同的预检目录检查同时保护静态供应的 PVC 不被静默覆盖。备份与恢复修复备份卡在started阶段当运行备份的实例管理器在备份进入running前被重启例如操作者升级后的原地升级协调会被重新调度以检测丢失的会话修复并发Backup对象竞态导致的资源泄漏备份现在按严格的创建时间顺序执行正在执行的备份不会被新备份抢占复制槽replication slot与 PostgreSQL 会话不再在主节点上被孤儿化修复ScheduledBackup控制器循环当Backup已创建但其状态补丁未落地时控制器会在下一轮采纳既有Backup而非在AlreadyExists上死循环修复从对象存储 bootstrap 恢复时的竞态恢复Job可能读到陈旧Cluster主节点未记录、timeline 未设置其.history文件被脑裂保护拒绝导致恢复停在基础备份的 timeline 上并静默丢弃后续 timeline 上提交的事务——现在集群 timeline 未设置时允许 history 文件修复声明式VolumeSnapshot备份在陈旧缓存导致重复创建快照时被永久标记为失败的问题——现在当既有快照携带该备份的标签时操作者会容忍冲突并采纳之外部快照冲突仍报错修复卷快照备份在 finalize 阶段遇到瞬时实例管理器连接错误如短暂的 Pod 网络中断导致的拨号超时时被丢弃的问题——此类网络错误现在会被重试而非视为终态。角色与认证修复postgres超级用户在禁用又启用超级用户访问后被锁死的问题缓存的 Secret 版本未失效、密码未重新应用修复角色协调在引用 Secret 无法获取时清空角色密码的问题——现在 Secret 可用前角色保持不变且按动作聚合错误以提升可见性。Bootstrap、升级与滚动修复 metrics-exporter 设置错误通常是与控制器的重复键竞态回滚streaming_replica创建并卡死副本加入的 bootstrap 失败——metrics-exporter 步骤现在在独立事务中运行修复启用 WAL-archiver 插件的既有集群上的切换死锁primaryUpdateMethod: switchover时干净降级需要尚缺失的 archiver sidecar导致主节点无法滚动——现在操作者会在原位置重建主 Pod 以注入 sidecar 恢复归档该检查同样覆盖以 init 容器 restartPolicy: Always注入原生 sidecar 的插件如 Barman Cloud 插件修复实例创建Job用尽 backoff limit 后集群无限停留在Setting up primary的问题——现在操作者检测到终态Job失败后会将集群标记为不可恢复并指名失败Job及其日志修复首次主节点 bootstrap 死锁数据 PVC 创建后、初始化Job启动前的状态补丁冲突会让孤儿 Pending PVC 被计为实例阻塞 bootstrap 门控——PVC 状态协调器现在会复用已分配序号重建 bootstrapJob修复集群创建时服务端与客户端 CA 解析到同一 Secret默认情况时的缓存竞态陈旧 informer 缓存触发冗余Create并报AlreadyExists可能让集群卡在Unable to create required cluster objects——现在名称匹配时操作者直接复用已获取的 CA Secret修复外部服务器 Secret 轮换如 CA bundle 从两张证书缩到一张后的陈旧证书数据与部分读取——文件现在原子写入libpq 只会读到旧值或新值不会读到混合内容。网络、连接与插件修复exec/attach流式传输现在协商 WebSocket 并回退 SPDY同时兼容已移除 SPDY 的 Kubernetes 版本与拒绝 WebSocket exec 升级的平台如 OpenShift修复 IPv6 URL 生成地址现在用方括号包裹修复外部集群插件在配置enabled: false时仍被当作活动插件的问题修复插件连通性改用插件Service的 FQDN 而非短名避免集群级代理自动注入 Pod 时导致的失败修复Clusterphase 在 post-reconcile 插件钩子返回错误时在Healthy与插件失败 phase 间抖动的问题——Healthy现在被登记为成功协调的最后一步因此以插件错误结尾的循环永远不会上报Healthy修复外部集群名与 Secret selector 引用在未校验情况下被拼入文件系统路径的问题——..或路径分隔符可能逃逸外部 Secrets 目录实例管理器倾倒连接材料时触发这些值现在会在校验 webhook 与写入点双重检查。控制器与协调健壮性修复并发备份门控在每次协调都运行、可能覆盖实例管理器异步写入的已完成 phase导致备份永久卡在pending的问题——门控现在仅在备份 phase 尚未设置或仍为pending时运行修复副本切换时在存储 token 与清理转换元数据之间被重新入队导致丢失status.demotionToken的问题——空的无变化 token 不再被回补覆盖已存储值修复Pooler的Cluster被删除时协调出现的空指针 panic修复WithActiveInstance期间部分命名日志管道postgres、postgres.csv、postgres.json没有消费者、导致普通文件替代命名管道生成的问题修复spec.postgresql.parameters接受非法的 PostgreSQL 参数名、可能向postgresql.conf注入任意指令的问题——键名现在由 webhook 校验修复每次请求的Clustercreate/update 校验 webhook 消息日志噪音过大从info降为debug。cnpg插件kubectl 插件修复 Windows 上kubectl cnpg psql依赖 Unix-only 系统调用而报 not supported by windows 的问题——Windows 现在以子进程方式启动kubectl exec修复繁忙集群上kubectl cnpg logs -f的无界内存泄漏——每个日志组的计时器此前从不释放现在在迭代间复用。升级建议与小结综合来看1.30 是一次底层机制 顶层 API双线并进的重要版本若你正在使用内建 Barman Cloud 支持请在 1.31 移除前完成到 Barman Cloud 插件的迁移若你的Database/Pooler/Publication/Subscription/ScheduledBackup存在跨集群改引用的自动化流程需注意cluster引用已不可变需调整脚本为先删后建三项安全公告中GHSA-7qwx-x8ff-3px9的加固未回移旧版本用户应继续用NetworkPolicy限制状态端口新增的DatabaseRole与primaryLease属于新能力可在小范围集群验证后推广升级前建议通读本文修复盘点确认哪些修复命中你的已知问题尤其是备份卡死、PVC 删除竞态与副本集群删除卡Terminating三类高频故障。如需深入了解相关 API 的完整字段定义可继续查阅 api/v1/databaserole_types.go、api/v1/pooler_types.go 与 api/v1/cluster_types.go以及角色管理的完整用户指南 docs/src/declarative_role_management.md。历史版本发布说明见 docs/src/release_notes/。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考