CloudNativePG PostgreSQL 配置完全指南：postgresql.conf、pg_hba.conf 与 pg_ident.conf 的声明式管理

CloudNativePG PostgreSQL 配置完全指南：postgresql.conf、pg_hba.conf 与 pg_ident.conf 的声明式管理

【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg

CloudNativePG 遵循声明式配置与容器不可变原则，不允许用户直接修改 Pod 内的 PostgreSQL 配置文件，而是通过Cluster资源中的postgresql字段，以声明式方式统一管理postgresql.conf、pg_hba.conf和pg_ident.conf三大核心配置。本文将以官方文档 docs/src/postgresql_conf.md 为主线，结合仓库源码（如 pkg/management/postgres/configuration.go、pkg/postgres/configuration.go、api/v1/cluster_types.go）深入剖析各配置项的生成逻辑、固定参数约束与实操示例，帮助读者掌握在 CloudNativePG 上安全、正确地配置 PostgreSQL 实例的完整方法。

为什么不能直接修改配置文件

熟悉 PostgreSQL 的读者都知道，一个实例通常由三个文件决定其行为：

• postgresql.conf：PostgreSQL 主运行时配置文件
• pg_hba.conf：客户端认证（Host Based Authentication）文件
• pg_ident.conf：外部系统用户到数据库用户的映射文件

但在 CloudNativePG 中，由于"声明式配置"和"PostgreSQL 容器不可变"两大设计原则，用户被禁止直接触碰这些文件。所有配置都必须通过Cluster资源定义中的postgresql字段来完成，具体对应三个键：

• parameters：自定义postgresql.conf参数
• pg_hba：自定义pg_hba.conf规则
• pg_ident：自定义pg_ident.conf映射规则

这些设置会应用到集群内的所有实例，确保配置的一致性。

警告：禁止使用ALTER SYSTEM强制修改配置不要用ALTER SYSTEM命令以命令式方式修改 PostgreSQL 实例配置。修改某些由 operator 控制的参数可能导致集群进入不可预测/不可恢复的状态，而且ALTER SYSTEM的修改不会在集群内复制。如需启用，见下文「启用ALTER SYSTEM」章节。

一个完整的自定义配置参考示例见仓库中的 docs/src/samples/cluster-example-custom.yaml。

postgresql配置段的生成机制

Pod 内的 PostgreSQL 实例以默认的postgresql.conf启动，operator 会自动在文件末尾追加以下两行：

listen_addresses = '*' include custom.conf

其中custom.conf就是承载用户自定义配置的文件。例如：

# ... postgresql: parameters: shared_buffers: "1GB" # ...

关于 PostgreSQL GUCGUC（Grand Unified Configuration）是 PostgreSQL 对运行时参数的统称，更多可用参数可参考 PostgreSQL 官方文档。需要注意的是，CloudNativePG 的parameters只接受字符串类型的值（即map[string]string，见 api/v1/cluster_types.go 中PostgresConfiguration.Parameters字段定义）。

custom.conf的内容由 operator 自动生成并维护，应用顺序如下：

1. 全局默认参数（Global default parameters）
2. 依赖 PostgreSQL 大版本号的默认参数（major-version defaults）
3. 用户提供的参数（User-provided parameters）
4. 固定参数（Fixed parameters）

全局默认参数

custom.conf中的全局默认参数如下（与 pkg/postgres/configuration.go 中CnpgConfigurationSettings.GlobalDefaultSettings的定义完全一致）：

archive_timeout = '5min' dynamic_shared_memory_type = 'posix' full_page_writes = 'on' logging_collector = 'on' log_destination = 'csvlog' log_directory = '/controller/log' log_filename = 'postgres' log_rotation_age = '0' log_rotation_size = '0' log_truncate_on_rotation = 'false' max_parallel_workers = '32' max_replication_slots = '32' max_worker_processes = '32' shared_memory_type = 'mmap' shared_preload_libraries = '' ssl_max_protocol_version = 'TLSv1.3' ssl_min_protocol_version = 'TLSv1.3' wal_keep_size = '512MB' wal_level = 'logical' wal_log_hints = 'on' wal_sender_timeout = '5s' wal_receiver_timeout = '5s'

警告：WAL 段保留策略是用户的责任你需要根据预期和实际负载，为集群规划 WAL 段的保留策略，并正确配置wal_keep_size（或旧版本上的wal_keep_segments）。

