OpenShift 上部署 Patroni 高可用 PostgreSQL 集群：从模板安装到 Jenkins 集成压测

数据库高可用集群管理运维后端【免费下载链接】patroniA template for PostgreSQL High Availability with Etcd, Consul, ZooKeeper, or Kubernetes项目地址https://gitcode.com/gh_mirrors/pa/patroni点击查看免费下载本指南围绕 Patroni 仓库中的kubernetes/openshift-example示例完整讲解在 OpenShift含restrictedSCC环境下部署三节点 Patroni 高可用 PostgreSQL 集群的步骤以及如何借助仓库自带的 Jenkins 管道kubernetes/openshift-example/test/Jenkinsfile自动创建 pgbench 压测 Pod 对集群执行基准测试。读完本文你将掌握 OpenShift 模板化的集群交付方式、动态 UID/GID 镜像适配原理以及一套可自定义的 CI 验证方案。一、为什么 Patroni 能在 OpenShift 上运行Patroni 的 Kubernetes 发行版默认基于 kubernetes/README.md 中描述的 StatefulSet 三 Pod 部署模型。而 OpenShift 与原生 Kubernetes 的主要差异在于安全约束OpenShift 默认以随机 UID 运行容器并施加restrictedSCCSecurity Context Constraints。为此仓库在 kubernetes/entrypoint.sh 中做了针对性适配当容器内 UID ≥ 10000 时脚本会把当前运行 UID/GID 回写进/etc/passwd中的postgres用户保证 PostgreSQL 进程能以非 root 身份、动态分配的 UID 正常读写数据目录if [[ $UID -ge 10000 ]]; then GID$(id -g) sed -e s/^postgres:x:[^:]*:[^:]*:/postgres:x:$UID:$GID:/ /etc/passwd /tmp/passwd cat /tmp/passwd /etc/passwd rm /tmp/passwd fi同时kubernetes/Dockerfile 在构建阶段执行chmod 775 $PGHOME与chmod 664 /etc/passwd使目录和文件具备 group 可写权限以配合 OpenShift 的随机 UID 运行模型。这两处改动是 OpenShift 版镜像区别于普通 K8s 镜像的核心。二、整体部署流程官方示例逐步操作以下步骤全部来自 kubernetes/openshift-example/README.md是官方给出的可执行流程。1. 创建测试项目oc new-project patroni-test2. 构建镜像在 OpenShift 中镜像以 ImageStream 方式管理。先在openshift命名空间导入 PostgreSQL 基础镜像再基于 Patroni 仓库源码直接触发构建构建上下文指向kubernetes目录即该目录下的 Dockerfile 与 entrypoint.sh 会被使用oc import-image postgres:10 --confirm -n openshift oc new-build https://github.com/patroni/patroni --context-dirkubernetes -n openshift说明原示例使用的postgres:10标签可在导入时替换为你环境中实际存在的镜像标签仓库当前 Dockerfile 已基于postgres:16构建实际使用时应保持基础镜像与构建上下文一致。官方文档特别提醒两点若此构建上游已合并进 Patroni 主仓库请同步更新引用若该模板要供多用户共享上述构建命令应在共享命名空间如openshift中执行而不是各用户项目内重复构建。3. 部署镜像两种模板的选择templates 目录 下提供两个 OpenShift Template模板文件用途template_patroni_ephemeral.yml无持久化存储Pod 销毁即数据丢失仅用于测试template_patroni_persistent.yaml通过 StatefulSet 的volumeClaimTemplates申请 PVC数据持久化两者唯一的本质区别在于StatefulSet 是否请求持久化存储。Ephemeral 模板的注解中明确警告WARNING: Any data stored will be lost upon pod destruction. Only use this template for testing.4. 创建并实例化模板若模板需要跨项目共享先安装到openshift命名空间oc create -f templates/template_patroni_ephemeral.yml -n openshift随后在自有项目中实例化oc new-app会按模板参数自动生成 Service、StatefulSet、Secret、RBAC 等资源对象oc new-app patroni-pgsql-ephemeral注意oc new-app patroni-pgsql-ephemeral引用的是模板的metadata.name即patroni-pgsql-ephemeral并非文件名。Persistent 模板的对应名称为patroni-pgsql-persistent。5. 验证集群初始化Pod 运行起来后应能看到两个 Patroni 用于 DCS 协调的 ConfigMap以默认集群名patroni-persistent为例这里展示的是 README 中的示例输出$ oc get configmap NAME DATA AGE patroniocp-config 0 1m patroniocp-leader 0 1m这两个 ConfigMap 由 Patroni 的 Kubernetes DCS 实现自动创建与维护-config保存集群动态配置与历史时间线-leader记录当前 leader 租约。对应源码位于 patroni/dcs/kubernetes.py其内部通过 leader 路径leader_path与 annotations 机制实现选主与续约。三、模板资源拆解OpenShift 模板到底创建了什么以 template_patroni_persistent.yaml 为例模板的objects数组依次定义了以下资源1. 三类 Service 与角色标签模板创建三个ClusterIP类型 Service全部监听/转发 5432 端口集群名 Service如patroni-persistent不设 selector配合同名 Endpoints 使用由 Patroni 动态维护成员地址Primary Service如patroni-persistent-primaryselector 为role: primaryReplica Service如patroni-persistent-replicaselector 为role: replica。role: primary/role: replica标签正是 Patroni 写入 Pod 的。在 patroni/dcs/kubernetes.py 中可看到默认配置self._leader_label_value config.get(leader_label_value, primary) self._follower_label_value config.get(follower_label_value, replica)而update_pods相关的标签同步逻辑会把当前角色写入role标签patroni/dcs/kubernetes.py中tmp_role primary以及{replica: self._follower_label_value}.get(data[role], data[role])的映射从而保证 Service selector 总能指向正确的 Pod 集合——这也是客户端读写分离能直接依赖*-primary/*-replica服务名的原因。2. Secret 保存数据库凭据kind: Secret stringData: superuser-password: ${PATRONI_SUPERUSER_PASSWORD} replication-password: ${PATRONI_REPLICATION_PASSWORD}后续容器环境变量通过secretKeyRef引用这两个键避免密码明文进入模板实例。3. StatefulSet核心 Pod 规格模板参数replicas: 3、podManagementPolicy: OrderedReady、updateStrategy: OnDeletePod 模板包含initContainerfix-perms在数据卷挂载点预创建数据目录并收紧权限command: [sh, -c, mkdir -p /home/postgres/pgdata/pgroot/data chmod 0700 /home/postgres/pgdata/pgroot/data]这与 kubernetes/entrypoint.sh 中动态 UID 适配配合解决 OpenShift 随机 UID 下 PVC 属主问题。关键环境变量全部通过PATRONI_*前缀自动映射进 Patroni 配置环境变量来源/值作用PATRONI_KUBERNETES_POD_IPfieldRef: status.podIPPatroni REST API 与 PostgreSQL 的 connect_addressPATRONI_KUBERNETES_NAMESPACEfieldRef: metadata.namespace定位 ConfigMap/EndpointsPATRONI_KUBERNETES_BYPASS_API_SERVICEtrue绕过 kubernetes Service直连 API需要 ClusterRole 权限见下文PATRONI_KUBERNETES_LABELS{application: ..., cluster-name: ...}集群成员发现标签PATRONI_SUPERUSER_USERNAME/PASSWORD模板参数 Secret超级用户凭据PATRONI_REPLICATION_USERNAME/PASSWORD模板参数 Secret流复制凭据PATRONI_SCOPE模板参数PATRONI_CLUSTER_NAME集群作用域名PATRONI_NAMEfieldRef: metadata.name成员名即 Pod 名PATRONI_POSTGRESQL_DATA_DIR/home/postgres/pgdata/pgroot/data数据目录PATRONI_POSTGRESQL_LISTEN0.0.0.0:5432PostgreSQL 监听地址PATRONI_RESTAPI_LISTEN0.0.0.0:8008Patroni REST API 监听地址就绪探针对 REST API/readiness端点做 HTTP GET端口 8008initialDelaySeconds: 3、periodSeconds: 10、failureThreshold: 3确保只有健康的 Patroni 成员才对外服务。持久化通过volumeClaimTemplates为每个副本申请 PVC默认5GiReadWriteOnce。4. RBAC最小权限模型模板为 ServiceAccount 创建Role/RoleBinding授权范围严格限定在 ConfigMap、Endpoints、Pods 三类资源上get/list/watch/patch/update/create/delete其中delete仅用于patronictl remove。此外由于设置了PATRONI_KUBERNETES_BYPASS_API_SERVICEtrue还需 ClusterRolepatroni-k8s-ep-access仅允许get名为kubernetes的 Endpoints及其 ClusterRoleBinding——模板注释明确说明该特权仅当部署在非 default 命名空间且启用 bypass 时必需。5. 模板参数一览模板末尾的parameters段定义了全部可定制项默认值如下参数默认值说明APPLICATION_NAMEpatroni-persistent所有资源的应用标签PATRONI_CLUSTER_NAMEpatroni-persistent集群名ScopePATRONI_PRIMARY_SERVICE_NAMEpatroni-persistent-primary主库 Service 名PATRONI_REPLICA_SERVICE_NAMEpatroni-persistent-replica备库 Service 名MEMORY_LIMIT512Mi容器内存上限NAMESPACEopenshiftImageStream 所在命名空间PATRONI_SUPERUSER_USERNAMEpostgres超级用户PATRONI_SUPERUSER_PASSWORDpostgres超级用户密码生产环境务必修改PATRONI_REPLICATION_USERNAMEpostgres复制用户PATRONI_REPLICATION_PASSWORDpostgres复制密码生产环境务必修改SERVICE_ACCOUNTpatroni-persistentPod 与 RoleBinding 使用的 SAPVC_SIZE5Gi持久卷大小Persistent 模板四、Jenkins 管道自动对集群执行 pgbench 压测test/README.md 的核心内容是一句话但配套的 test/Jenkinsfile 提供了完整的声明式管道实现原文明确说明该管道会为 pgbench Pod 创建一个独立的 DeploymentConfig并对 Patroni 集群执行测试这是一个示例应根据自身环境定制。1. 管道全貌Jenkinsfile 定义了三个阶段pipeline { agent any stages { stage (Deploy test pod) { ... } // 部署 pgbench 压测 Pod stage (Run benchmark Test) { ... } // 在 Pod 内执行 test.sh stage (Clean up pgtest pod) { ... } // 清理压测资源 } }2. 阶段一Deploy test pod条件化部署先检查当前项目中是否已存在名为pgbench的 DeploymentConfig只有不存在时才执行部署避免重复创建openshift.withCluster() { openshift.withProject() { return !openshift.selector( dc, pgbench ).exists() } }随后通过openshift.newApp从外部镜像创建应用关键参数如下def pgbench openshift.newApp( https://github.com/stewartshea/docker-pgbench/, --namepgbench, -e PGPASSWORDpostgres, -e PGUSERpostgres, -e PGHOSTpatroni-persistent-primary, -e PGDATABASEpostgres, -e TEST_CLIENT_COUNT20, -e TEST_DURATION120 )参数含义参数值说明PGHOSTpatroni-persistent-primary指向模板创建的Primary Service 名压测流量永远打到当前主库PGUSER/PGPASSWORDpostgres/postgres与模板默认超级用户凭据一致改动模板密码时需同步修改TEST_CLIENT_COUNT20并发客户端数TEST_DURATION120压测时长秒创建后使用timeout(5)包裹pgbenchdc.rollout().status()等待 DeploymentConfig 滚动完成最多等待 5 分钟。定制提示PGHOST必须与你在 template_patroni_persistent.yaml 中设置的PATRONI_PRIMARY_SERVICE_NAME保持一致TEST_CLIENT_COUNT、TEST_DURATION应依据集群规格调整。3. 阶段二Run benchmark Test通过oc exec进入运行中的 pgbench Pod 并执行其内置测试脚本oc exec $(oc get pods -l apppgbench | grep Running | awk {print $1}) ./test.sh先按apppgbench标签筛选 Pod再用grep Runningawk提取处于 Running 状态的 Pod 名最后在容器内执行./test.sh发起压测。该 Pod 正是阶段一部署的 docker-pgbench 镜像中自带的测试入口。4. 阶段三Clean up pgtest pod压测结束后按标签清理全部相关资源oc delete all -l apppgbenchoc delete all会同时删除该标签下的 DeploymentConfig、Pod、Service 等 OpenShift 资源保证测试环境不残留资源占用。五、底层原理Kubernetes DCS 如何支撑这套部署理解 OpenShift 模板背后的协调逻辑可以更自信地定制参数。Patroni 的 Kubernetes 实现位于 patroni/dcs/kubernetes.py核心机制包括ConfigMap 即 DCS 存储集群配置、leader 租约均以 ConfigMap annotations 形式存储通过_patch_or_create、_update_leader等方法写入并由watch方法leader_version、timeout 机制监听变更实现故障快速感知角色标签驱动 Service正如前文所述leader_label_value/follower_label_value默认分别为primary/replicaPatroni 持续将当前角色写入 Pod 标签使*-primary、*-replicaService 的 selector 始终精确命中对应成员——这也是 Jenkins 压测直接连patroni-persistent-primary即可稳定打到主库的原理in-cluster 认证K8sConfig从/var/run/secrets/kubernetes.io/serviceaccount/token与ca.crt读取 ServiceAccount 凭据见load_incluster_config因此模板中为 ServiceAccount 授予的最小 RBAC 权限就是 Patroni 全部所需。六、部署与定制的关键注意事项镜像构建上下文oc new-build ... --context-dirkubernetes必须指向kubernetes目录因为 OpenShift 版 Dockerfile 与 entrypoint 都位于该目录Ephemeral 仅限测试无 PVC 的模板在 Pod 重建后数据全部丢失切勿用于生产凭据必须修改模板默认超级用户与复制用户密码均为postgres实例化时应通过参数覆盖并依赖 Secret 机制传递避免明文暴露服务名耦合Jenkins 管道中的PGHOST、客户端使用的*-primary/*-replica服务名都直接绑定模板参数PATRONI_PRIMARY_SERVICE_NAME等改名时需同步更新消费方RBAC 按需裁剪patroni-k8s-ep-accessClusterRole 仅在使用PATRONI_KUBERNETES_BYPASS_API_SERVICEtrue且非 default 命名空间时需要可按注释说明评估是否保留Jenkins 管道是示例test/Jenkinsfile中 pgbench 镜像、测试时长、并发数、凭据均为示例值原文明确要求按自身环境定制后再接入 CI。通过上述模板化部署与 Jenkins 压测管道你可以在 OpenShift 上快速获得一套可验证、可伸缩的 Patroni 高可用 PostgreSQL 集群交付方案并把基准测试固化为持续集成的一部分。赞分享数据库高可用集群管理运维后端【免费下载链接】patroniA template for PostgreSQL High Availability with Etcd, Consul, ZooKeeper, or Kubernetes项目地址https://gitcode.com/gh_mirrors/pa/patroni点击查看免费下载相关推荐在 OpenShift 上部署 Patroni PostgreSQL 高可用集群基于模板的动态 UID/GID 适配实战在 OpenShift 上部署 Patroni PostgreSQL 高可用集群基于模板的动态 UID/GID 适配实战 本篇技术指南围绕 Patroni 项数据库高可用集群管理运维后端Patroni高可用性部署完整指南从零构建PostgreSQL集群Patroni高可用性部署完整指南从零构建PostgreSQL集群 Patroni作为PostgreSQL高可用性解决方案的领导者能够帮助您快速构建稳定可靠数据库高可用集群管理运维后端免费 API 认证实战无需认证、apiKey 与 OAuth 的选型与落地免费 API 认证实战无需认证、apiKey 与 OAuth 的选型与落地 第一次给项目接免费 API多半会被认证这一关卡住有的接口拿来就能调有的要先申文档上一篇riscv-gnu-toolchain核心组件解析GCC、Binutils与Newlib深度剖析下一篇Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF多语言能力测试201种语言表现深度测评创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考