CloudNativePG 的 CNCF LFX 导师计划参与指南申请路径、技术准备与开发环境落地【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg本文以 CloudNativePG 仓库中的 contribute/lfx-mentorship-program.md 为主线系统梳理这一 CNCF 项目如何通过 Linux Foundation 的 LFX Mentorship Program 招募和培养贡献者从计划背景、项目周期、历史项目清单到申请要点、推荐的技能准备方向再到入选后搭建本地开发环境、运行 E2E 测试的完整实操路径。读完本文你既能掌握一套可复用的开源项目导师计划申请方法论也能在本地把 CloudNativePG 的 operator 跑起来为提交第一个补丁做好准备。LFX 导师计划与 CloudNativePG 的渊源CloudNativePG 是一个面向 Kubernetes 环境的开源 PostgreSQL 平台通过其核心组件 CloudNativePG operator 覆盖 PostgreSQL 从部署到日常运维的完整生命周期详见仓库根目录 README.md。作为CNCF云原生计算基金会项目CloudNativePG 官方支持由 Linux Foundation 推出的LFX Mentorship Program——一个面向开源项目的带薪导师制学习计划。按照lfx-mentorship-program.md中的说明该页面承担三项职责列出已接受的 CloudNativePG 导师项目为当前 mentee受训者提供资源为潜在申请者与有意参与进来的贡献者提供指引。值得一提的是CloudNativePG 对 LFX 计划的参与不仅停留在文档层面。在仓库的 ROADMAP.md 中项目明确将其列为社区建设与贡献者培养的重要渠道作为 CNCF LFX 导师计划的活跃参与者项目方会识别并划定特定功能或改进作为可供 mentee 认领的课题。也就是说导师项目并非泛泛的打杂而是被纳入项目路线图管理的、有明确交付物的工作包。计划周期与投入要求每个导师项目持续12 周被设计为一个全职学习机会对 mentee 的投入度和专注度有较高要求。这意味着你需要能在这 3 个月里投入大量连续时间项目通常以真实的功能开发、文档建设或测试基建收尾导师通常是 CloudNativePG 的核心维护者会全程陪伴并给出代码评审与方向指引。LFX Mentorship 标签为了把与导师计划相关的事务显式标记出来CloudNativePG 使用LFX Mentorship 标签来分类相关的 issue 和 pull request。贡献者在浏览 issue 列表、筛选可认领任务时可以直接按该标签过滤申请过程中所有需要澄清的问题也应遵循在上游 issue 中提问的透明原则详见下文申请要点。当前计划状态根据lfx-mentorship-program.md的记录CloudNativePG 正在为**下一个 LFX 导师计划周期2026 年第 3 期3–5 月**筹备提案。也就是说新一期项目的具体课题还在规划中——这对潜在的申请者而言是一个信号现在就可以开始按推荐准备一节的内容武装自己等待提案公布后第一时间准备材料。历史导师项目一览以下表格完整记录了 CloudNativePG 已经完成验收的导师项目取自lfx-mentorship-program.md年份期次项目Mentee202539–11 月Chaos Testing混沌测试Yash Agarwal202539–11 月Rebuild documentation for multi-version support with Docusaurus基于 Docusaurus 重建多版本文档支持Anushka Saxena202526–8 月Declarative Management of PostgreSQL FDWsPostgreSQL 外部数据源的声明式管理Ying Zhu从这些历史课题可以清晰地看出 CloudNativePG 导师项目的技术分布它们恰好对应仓库中几条核心工作线混沌测试Chaos Testing对应 tests/e2e 下的端到端测试体系与故障注入场景比如 failover、fencing、self-fencing 等测试文件所覆盖的破坏性场景多版本文档重建Docusaurus对应 docs/src 文档站点其结构与 release notes 的组织方式docs/src/release_notes正是多版本维护的典型阵地PostgreSQL FDW 声明式管理对应 api/v1 中自定义资源CRD的设计与 internal/controller 中的控制器实现——FDW 的声明式管理意味着把原本需要手写 SQL 的外部数据源配置抽象为 Kubernetes 资源对象。如何提交申请官方给出的六条建议lfx-mentorship-program.md为申请者提供了非常具体的准备建议下面逐条展开并补充实践层面的解读用心准备一份有思考深度的 CV 和求职信cover letter这是你第一次向导师展示你是谁、你的动机是什么、你希望在导师期间达成什么的机会。官方建议花时间把它们写得清晰、个性化且结构良好。实践提示与其罗列所有技能不如围绕目标项目写我为什么适合做这个课题并给出能证明能力的链接如个人项目、PR 历史。明智地使用 AI 工具工具可以帮助润色文笔、检查语法但申请材料必须体现你自己。导师通常能识别出完全由 AI 生成的内容。导师制的本质是三个月的个人成长让真实的自己发声远比一份完美但陌生的申请书有说服力。通过官方 LFX 门户完成申请只有通过 LFX 官方申请流程提交并上传 CV 与求职信才会被正式纳入候选池。不要绕过官方渠道私下联系。遵循上游 issue 中的流程任何关于项目的澄清问题都应直接在对应 issue 中提出。这保证了过程透明也确保导师不会错过你的问题。这正好呼应了LFX Mentorship标签的作用——用它筛出相关 issue在公开线程中提问。尊重沟通边界不要在公共聊天群询问申请状态也不要在社交媒体上单独私信某位导师。等待确实煎熬但遵守官方流程对所有人都是公平且高效的。理解选择现实候选项目多、申请者多、而评审时间窗口很短这意味着并非每位申请者都会被单独联系。如果没收到回复不要气馁——持续申请、持续积累技能本身就是最好的策略。推荐准备的技术领域与仓库学习路线虽然每个导师项目有自己的技能要求但 LFX 计划整体致力于加深 mentee 在以下五个方向的知识。这里把官方清单与仓库内的一手资源一一对应起来形成一条可执行的学习路径Go 编程聚焦 operator 开发这是 CloudNativePG 的主语言operator 的核心逻辑全部用 Go 编写。学习入口cmd/manager/main.go 是 operator 的进程入口internal/controller 是控制器实现的腹地cluster、backup、pooler、scheduledbackup 等控制器都在此pkg 下有大量可独立阅读的领域逻辑如 PostgreSQL 配置管理、证书、spec 构建等。Kubernetes 与 Custom Resource DefinitionsCRDCloudNativePG 是一个典型的声明式 operator用户在Cluster等 CRD 中声明期望状态operator 负责收敛实际状态。学习入口api/v1 下定义了全部自定义资源的 Go 类型cluster_types.go、backup_types.go、pooler_types.go等及其默认值与校验逻辑config/crd/bases 是生成的 CRD YAML 清单可对照阅读字段结构config/rbac 展示了 operator 需要的 RBAC 权限模型。Git 与 GitHub 工作流贡献流程要求熟悉 fork、分支、PR、CI 状态检查等操作。仓库内的 CONTRIBUTING.md 是贡献入口hack 目录则沉淀了大量工程脚本构建、测试、发布是观察项目工程化水平的好窗口。CloudNativePG 架构与使用建议先以用户视角完整跑一遍官方 docs/src/quickstart.md再阅读 docs/src/architecture.md 理解整体架构设计。PostgreSQL 基础CloudNativePG 只支持原生 PostgreSQL理解流复制、WAL、表空间、备份恢复等核心概念是理解 operator 行为的前提。仓库中 docs/src 下的 backup、replication、wal_archiving 等主题文档都是很好的配套阅读材料。建议资源官方文档为学习者推荐了两份经典教材仅作名称与定位说明可从各自官方渠道获取Kubebuilder BookKubernetes operator 开发的权威教程覆盖 CRD 设计、控制器、webhook 与测试与 CloudNativePG 的代码结构高度同构Programming KubernetesOReilly 出版深入讲解 Kubernetes 客户端库与控制器模式的原理级读物。入选之后Mentee 起步三部曲一旦入选lfx-mentorship-program.md建议你尽快完成三件事确保开跑即进入状态1. 加入社区沟通渠道加入CNCF Slack中 CloudNativePG 的频道社区入口见仓库根目录 README.md 的 Communications 一节。日常的异步讨论、状态同步与求助都发生在这里。2. 搭建本地开发环境要贡献 CloudNativePG 的源码需要一套可复现的开发环境。官方指引在 contribute/development_environment/README.md核心三步如下。第一步安装依赖一次性操作在项目根目录运行make help可确认 GNU/Make 已就绪并查看全部可用任务make help各平台的依赖要求源自development_environment/README.mdGNU/Linux以 Debian 系为例需要PATH中存在 Go 1.21 编译器、GNU Make、Kind v0.20.x 或更高、golangci-lint、goreleaser、Operator SDK CLI、Helm同时需要安装coreutils、diffutils、findutils、git、gpg、jq、make、sed、tar、util-linux、zlib1g等系统包其他发行版包名可能不同。Microsoft WSL2与 GNU/Linux 指令相同但需额外满足 Kind 在 WSL2 下的运行要求。Mac OS X官方推荐用 brew 安装核心组件brew install go \ kind \ golangci/tap/golangci-lint \ goreleaser \ helm并注意 bash v5.0 是必需的brew install bash随后安装其余工具包并将 Go 与 Homebrew GNU 工具链的路径写进 shell profile~/.bash_profile或~/.zprofile具体环境变量可完整参考development_environment/README.md。如果使用 Docker Desktop还需按 Kind 文档配置相关设置。第二步Fork 并克隆仓库除非你是主仓库的直接维护者否则需要先 forkcloudnative-pg/cloudnative-pg再把你的 fork clone 到本地。第三步本地构建并部署 operator在本地 clone 目录中切换到main分支并执行构建与部署cd cloudnative-pg git checkout main ./hack/setup-cluster.sh create load deploy这条命令链会基于main分支内容构建 operator 镜像 → 在本地创建一个带容器镜像仓库的kind集群 → 把刚构建的 operator 部署进去。其中 hack/setup-cluster.sh 是官方提供的本地集群管理脚本支持多命令串联执行。也可以不构建源码而是用-o参数部署已发布的版本或开发快照# 部署指定发布版本 ./hack/setup-cluster.sh -o 1.28.1 create deploy # 部署 main 分支最新快照 ./hack/setup-cluster.sh -o main create deploy # 部署某个发布分支的最新快照 ./hack/setup-cluster.sh -o release-1.28 create deploy验证部署成功kubectl get deploy -n cnpg-system cnpg-controller-manager如果构建过程报错development_environment/README.md建议先确保 Go 工具链是最新版本并偶尔执行make distclean清理缓存的工具二进制。环境验证完成后可用以下命令拆除本地集群./hack/setup-cluster.sh teardown至此你的开发环境已被完整验证可以开始为 CloudNativePG 贡献补丁了。3. 本地运行 E2E 测试CloudNativePG 将持续集成与持续测试视为项目的基础能力每一个提交都不能破坏 operator 在所有受支持的 PostgreSQL 版本与所有受支持的 Kubernetes 版本上的既有行为。这套端到端测试框架由两个组件构成详见 contribute/e2e_testing_environment/README.md一个本地、可随时销毁的 Kubernetes 集群基于kind或k3d一套可运行在任意现有集群含上述本地集群上的 E2E 测试。集群管理脚本的完整能力hack/setup-cluster.sh是本地测试集群的核心入口常用命令包括hack/setup-cluster.sh create # 创建集群 hack/setup-cluster.sh load # 构建 operator 镜像并加载进本地集群 hack/setup-cluster.sh deploy # 部署 operator hack/setup-cluster.sh teardown # 清理一切脚本支持的标志均可用同名环境变量覆盖括号内为对应环境变量标志用途-e/--engine CLUSTER_ENGINE指定 Kubernetes 引擎如-e k3d默认kind。Env:CLUSTER_ENGINE-k/--k8s-version K8S_VERSION指定完整的 Kubernetes 版本号如-k v1.30.0。Env:K8S_VERSION-n/--nodes NODES指定节点数仅 create 时生效默认 3。Env:NODES-o/--operator OPERATOR选择要部署的 operatorlocal默认从本地工作树构建、某个版本号、或分支名。Env:OPERATOR-d/--deployment-method METHOD部署方式manifest默认kustomize 生成清单或helm。Env:CNPG_DEPLOYMENT_METHOD两个补充细节值得注意helm部署方式目前仅支持-o local此时 CRD 始终从本地源码树config/helm应用以保证与本地构建的 operator 二进制完全一致在 Apple M1/M2/M3 等 ARM64 架构上kind对 AMD64 与 ARM64 使用不同节点镜像。脚本会自动检测架构并通过DOCKER_DEFAULT_PLATFORMlinux/arm64使用 ARM64 镜像如需强制 x86/amd64 模拟可显式设置DOCKER_DEFAULT_PLATFORMlinux/amd64。E2E 测试套件的运行方式测试由 hack/e2e/run-e2e.sh 驱动前提是kubectl已指向可用的集群。测试套件本身只由一个 YAML 配置文件驱动默认tests/e2e/config.yaml不读取任何环境变量——环境变量先由hack/e2e下的脚本消费再生成配置文件交给测试套件。该脚本支持的环境变量非常丰富核心的有CONTROLLER_IMG要部署到集群的控制器镜像POSTGRES_IMG集群默认使用的 PostgreSQL 镜像即真正被测对象E2E_PRE_ROLLING_UPDATE_IMG从该版本滚动升级到最新小版本的升级测试TEST_CLOUD_VENDOR集群所在云厂商kind、k3d、aks、eks、gke、ocp默认kindTEST_DEPTH本次运行包含的最大测试等级从0仅关键测试到4全部测试默认2FEATURE_TYPE按功能标签选择要运行的 E2E 用例详见下文BRANCH_NAME套件运行的 git 分支用于识别发布分支如选择 operator 升级测试中的上一发布版本CNPG_DEPLOYMENT_METHOD/CNPG_CHART_VERSION部署方式与 Helm chart 版本固定BARMAN_PLUGIN_VERSION插件备份测试要安装的plugin-barman-cloud构建版本release默认 /main/ 固定版本 /pr-number/ 分支名存储类相关E2E_DEFAULT_STORAGE_CLASS、E2E_CSI_STORAGE_CLASS、E2E_DEFAULT_VOLUMESNAPSHOT_CLASSAzure 备份测试相关AZURE_STORAGE_ACCOUNT、AZURE_STORAGE_KEY、AZURE_BLOB_CONTAINER。直接运行测试套件绕过脚本时也可以手写配置文件全部字段均可选postgres: image: ghcr.io/cloudnative-pg/postgresql:18.1-standard-trixie preRollingUpdateImage: ghcr.io/cloudnative-pg/postgresql:18 imageRepository: ghcr.io/cloudnative-pg/postgresql postgisImageRepository: ghcr.io/cloudnative-pg/postgis storage: storageClass: standard # 留空则从集群自动探测 csiStorageClass: csi-hostpath-sc volumeSnapshotClass: csi-hostpath-snapclass cloudVendor: kind # kind|k3d|aks|eks|gke|ocp depth: 2 # 0仅关键到 4全部 labelFilter: backup-restore || basic skipUpgradeSuite: true timeouts: # 按需覆盖默认超时秒 failover: 240 deployment: method: manifest barmanPluginVersion: release registryPullSecret: server: registry.example.com username: user password: secret azure: storageAccount: account storageKey: key blobContainer: container branchName: main配置文件会拒绝未知字段因此拼写错误会立即导致运行失败而不会被静默忽略。按功能特性筛选测试所有 E2E 测试用例都带有功能标签定义在 tests/labels.go 中可通过FEATURE_TYPE筛选。常用标签包括smoke、basic、backup-restore、replication、failover对应 disruptive、security、upgrade、observability、tablespaces、declarative-databases、postgres-major-upgrade等二十余个。示例export FEATURE_TYPEsmoke,basic,service-connectivity多个标签用逗号分隔无空格将只运行匹配的用例。一键运行入口与测试等级仓库 Makefile 提供了三个便捷目标make e2e-test-kind # 在 kind 集群上跑 E2E make e2e-test-k3d # 在 k3d 集群上跑 E2E make e2e-test-existing-cluster # 在现有集群默认 kube context上跑 E2E它们内部封装了hack/e2e/run-e2e-local.sh与hack/e2e/run-e2e-suite.sh。此外每个测试用例自身定义了重要度0 最高到 4 最低用TEST_DEPTH控制最大等级常用组合如FEATURE_TYPEsmoke,basic make e2e-test-kind跑冒烟与基础用例TEST_DEPTH0 make e2e-test-kind只跑最关键用例TEST_DEPTH1 make e2e-test-kind跑关键 高优先级用例。对于仓库维护者与组织成员还可以在 fork 仓库的 PR 中使用/test命令触发 GitHub Actions 上的 E2E 运行需要仓库 write 权限支持tl测试等级、d深度矩阵、type特性标签、deployment-method、barman_plugin等参数外部贡献者则聚焦本地 E2E 运行云端全矩阵测试由维护者在 PR 评审阶段完成。总结CloudNativePG 通过 CNCF LFX 导师计划为社区持续输送新的活跃贡献者每个课题为期 12 周、全职投入围绕真实的功能开发、文档建设或测试基建展开并被打上 LFX Mentorship 标签以便追踪。对申请者而言一份真诚的 CV 与求职信、规范的官方渠道申请、透明的上游沟通加上 Go/Kubernetes/CRD/Git/PostgreSQL 五大方向的扎实准备是最稳妥的入场策略。而对已经入选的 mentee仓库内沉淀的 contribute/development_environment/README.md 与 contribute/e2e_testing_environment/README.md 提供了从零到一的完整落地路径——hack/setup-cluster.sh一键建集群、make e2e-test-kind一键跑测试让你在正式开工前就能以维护者的标准验证自己的环境与每一个改动。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CloudNativePG 的 CNCF LFX 导师计划参与指南：申请路径、技术准备与开发环境落地
CloudNativePG 的 CNCF LFX 导师计划参与指南申请路径、技术准备与开发环境落地【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg本文以 CloudNativePG 仓库中的 contribute/lfx-mentorship-program.md 为主线系统梳理这一 CNCF 项目如何通过 Linux Foundation 的 LFX Mentorship Program 招募和培养贡献者从计划背景、项目周期、历史项目清单到申请要点、推荐的技能准备方向再到入选后搭建本地开发环境、运行 E2E 测试的完整实操路径。读完本文你既能掌握一套可复用的开源项目导师计划申请方法论也能在本地把 CloudNativePG 的 operator 跑起来为提交第一个补丁做好准备。LFX 导师计划与 CloudNativePG 的渊源CloudNativePG 是一个面向 Kubernetes 环境的开源 PostgreSQL 平台通过其核心组件 CloudNativePG operator 覆盖 PostgreSQL 从部署到日常运维的完整生命周期详见仓库根目录 README.md。作为CNCF云原生计算基金会项目CloudNativePG 官方支持由 Linux Foundation 推出的LFX Mentorship Program——一个面向开源项目的带薪导师制学习计划。按照lfx-mentorship-program.md中的说明该页面承担三项职责列出已接受的 CloudNativePG 导师项目为当前 mentee受训者提供资源为潜在申请者与有意参与进来的贡献者提供指引。值得一提的是CloudNativePG 对 LFX 计划的参与不仅停留在文档层面。在仓库的 ROADMAP.md 中项目明确将其列为社区建设与贡献者培养的重要渠道作为 CNCF LFX 导师计划的活跃参与者项目方会识别并划定特定功能或改进作为可供 mentee 认领的课题。也就是说导师项目并非泛泛的打杂而是被纳入项目路线图管理的、有明确交付物的工作包。计划周期与投入要求每个导师项目持续12 周被设计为一个全职学习机会对 mentee 的投入度和专注度有较高要求。这意味着你需要能在这 3 个月里投入大量连续时间项目通常以真实的功能开发、文档建设或测试基建收尾导师通常是 CloudNativePG 的核心维护者会全程陪伴并给出代码评审与方向指引。LFX Mentorship 标签为了把与导师计划相关的事务显式标记出来CloudNativePG 使用LFX Mentorship 标签来分类相关的 issue 和 pull request。贡献者在浏览 issue 列表、筛选可认领任务时可以直接按该标签过滤申请过程中所有需要澄清的问题也应遵循在上游 issue 中提问的透明原则详见下文申请要点。当前计划状态根据lfx-mentorship-program.md的记录CloudNativePG 正在为**下一个 LFX 导师计划周期2026 年第 3 期3–5 月**筹备提案。也就是说新一期项目的具体课题还在规划中——这对潜在的申请者而言是一个信号现在就可以开始按推荐准备一节的内容武装自己等待提案公布后第一时间准备材料。历史导师项目一览以下表格完整记录了 CloudNativePG 已经完成验收的导师项目取自lfx-mentorship-program.md年份期次项目Mentee202539–11 月Chaos Testing混沌测试Yash Agarwal202539–11 月Rebuild documentation for multi-version support with Docusaurus基于 Docusaurus 重建多版本文档支持Anushka Saxena202526–8 月Declarative Management of PostgreSQL FDWsPostgreSQL 外部数据源的声明式管理Ying Zhu从这些历史课题可以清晰地看出 CloudNativePG 导师项目的技术分布它们恰好对应仓库中几条核心工作线混沌测试Chaos Testing对应 tests/e2e 下的端到端测试体系与故障注入场景比如 failover、fencing、self-fencing 等测试文件所覆盖的破坏性场景多版本文档重建Docusaurus对应 docs/src 文档站点其结构与 release notes 的组织方式docs/src/release_notes正是多版本维护的典型阵地PostgreSQL FDW 声明式管理对应 api/v1 中自定义资源CRD的设计与 internal/controller 中的控制器实现——FDW 的声明式管理意味着把原本需要手写 SQL 的外部数据源配置抽象为 Kubernetes 资源对象。如何提交申请官方给出的六条建议lfx-mentorship-program.md为申请者提供了非常具体的准备建议下面逐条展开并补充实践层面的解读用心准备一份有思考深度的 CV 和求职信cover letter这是你第一次向导师展示你是谁、你的动机是什么、你希望在导师期间达成什么的机会。官方建议花时间把它们写得清晰、个性化且结构良好。实践提示与其罗列所有技能不如围绕目标项目写我为什么适合做这个课题并给出能证明能力的链接如个人项目、PR 历史。明智地使用 AI 工具工具可以帮助润色文笔、检查语法但申请材料必须体现你自己。导师通常能识别出完全由 AI 生成的内容。导师制的本质是三个月的个人成长让真实的自己发声远比一份完美但陌生的申请书有说服力。通过官方 LFX 门户完成申请只有通过 LFX 官方申请流程提交并上传 CV 与求职信才会被正式纳入候选池。不要绕过官方渠道私下联系。遵循上游 issue 中的流程任何关于项目的澄清问题都应直接在对应 issue 中提出。这保证了过程透明也确保导师不会错过你的问题。这正好呼应了LFX Mentorship标签的作用——用它筛出相关 issue在公开线程中提问。尊重沟通边界不要在公共聊天群询问申请状态也不要在社交媒体上单独私信某位导师。等待确实煎熬但遵守官方流程对所有人都是公平且高效的。理解选择现实候选项目多、申请者多、而评审时间窗口很短这意味着并非每位申请者都会被单独联系。如果没收到回复不要气馁——持续申请、持续积累技能本身就是最好的策略。推荐准备的技术领域与仓库学习路线虽然每个导师项目有自己的技能要求但 LFX 计划整体致力于加深 mentee 在以下五个方向的知识。这里把官方清单与仓库内的一手资源一一对应起来形成一条可执行的学习路径Go 编程聚焦 operator 开发这是 CloudNativePG 的主语言operator 的核心逻辑全部用 Go 编写。学习入口cmd/manager/main.go 是 operator 的进程入口internal/controller 是控制器实现的腹地cluster、backup、pooler、scheduledbackup 等控制器都在此pkg 下有大量可独立阅读的领域逻辑如 PostgreSQL 配置管理、证书、spec 构建等。Kubernetes 与 Custom Resource DefinitionsCRDCloudNativePG 是一个典型的声明式 operator用户在Cluster等 CRD 中声明期望状态operator 负责收敛实际状态。学习入口api/v1 下定义了全部自定义资源的 Go 类型cluster_types.go、backup_types.go、pooler_types.go等及其默认值与校验逻辑config/crd/bases 是生成的 CRD YAML 清单可对照阅读字段结构config/rbac 展示了 operator 需要的 RBAC 权限模型。Git 与 GitHub 工作流贡献流程要求熟悉 fork、分支、PR、CI 状态检查等操作。仓库内的 CONTRIBUTING.md 是贡献入口hack 目录则沉淀了大量工程脚本构建、测试、发布是观察项目工程化水平的好窗口。CloudNativePG 架构与使用建议先以用户视角完整跑一遍官方 docs/src/quickstart.md再阅读 docs/src/architecture.md 理解整体架构设计。PostgreSQL 基础CloudNativePG 只支持原生 PostgreSQL理解流复制、WAL、表空间、备份恢复等核心概念是理解 operator 行为的前提。仓库中 docs/src 下的 backup、replication、wal_archiving 等主题文档都是很好的配套阅读材料。建议资源官方文档为学习者推荐了两份经典教材仅作名称与定位说明可从各自官方渠道获取Kubebuilder BookKubernetes operator 开发的权威教程覆盖 CRD 设计、控制器、webhook 与测试与 CloudNativePG 的代码结构高度同构Programming KubernetesOReilly 出版深入讲解 Kubernetes 客户端库与控制器模式的原理级读物。入选之后Mentee 起步三部曲一旦入选lfx-mentorship-program.md建议你尽快完成三件事确保开跑即进入状态1. 加入社区沟通渠道加入CNCF Slack中 CloudNativePG 的频道社区入口见仓库根目录 README.md 的 Communications 一节。日常的异步讨论、状态同步与求助都发生在这里。2. 搭建本地开发环境要贡献 CloudNativePG 的源码需要一套可复现的开发环境。官方指引在 contribute/development_environment/README.md核心三步如下。第一步安装依赖一次性操作在项目根目录运行make help可确认 GNU/Make 已就绪并查看全部可用任务make help各平台的依赖要求源自development_environment/README.mdGNU/Linux以 Debian 系为例需要PATH中存在 Go 1.21 编译器、GNU Make、Kind v0.20.x 或更高、golangci-lint、goreleaser、Operator SDK CLI、Helm同时需要安装coreutils、diffutils、findutils、git、gpg、jq、make、sed、tar、util-linux、zlib1g等系统包其他发行版包名可能不同。Microsoft WSL2与 GNU/Linux 指令相同但需额外满足 Kind 在 WSL2 下的运行要求。Mac OS X官方推荐用 brew 安装核心组件brew install go \ kind \ golangci/tap/golangci-lint \ goreleaser \ helm并注意 bash v5.0 是必需的brew install bash随后安装其余工具包并将 Go 与 Homebrew GNU 工具链的路径写进 shell profile~/.bash_profile或~/.zprofile具体环境变量可完整参考development_environment/README.md。如果使用 Docker Desktop还需按 Kind 文档配置相关设置。第二步Fork 并克隆仓库除非你是主仓库的直接维护者否则需要先 forkcloudnative-pg/cloudnative-pg再把你的 fork clone 到本地。第三步本地构建并部署 operator在本地 clone 目录中切换到main分支并执行构建与部署cd cloudnative-pg git checkout main ./hack/setup-cluster.sh create load deploy这条命令链会基于main分支内容构建 operator 镜像 → 在本地创建一个带容器镜像仓库的kind集群 → 把刚构建的 operator 部署进去。其中 hack/setup-cluster.sh 是官方提供的本地集群管理脚本支持多命令串联执行。也可以不构建源码而是用-o参数部署已发布的版本或开发快照# 部署指定发布版本 ./hack/setup-cluster.sh -o 1.28.1 create deploy # 部署 main 分支最新快照 ./hack/setup-cluster.sh -o main create deploy # 部署某个发布分支的最新快照 ./hack/setup-cluster.sh -o release-1.28 create deploy验证部署成功kubectl get deploy -n cnpg-system cnpg-controller-manager如果构建过程报错development_environment/README.md建议先确保 Go 工具链是最新版本并偶尔执行make distclean清理缓存的工具二进制。环境验证完成后可用以下命令拆除本地集群./hack/setup-cluster.sh teardown至此你的开发环境已被完整验证可以开始为 CloudNativePG 贡献补丁了。3. 本地运行 E2E 测试CloudNativePG 将持续集成与持续测试视为项目的基础能力每一个提交都不能破坏 operator 在所有受支持的 PostgreSQL 版本与所有受支持的 Kubernetes 版本上的既有行为。这套端到端测试框架由两个组件构成详见 contribute/e2e_testing_environment/README.md一个本地、可随时销毁的 Kubernetes 集群基于kind或k3d一套可运行在任意现有集群含上述本地集群上的 E2E 测试。集群管理脚本的完整能力hack/setup-cluster.sh是本地测试集群的核心入口常用命令包括hack/setup-cluster.sh create # 创建集群 hack/setup-cluster.sh load # 构建 operator 镜像并加载进本地集群 hack/setup-cluster.sh deploy # 部署 operator hack/setup-cluster.sh teardown # 清理一切脚本支持的标志均可用同名环境变量覆盖括号内为对应环境变量标志用途-e/--engine CLUSTER_ENGINE指定 Kubernetes 引擎如-e k3d默认kind。Env:CLUSTER_ENGINE-k/--k8s-version K8S_VERSION指定完整的 Kubernetes 版本号如-k v1.30.0。Env:K8S_VERSION-n/--nodes NODES指定节点数仅 create 时生效默认 3。Env:NODES-o/--operator OPERATOR选择要部署的 operatorlocal默认从本地工作树构建、某个版本号、或分支名。Env:OPERATOR-d/--deployment-method METHOD部署方式manifest默认kustomize 生成清单或helm。Env:CNPG_DEPLOYMENT_METHOD两个补充细节值得注意helm部署方式目前仅支持-o local此时 CRD 始终从本地源码树config/helm应用以保证与本地构建的 operator 二进制完全一致在 Apple M1/M2/M3 等 ARM64 架构上kind对 AMD64 与 ARM64 使用不同节点镜像。脚本会自动检测架构并通过DOCKER_DEFAULT_PLATFORMlinux/arm64使用 ARM64 镜像如需强制 x86/amd64 模拟可显式设置DOCKER_DEFAULT_PLATFORMlinux/amd64。E2E 测试套件的运行方式测试由 hack/e2e/run-e2e.sh 驱动前提是kubectl已指向可用的集群。测试套件本身只由一个 YAML 配置文件驱动默认tests/e2e/config.yaml不读取任何环境变量——环境变量先由hack/e2e下的脚本消费再生成配置文件交给测试套件。该脚本支持的环境变量非常丰富核心的有CONTROLLER_IMG要部署到集群的控制器镜像POSTGRES_IMG集群默认使用的 PostgreSQL 镜像即真正被测对象E2E_PRE_ROLLING_UPDATE_IMG从该版本滚动升级到最新小版本的升级测试TEST_CLOUD_VENDOR集群所在云厂商kind、k3d、aks、eks、gke、ocp默认kindTEST_DEPTH本次运行包含的最大测试等级从0仅关键测试到4全部测试默认2FEATURE_TYPE按功能标签选择要运行的 E2E 用例详见下文BRANCH_NAME套件运行的 git 分支用于识别发布分支如选择 operator 升级测试中的上一发布版本CNPG_DEPLOYMENT_METHOD/CNPG_CHART_VERSION部署方式与 Helm chart 版本固定BARMAN_PLUGIN_VERSION插件备份测试要安装的plugin-barman-cloud构建版本release默认 /main/ 固定版本 /pr-number/ 分支名存储类相关E2E_DEFAULT_STORAGE_CLASS、E2E_CSI_STORAGE_CLASS、E2E_DEFAULT_VOLUMESNAPSHOT_CLASSAzure 备份测试相关AZURE_STORAGE_ACCOUNT、AZURE_STORAGE_KEY、AZURE_BLOB_CONTAINER。直接运行测试套件绕过脚本时也可以手写配置文件全部字段均可选postgres: image: ghcr.io/cloudnative-pg/postgresql:18.1-standard-trixie preRollingUpdateImage: ghcr.io/cloudnative-pg/postgresql:18 imageRepository: ghcr.io/cloudnative-pg/postgresql postgisImageRepository: ghcr.io/cloudnative-pg/postgis storage: storageClass: standard # 留空则从集群自动探测 csiStorageClass: csi-hostpath-sc volumeSnapshotClass: csi-hostpath-snapclass cloudVendor: kind # kind|k3d|aks|eks|gke|ocp depth: 2 # 0仅关键到 4全部 labelFilter: backup-restore || basic skipUpgradeSuite: true timeouts: # 按需覆盖默认超时秒 failover: 240 deployment: method: manifest barmanPluginVersion: release registryPullSecret: server: registry.example.com username: user password: secret azure: storageAccount: account storageKey: key blobContainer: container branchName: main配置文件会拒绝未知字段因此拼写错误会立即导致运行失败而不会被静默忽略。按功能特性筛选测试所有 E2E 测试用例都带有功能标签定义在 tests/labels.go 中可通过FEATURE_TYPE筛选。常用标签包括smoke、basic、backup-restore、replication、failover对应 disruptive、security、upgrade、observability、tablespaces、declarative-databases、postgres-major-upgrade等二十余个。示例export FEATURE_TYPEsmoke,basic,service-connectivity多个标签用逗号分隔无空格将只运行匹配的用例。一键运行入口与测试等级仓库 Makefile 提供了三个便捷目标make e2e-test-kind # 在 kind 集群上跑 E2E make e2e-test-k3d # 在 k3d 集群上跑 E2E make e2e-test-existing-cluster # 在现有集群默认 kube context上跑 E2E它们内部封装了hack/e2e/run-e2e-local.sh与hack/e2e/run-e2e-suite.sh。此外每个测试用例自身定义了重要度0 最高到 4 最低用TEST_DEPTH控制最大等级常用组合如FEATURE_TYPEsmoke,basic make e2e-test-kind跑冒烟与基础用例TEST_DEPTH0 make e2e-test-kind只跑最关键用例TEST_DEPTH1 make e2e-test-kind跑关键 高优先级用例。对于仓库维护者与组织成员还可以在 fork 仓库的 PR 中使用/test命令触发 GitHub Actions 上的 E2E 运行需要仓库 write 权限支持tl测试等级、d深度矩阵、type特性标签、deployment-method、barman_plugin等参数外部贡献者则聚焦本地 E2E 运行云端全矩阵测试由维护者在 PR 评审阶段完成。总结CloudNativePG 通过 CNCF LFX 导师计划为社区持续输送新的活跃贡献者每个课题为期 12 周、全职投入围绕真实的功能开发、文档建设或测试基建展开并被打上 LFX Mentorship 标签以便追踪。对申请者而言一份真诚的 CV 与求职信、规范的官方渠道申请、透明的上游沟通加上 Go/Kubernetes/CRD/Git/PostgreSQL 五大方向的扎实准备是最稳妥的入场策略。而对已经入选的 mentee仓库内沉淀的 contribute/development_environment/README.md 与 contribute/e2e_testing_environment/README.md 提供了从零到一的完整落地路径——hack/setup-cluster.sh一键建集群、make e2e-test-kind一键跑测试让你在正式开工前就能以维护者的标准验证自己的环境与每一个改动。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考