如果集群中唯一的流复制客户端只是 HA 集群内的副本实例，则可以利用复制槽特性（replicationSlots.highAvailability选项，详见 docs/src/replication.md），在集群层面管理复制槽。

在没有复制槽也没有持续备份的情况下，配置wal_keep_size或wal_keep_segments是防止 standby 掉出同步的唯一手段。standby 一旦掉出同步，会产生类似"could not receive data from WAL stream: ERROR: requested WAL segment ************************ has already been removed"的错误，此时需要从PGDATA或 WAL 卷中预留一部分空间来保留旧的 WAL 段供流复制使用。

固定参数（Fixed parameters）

以下参数是固定的，完全由 operator 独占控制：

archive_command = '/controller/manager wal-archive %p' hot_standby = 'true' listen_addresses = '*' port = '5432' restart_after_crash = 'false' ssl = 'on' ssl_ca_file = '/controller/certificates/client-ca.crt' ssl_cert_file = '/controller/certificates/server.crt' ssl_key_file = '/controller/certificates/server.key' unix_socket_directories = '/controller/run'

由于固定参数被追加在最后，用户无法通过 YAML 配置覆盖它们。这些参数是 WAL 归档和复制正确运行的必要条件。值得注意的是，operator 还维护了一个更长的"禁止用户设置"参数清单（见下文「固定参数与禁止覆盖清单」），并通过webhook 拦截用户对这些参数的设置。

从实现上看，配置文件的生成与写入集中在 pkg/management/postgres/configuration.go：createPostgresqlConfiguration函数组装ConfigurationInfo（包含全局默认、用户参数、额外共享库、同步备用名、临时表空间、扩展等），最终由postgres.CreatePostgresqlConfFile生成配置文本与其 SHA-256 校验和，再由InstallPgDataFileContent写入PGDATA下的custom.conf（文件名常量定义于 pkg/management/postgres/constants/constants.go）。该函数只有在内容真正变化时才返回变更标志，供实例管理器决定是否需要 reload 或滚动重启。

Write-Ahead Log Level（WAL 级别）

PostgreSQL 的wal_level决定写入 WAL 的信息量，可选值如下：

• minimal：仅写入崩溃恢复所需的信息
• replica：额外支持 WAL 归档和流复制，包括在 standby 上运行只读查询
• logical：包含replica的全部信息，并额外支持逻辑解码和逻辑复制

上游 PostgreSQL 默认wal_level为replica，而CloudNativePG 默认将其设为logical，以便开箱即用地支持逻辑复制（例如从外部 PostgreSQL 服务器迁移数据）。

• 如果集群不需要逻辑复制，建议将wal_level设为replica以减少 WAL 体积和开销；
• 只有单实例集群且禁用 WAL 归档时，才允许将wal_level设为minimal。

复制相关设置（Replication Settings）

primary_conninfo、restore_command、recovery_target_timeline由 operator 根据实例在集群中的角色自动管理，仅在实例作为副本运行时生效：

primary_conninfo = 'host=<PRIMARY> user=postgres dbname=postgres tcp_user_timeout=5000' recovery_target_timeline = 'latest'

重要：tcp_user_timeout默认情况下，每个 standby 都将tcp_user_timeout设为5 秒。该参数定义在 TCP 连接被强制关闭前，已传输数据允许保持未确认的最长时间，决定了 standby 对网络问题的反应速度。如果默认值不满足需求，可通过 operator 配置项STANDBY_TCP_USER_TIMEOUT统一覆盖所有 standby（详见 docs/src/operator_conf.md）。

从源码看，这些复制参数写入的是override.conf（另一份由 operator 维护的文件）：pkg/management/postgres/configuration.go 中的writePostgresOverrideConfFile函数会写入restore_command、recovery_target_timeline = 'latest'、primary_conninfo，并在启用复制槽时追加primary_slot_name；同时createStandbySignal会创建standby.signal文件以标记实例进入 standby 模式。在导入数据库等场景中，operator 还会向override.conf写入archive_mode=off、fsync=off、wal_level=minimal等临时优化参数（见configurePostgresForImport）。

日志控制设置（Log control settings）

operator 要求 PostgreSQL 以CSV 格式输出日志，实例管理器会自动解析 CSV 并转换为 JSON 格式输出。因此，postgresql.conf中的相关日志设置（如logging_collector、log_destination、log_directory、log_filename、log_rotation_age/size、log_truncate_on_rotation等）是固定的、不可修改。更多细节见 docs/src/logging.md。

共享预加载库（Shared Preload Libraries）

shared_preload_libraries用于指定在服务器启动时预加载的一个或多个共享库（逗号分隔列表），典型用途是加载需要在整个系统中大多数数据库会话可用的扩展，例如pg_stat_statements。

在 CloudNativePG 中，shared_preload_libraries默认为空。虽然可以覆盖其内容，但官方只建议 PostgreSQL 专家用户这样做。

重要如果指定的库未找到，服务器将无法启动，从而阻断 CloudNativePG 的一切自愈尝试，需要人工干预。请务必在直接管理shared_preload_libraries内容时，先测试好扩展及其设置。

CloudNativePG 能够对若干最常用的扩展自动管理shared_preload_libraries的内容（见下节「受管扩展」）：一旦 operator 发现某个配置参数需要某个受管库，就会自动把该库加入列表；当没有任何实际参数需要它时，又会自动移除。

重要请始终牢记：从shared_preload_libraries中移除库，需要重启集群中所有实例才能生效。

此外，用户还可以通过.spec.postgresql.shared_preload_libraries以字符串列表形式提供额外的预加载库，operator 会将其与自动管理的库合并（对应 api/v1/cluster_types.go 中PostgresConfiguration.AdditionalLibraries字段，其 JSON 键为shared_preload_libraries）。

受管扩展（Managed Extensions）

CloudNativePG 会自动管理以下扩展在shared_preload_libraries中的条目：

• auto_explain
• pg_stat_statements
• pgaudit
• pg_failover_slots

其中部分库还需要在数据库内创建额外对象（通常通过CREATE EXTENSION创建视图/函数，DROP EXTENSION移除）。对于这些库，CloudNativePG 会在集群中所有允许连接的数据库（由以下查询识别）中自动处理扩展的创建与移除：

SELECT datname FROM pg_database WHERE datallowconn

注意：上述查询结果包含template1等模板数据库。

重要随着 Database CRD 声明式扩展管理 的引入，受管扩展特性可能在 CloudNativePG 未来版本中发生重大变化，部分功能可能被弃用。

启用auto_explain

auto_explain自动记录慢语句的执行计划，无需手动执行EXPLAIN（有助于排查未优化的查询）。只要配置中出现以auto_explain.开头的参数即可启用。以下示例会自动记录执行时间超过 10 秒的查询执行计划：

# ... postgresql: parameters: auto_explain.log_min_duration: "10s" # ...

注意：启用 auto_explain 可能导致性能问题，请参考 PostgreSQL 官方文档。

启用pg_stat_statements

pg_stat_statements是 PostgreSQL 实现查询实时监控最重要的能力之一。配置以pg_stat_statements.开头的参数即可启用：

# ... postgresql: parameters: pg_stat_statements.max: "10000" pg_stat_statements.track: all # ...

如前所述，operator 会自动将pg_stat_statements加入shared_preload_libraries，并在每个数据库上执行CREATE EXTENSION IF NOT EXISTS pg_stat_statements，之后即可对pg_stat_statements视图执行查询。

启用pgaudit

pgaudit通过标准 PostgreSQL 日志设施提供详细的会话级和/或对象级审计日志。CloudNativePG 对 PostgreSQL 集群上的 PGAudit 提供透明、原生支持，详见 docs/src/logging.md。配置以pgaudit.开头的参数即可启用：

postgresql: parameters: pgaudit.log: "all, -misc" pgaudit.log_catalog: "off" pgaudit.log_parameter: "on" pgaudit.log_relation: "on"

在源码层面，实例管理器的日志管道专门实现了 pgaudit 的 CSV 解析支持（见 pkg/management/postgres/logpipe/pgaudit.go），pgaudit类型的日志记录会以logger: pgaudit的 JSON 字段输出，便于日志采集与检索。

启用pg_failover_slots

EDB 的pg_failover_slots扩展确保逻辑复制槽能够在故障转移场景下存活（CloudNativePG 的故障转移正是基于物理流复制实现的）。配置以pg_failover_slots.开头的参数即可启用，operator 会透明地管理其在shared_preload_libraries中的条目。

此外，对于每个打算配合pg_failover_slots使用的数据库，你需要在pg_hba段中添加一条允许各副本连接主库的规则。例如，要在app数据库上使用pg_failover_slots：

postgresql: pg_hba: - hostssl app streaming_replica all cert

pg_hba段：主机认证规则

pg_hba是用于生成 Pod 内pg_hba.conf的 PostgreSQL Host Based Authentication 规则列表（对应PostgresConfiguration.PgHBA字段，类型为[]string）。

重要pg_hba.conf的更多信息请参考 PostgreSQL 官方文档。

由于 PostgreSQL 采用第一条匹配规则进行认证，operator 生成的pg_hba.conf可以看作由四个部分拼接而成：

1. 固定规则（Fixed rules）
2. 用户自定义规则（User-defined rules）
3. 可选的 LDAP 段（Optional LDAP section）
4. 默认规则（Default rules）

固定规则：

local all all peer hostssl postgres streaming_replica all cert map=cnpg_streaming_replica hostssl replication streaming_replica all cert map=cnpg_streaming_replica hostssl all cnpg_pooler_pgbouncer all cert map=cnpg_pooler_pgbouncer

默认规则：

host all all all <default-authentication-method>

从 PostgreSQL 14 起，password_encryption数据库参数的默认值改为scram-sha-256，因此PostgreSQL 14 及以上版本的默认认证方式为scram-sha-256；PostgreSQL 13 及更早版本默认使用md5。这一逻辑在源码中也有体现：pkg/management/postgres/configuration.go 的GeneratePostgresqlHBA函数根据majorVersion < 14决定默认认证方式为md5或scram-sha-256。

最终生成的pg_hba.conf大致如下：

local all all peer hostssl postgres streaming_replica all cert map=cnpg_streaming_replica hostssl replication streaming_replica all cert map=cnpg_streaming_replica hostssl all cnpg_pooler_pgbouncer all cert map=cnpg_pooler_pgbouncer <user defined rules> <user defined LDAP> host all all all scram-sha-256 # (or md5 for PostgreSQL version <= 13)

在集群清单中，pg_hba规则以列表项形式写在.spec.postgresql.pg_hba下，例如：

postgresql: pg_hba: - hostssl app app 10.244.0.0/16 md5

上述示例通过安全通道（hostssl）为app用户访问app数据库启用了 MD5 密码认证（也可改用scram-sha-256）。生成 HBA 文件的实际调用链为RefreshPGHBA → GeneratePostgresqlHBA → postgres.CreateHBARules，其中会注入固定规则、LDAP 配置、podSelector 展开后的 IP 以及默认认证方式。

使用podSelectorRefs动态解析地址

在 Kubernetes 中，Pod IP 是临时的。每当客户端 Pod 重启就手动更新pg_hba规则是不可持续的。.spec.podSelectorRefs选项将其自动化：允许你定义命名标签选择器，operator 将其解析为最新的 IP 地址。

工作原理

1. 定义选择器：将友好的名称映射到标准的 Kubernetes podlabelSelector
2. 引用选择器：在pg_hba规则中使用${podselector:NAME}占位符
3. 自动展开：operator 解析匹配的 Pod IP，实例管理器把每个引用展开为pg_hba.conf中的独立 CIDR 条目（IPv4 为/32，IPv6 为/128）

配置示例

以下片段定义了应用 Pod 与监控 Pod 的选择器，并将其应用到 PostgreSQL 访问规则：

podSelectorRefs: - name: app-pods selector: matchLabels: app: myapp - name: monitoring selector: matchLabels: role: monitoring postgresql: pg_hba: - "hostssl mydb myuser ${podselector:app-pods} scram-sha-256" - "hostssl postgres monitor ${podselector:monitoring} scram-sha-256"

IP 展开映射

如果 operator 检测到应用 Pod 的 IP 为10.0.0.5、10.0.0.12，监控 Pod 的 IP 为10.0.1.3，实例管理器会将模板转换为：

# Expanded from: hostssl mydb myuser ${podselector:app-pods} scram-sha-256 hostssl mydb myuser 10.0.0.5/32 scram-sha-256 hostssl mydb myuser 10.0.0.12/32 scram-sha-256 # Expanded from: hostssl postgres monitor ${podselector:monitoring} scram-sha-256 hostssl postgres monitor 10.0.1.3/32 scram-sha-256

关键约束与行为

• 作用域：出于安全考虑，选择器仅限 Cluster 所在的同一个 namespace，不支持跨 namespace 查找。
• 位置限制：${podselector:NAME}语法仅可出现在host类型条目（host、hostssl、hostnossl、hostgssenc、hostnogssenc）的地址字段中。
• 响应性：operator 监听 Pod 生命周期事件（创建、删除或 IP 更新），触发配置自动重新生成并执行 PostgreSQLreload。
• 校验：选择器名称必须匹配^[a-z](https://link.gitcode.com/i/5ae28c8836d19f07ff3acdcfabf12d9f)?$模式，且pg_hba规则中每个${podselector:NAME}引用都必须对应podSelectorRefs中已定义的条目，webhook 会校验这两项约束。对应的 Go 类型PodSelectorRef定义见 api/v1/cluster_types.go，其中Name字段带有相同的正则校验注解。

警告当某个选择器匹配到零个 Pod 时，引用它的pg_hba行会从pg_hba.conf中省略。请确保你的默认规则提供了适当的兜底访问。

完整示例见 docs/src/samples/cluster-example-pod-selector-refs.yaml。

LDAP 配置

在集群 spec 的postgres段下，还有一个可选的ldap段，用于定义将被转换为pg_hba.conf中一条规则（host all all 0.0.0.0/0 ldap ...）的 LDAP 配置，支持两种模式：

• simple bind 模式：需要在 LDAP 段中指定server、prefix和suffix
• search+bind 模式：需要指定server、baseDN、bindDN，以及包含 LDAP 密码的 SecretbindPassword；此外可选用searchFilter或searchAttribute指定搜索方式，若未指定searchAttribute，默认使用uid

两种模式都允许通过scheme指定 LDAP scheme（如ldaps，见 api/v1/cluster_types.go 中的LDAPSchemeLDAP/LDAPSchemeLDAPS常量）以及port指定端口，但两者均非必填。

search+bind 模式的完整示例：

postgresql: ldap: server: 'openldap.default.svc.cluster.local' bindSearchAuth: baseDN: 'ou=org,dc=example,dc=com' bindDN: 'cn=admin,dc=example,dc=com' bindPassword: name: 'ldapBindPassword' key: 'data' searchAttribute: 'uid'

LDAP 规则的实际构造逻辑在 pkg/management/postgres/configuration.go 的buildLDAPConfigString函数中：它会依据配置依次追加ldapserver、ldapport、ldapscheme、ldaptls=1（当TLS为 true 时）、simple bind 的ldapprefix/ldapsuffix，或 search+bind 的ldapbasedn/ldapbinddn/ldapbindpasswd（以及可选的ldapsearchfilter/ldapsearchattribute），所有值都会按照pg_hba.conf的规则进行引号转义（quoteHbaLiteral）。

pg_ident段：用户名映射

pg_ident是 PostgreSQL User Name Maps 的列表，CloudNativePG 用它生成并维护数据目录中的 ident 映射文件pg_ident.conf（对应PostgresConfiguration.PgIdent字段）。

重要pg_ident.conf的更多信息请参考 PostgreSQL 官方文档。

operator 写入的pg_ident.conf由两部分组成：

1. 固定规则（Fixed rules）
2. 用户自定义规则（User-defined rules）

目前唯一由 operator 自动生成的固定规则是：

local <postgres system user> postgres

实例管理器会检测运行 PostgreSQL 实例的系统用户，并自动添加一条规则将其映射到数据库中的postgres用户。如果容器内postgres用户未被正确配置，实例管理器将允许任何本地用户连接，并记录类似下面的警告：

Unable to identify the current user. Falling back to insecure mapping.

最终生成的pg_ident.conf类似：

local <postgres system user> postgres <user defined lines>

在集群清单中，pg_ident规则以列表项形式写在.spec.postgresql.pg_ident下，例如：

postgresql: pg_ident: - "mymap /^(.*)@mydomain\\.com$ \\1"

写入逻辑对应 pkg/management/postgres/configuration.go 的RefreshPGIdent → generatePostgresqlIdent → postgres.CreateIdentRules，其中固定映射来自getCurrentUserOrDefaultToInsecureMapping()（即检测系统用户，失败时退化为不安全映射）。

变更配置与滚动更新

应用配置变更只需编辑Cluster资源的postgresql段：

• 变更后，集群实例会立即 reload 配置以应用改动；
• 如果变更涉及需要重启的参数，operator 将执行滚动升级（rolling upgrade）来逐个替换实例。

启用ALTER SYSTEM

CloudNativePG 强烈主张以 Cluster 清单作为修改 PostgreSQL 集群配置的唯一方式，以保证整个高可用集群的配置一致，并符合 Infrastructure-as-Code 的最佳实践。

默认情况下，CloudNativePG禁用新建 PostgreSQL 集群上的ALTER SYSTEM。若需启用，显式设置.spec.postgresql.enableAlterSystem为true即可（对应 api/v1/cluster_types.go 中PostgresConfiguration.EnableAlterSystem字段，默认false，注释明确说明"仅应用于调试和故障排查"）。

警告使用ALTER SYSTEM需格外谨慎：该命令只作用于当前连接的实例，不会被复制。CloudNativePG 对部分固定参数负有责任，并完全控制其余参数，务必三思。

• PostgreSQL 17 及以后：.spec.postgresql.enableAlterSystem直接控制 PostgreSQL 的allow_alter_systemGUC（该特性正是由 CloudNativePG 社区贡献给 PostgreSQL 的）；
• PostgreSQL 17 之前：当enableAlterSystem为false时，postgresql.auto.conf文件会被设为只读，任何ALTER SYSTEM尝试都会报错，错误信息类似：

ERROR: could not open file "postgresql.auto.conf": Permission denied

动态共享内存设置

PostgreSQL 通过dynamic_shared_memory_type支持多种动态共享内存实现。在 CloudNativePG 中官方建议只使用以下两种取值：

• posix：基于shm_open分配的 POSIX 共享内存（默认设置）
• sysv：基于shmget分配的 System V 共享内存

该设置对并行查询的内存分配尤为重要。

POSIX 共享内存

默认的posix设置在大多数场景下已足够，因为 operator 会自动挂载一个名为shm的内存型EmptyDir卷到/dev/shm。可在运行中的 Postgres 容器内用以下命令验证其大小：

mount | grep shm

输出大致如下：

shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=******)

如需为shm卷设置最大大小，可通过Cluster资源中的.spec.ephemeralVolumesSizeLimit.shm字段实现：

spec: ephemeralVolumesSizeLimit: shm: 1Gi

System V 共享内存

如果 Kubernetes 节点的SHMMAX与SHMALL值足够高，也可以设置：

dynamic_shared_memory_type: "sysv"

在 PostgreSQL 容器内运行以下命令查看SHMMAX/SHMALL：

ipcs -lm

例如：

------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 18014398509465599 max total shared memory (kbytes) = 18014398509481980 min seg size (bytes) = 1

可以看到，max total shared memory数值非常高，此时建议将dynamic_shared_memory_type设为sysv。另一种查看方式：

cat /proc/sys/kernel/shmall cat /proc/sys/kernel/shmmax

固定参数与禁止覆盖清单

部分 PostgreSQL 配置参数只能由 operator 管理。operator 通过 webhook 阻止用户设置它们。以下参数不允许出现在postgresql段的parameters中：

allow_alter_system allow_system_table_mods archive_cleanup_command archive_command archive_mode bonjour bonjour_name cluster_name config_file data_directory data_sync_retry event_source external_pid_file hba_file hot_standby ident_file jit_provider listen_addresses log_destination log_directory log_file_mode log_filename log_rotation_age log_rotation_size log_truncate_on_rotation logging_collector port primary_conninfo primary_slot_name promote_trigger_file recovery_end_command recovery_min_apply_delay recovery_target recovery_target_action recovery_target_inclusive recovery_target_lsn recovery_target_name recovery_target_time recovery_target_timeline recovery_target_xid restart_after_crash restore_command shared_preload_libraries ssl ssl_ca_file ssl_cert_file ssl_crl_file ssl_dh_params_file ssl_key_file ssl_passphrase_command ssl_passphrase_command_supports_reload ssl_prefer_server_ciphers stats_temp_directory synchronous_standby_names syslog_facility syslog_ident syslog_sequence_numbers syslog_split_messages unix_socket_directories unix_socket_group unix_socket_permissions

这些参数涉及归档、复制、SSL、监听地址、恢复目标等 operator 必须完全掌控的领域。用户自定义配置只能在其之外的安全范围内进行，任何越界尝试都会被 webhook 拒绝，从而保证高可用集群不会因为错误的配置而陷入不可恢复的状态。

总结

CloudNativePG 通过Cluster资源的postgresql段，将 PostgreSQL 三大配置文件（postgresql.conf、pg_hba.conf、pg_ident.conf）全面纳入声明式管理：parameters支持用户参数但受固定参数与 webhook 双重约束，pg_hba支持固定规则、用户规则、LDAP 与podSelectorRefs动态 IP 展开，pg_ident负责系统用户到数据库用户的映射，而enableAlterSystem提供了在需要时安全启用命令式修改的开关。理解 operator 在 pkg/management/postgres/configuration.go 与 pkg/postgres/configuration.go 中的文件生成与维护机制，是安全使用这些配置能力、避免集群进入不可恢复状态的关键。

【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg