Kubernetes 贡献者入门指南：从零开始参与社区开发的完整路线图

Kubernetes 贡献者入门指南：从零开始参与社区开发的完整路线图

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

本文是 Kubernetes 社区仓库（community）中 contributors/guide/README.md 的深度解读。它面向所有想要参与 Kubernetes 开发的开发者，系统梳理了从注册 GitHub 账号、签署 CLA，到理解社区角色、加入 SIG、提交第一个 PR 的完整路径。读完本文，你将掌握参与 Kubernetes 开发所需的全部前置步骤、社区沟通渠道与协作规范，并能基于仓库内的实际文件（如 OWNERS、OWNERS_ALIASES、community-membership.md）理解背后的自动化机制。

Welcome：这份指南是什么

你是否想过为云原生领域最核心的开源项目贡献代码？Kubernetes 社区仓库 中的这份贡献者指南（Contributor Guide）正是为此而生。它帮助新贡献者理解 Kubernetes 项目的整体组织方式，并指引你找到最佳的上手路径：认领 issue、编写代码修复问题、提交 PR 并通过评审被合入主线。

官方明确表示，这份文档是如何向 Kubernetes 代码库贡献的唯一权威来源（single source of truth）。社区欢迎任何人浏览 [open issues] 并提出新问题，所有反馈都会被认真对待。当前仓库正是这一指南的实际载体，你可以直接在本仓库中浏览对应文档：contributors/guide/README.md。

Contributor Guide：建议按顺序阅读的章节

Kubernetes 官方建议新贡献者按以下顺序走完整个指南，每一步都建立在前一步的基础上：

1. Welcome（本文所在页面）—— 了解项目整体与入门路径；
2. Prerequisites（前置条件）—— 在开始贡献前必须完成的准备工作；
3. Your First Contribution —— 第一次贡献前需要知道的事；
4. Contributing —— 贡献 Kubernetes 的主要参考指南。

此外，contributor cheatsheet（若有，位于contributors/guide/contributor-cheatsheet/）提供了一页速查的贡献者资源索引，适合作为日常查阅的手册。

Prerequisites：提交代码前的四项准备

在向 Kubernetes 提交代码之前，必须先完成以下前置条件。这些步骤会在你第一次提交时由机器人自动检查，提前完成会让首次贡献顺利得多。对应仓库根目录的 CLA.md、code-of-conduct.md、values.md 等文件给出了完整细节。

创建 GitHub 账号

一切开始之前，你需要先注册一个 GitHub 用户账号。这是后续提交 PR、被机器人自动检查身份的账户基础。

签署 CLA（贡献者许可协议）

Kubernetes只接受已签署 CLA 的原创源代码。根据仓库根目录的 CLA.md，Cloud Native Computing Foundation（CNCF）定义了两种类型的贡献者许可协议：

• Individual Contributor（个人贡献者）：以个人身份贡献；
• Corporate Contributor（企业贡献者）：代表雇主或其他组织贡献。

需要注意的是，该政策不适用于third_party和vendor目录下的第三方依赖代码。签署 CLA 的最简单方式，是向kubernetes-sigs/contributor-playground仓库提交一个练习性质的 PR。提交 PR 时请按照提供的模板填写描述。

EasyCLA 签署流程（共六步，来自 CLA.md）：

1. 创建你的第一个 PR 后，linux-foundation-easycla机器人会在 PR 中回复你的 CLA 状态与签署链接。若以企业贡献者身份签署，请确保已将企业邮箱关联到 GitHub 账号（不要求是主邮箱），否则可能导致 CLA 系统校验失败；
2. 点击 "Please click here to be authorized" 链接，跳转到 GitHub 授权页并点击 "Authorize LF-Engineering"，授权 Linux Foundation 只读读取你 GitHub 账号关联的邮箱列表；
3. 授权完成后，页面会要求你选择贡献者类型：Individual Contributor（以个人身份）或 Corporate Contributor（代表组织）；
4. 选择类型后，通过 DocuSign 完成签署流程，点击 "Finish" 后会自动跳转回你的 PR；
5. 留意邮箱中来自 EasyCLA 的成功通知邮件，可下载已签署的 CLA 的 PDF；
6. 回到 PR，在评论区回复/easycla以更新该 PR 的 CLA 状态。

如果更换雇主，还需要在cncf/gitdm仓库中更新你的开发者归属信息（affiliation），格式如下：

Jorge O. Castro*: jorge!heptio.com, jorge!ubuntu.com, jorge.castro!gmail.com Heptio Canonical until 2017-03-31

若签署过程中遇到问题，可通过 EasyCLA 机器人响应中的支持链接提交工单，或使用备用邮箱联系 CNCF。仓库管理员如需为自己的仓库配置 CNCF CLA 检查，可参考 github-management/setting-up-cla-check.md。

遵守行为准则与社区价值观

请务必阅读并遵守 Code of Conduct 与 Community Values。Kubernetes 是一个社区项目，其健康发展完全依赖社区成员共同营造高效、友好、协作的环境。行为准则适用于社区所有的沟通平台（见 communication/README.md）。

搭建开发环境

官方明确说明：仅参与社区贡献（如文档、issue 等）并不强制要求搭建开发环境。但如果你计划提交代码修改，请查阅 developer resources 页面了解如何配置环境。其中包含本地开发、编码与调试的完整指引（contributors/devel/目录下还按 SIG 细分了开发文档，如 development.md、running-locally.md）。

理解社区期望与角色

Kubernetes 高度依赖社区，请提前了解协作中的代码与评审期望，以及各类贡献者角色的职责：

• 阅读 Community Expectations，理解代码与评审期望，例如：所有活跃参与者都被期望同时成为活跃的评审者；评审者（reviewer）应对活跃 PR 及时响应，若长时间不可用，应设置 GitHub 状态为 "busy" 以阻止机器人自动指派，长期不可用则应将自己从 OWNERS 文件中移除并提名继任者；"活跃 PR" 指带有cla:yes标签且无需 rebase 即可合并的 PR；
• 查看 Community Membership 了解各角色的职责清单，并鼓励随着经验积累逐步向上攀登贡献者阶梯。

community-membership.md 中定义了四个核心角色及其定义方式：

例如，成为Member的基本要求包括：开启 GitHub 双重认证、在 CNCF gitdm 中保持账号归属信息最新、做出多次能体现持续长期承诺的贡献（至少有一个已合入的 PR）、订阅dev@kubernetes.io邮件列表、阅读本贡献者指南、由 2 位 reviewer 推荐（且两位 sponsor 必须来自不同公司以体现跨社区整合），最终在kubernetes/org仓库提交 membership 申请 issue 并让 sponsor 回复+1。

Kubernetes Contributor Playground：安全的练习场

如果你希望在一个安全的环境中熟悉 Kubernetes 的 PR 与 issue 评审流程，Kubernetes Contributor Playground 是最合适的去处。它不仅是 CLA 注册的渠道，更是一个练习提交第一个 PR 的仓库——正如 contributors/guide/README.md 所强调的，提交新 PR 时请按照模板撰写描述。

此外，New Contributor Workshop 的视频大纲可以在本仓库的 events/2019/11-contributor-summit 目录中找到，配套的 YouTube 视频合辑对新手极具参考价值。

Community：加入 Kubernetes 社区

Kubernetes 是一个庞大、活跃、友好的开源社区。如同许多开源项目一样，它的持续发展依赖源源不断的新成员加入并成为常规代码贡献者。请考虑加入 Kubernetes，并沿着贡献者阶梯稳步向上。

沟通渠道

社区遵循统一的沟通政策，详见 communication/README.md。该文档列出了上游贡献者的沟通平台与资源：包括按社区组（尤其是各 SIG）组织的邮件列表、Slack 频道、Zoom 会议、会议议程/纪要等。所有平台都受 code-of-conduct.md 约束，并明确禁止未经请求的商业内容（如 Slack 上的广告式私信、会议中的产品推销），但允许在合适频道提问商业产品使用问题。官方决策信息主要沉淀在kubernetes-dev邮件列表、各关联仓库的 GitHub Issues/PRs 以及 KEP（Kubernetes Enhancement Proposals）中。

事件与峰会

Kubernetes 每年在中国、欧洲、北美举办三次 KubeCon + CloudNativeCon 峰会，CNCF 官网提供了这些社区事件的详细信息。仓库中 events/ 目录记录了历年 Contributor Summit 的历史资料，可供回顾。

Meetups

所有 Kubernetes Meetup 均遵循 Cloud Native Computing Foundation 的社区组（Community Groups）指南；你也可以通过邮箱联系 CNCF 负责社区组项目的员工咨询相关问题。

导师计划（Mentorship）

想获得更有经验的社区成员一对一指导？请阅读 mentoring/README.md 了解 Kubernetes 的导师计划。仓库 mentoring/ 目录下还包含新贡献者导向（new-contributor-orientation）、流程（processes）与各类项目（programs）的详细材料。

进阶主题：OWNERS 文件与自动化

进阶主题面向需要深入理解仓库治理机制的贡献者。Kubernetes 组织通过OWNERS 文件管理代码归属：每个包含独立代码或内容单元（unit of independent code）的目录都可以包含一个OWNERS文件，它作用于该目录下的所有内容（包括自身、同级文件与子目录）。OWNERS 文件是项目两阶段代码评审流程的实现机制，受 Chromium OWNERS 启发，也启发了 GitHub 的 CODEOWNERS。

详细规范见 contributors/guide/owners.md，其核心语法如下：

approvers: - alice - bob # this is a comment reviewers: - carol - david # this is another comment - sig-foo # this is an alias

关键字段：

• approvers：可以使用/approve命令的 GitHub 用户名或别名列表；
• reviewers：适合/lgtm一个 PR 的候选人列表；
• labels：自动应用到 PR 的 GitHub 标签列表；
• emeritus_approvers：曾经是 approvers、但不再活跃审批的成员（被 Prow 忽略分配，但可被查阅咨询）；
• options.no_parent_owners：默认为false；为true时排除父目录 OWNERS 文件的影响；
• filters：键为 Go 正则表达式、值为简单 OWNERS 配置的映射，正则匹配相对于该 OWNERS 文件的路径。一旦使用filters，approvers/reviewers/labels等必须定义在filters内，只有options例外，例如：

filters: ".*": labels: - re/all "\\.go$": labels: - re/go

本仓库根目录的 OWNERS 就是一个真实示例——它通过filters对annual-report-.*\.md$文件自动打上area/annual-reports标签，对charter.md指定了required_reviewers（steering-committee）与committee/steering标签。而 OWNERS_ALIASES 定义了sig-*-leads等别名组（alias），用别名替代 GitHub Teams，是因为 Teams 的变更无法公开审计。

两阶段评审流程（owners.md 中的简化描述）：

• Phase 0 自动化：作者提交 PR 后，自动化（Blunderbuss 插件）根据变更代码最近的 OWNERS 文件推荐至少 2 位 reviewer，并为每个 OWNERS 文件推荐一位 approver 写入评论；
• Phase 1 人工评审：reviewer 关注代码质量、正确性、工程风格；满意则评论/lgtm，改主意则/lgtm cancel。Prow 机器人据此打上lgtm标签；
• Phase 2 人工审批：作者/assign所有建议的 approver；只有相关 OWNERS 文件中列出（直接或通过别名）的人才能/approve；全部 approver 批准后 Prow 打上approved标签；
• Phase 3 自动化合并：当所需标签齐全（如lgtm、approved）、无阻塞标签（如do-not-merge/hold、needs-rebase）且预提交 Prow 任务通过后，PR 被自动合并。

该流程由 Prow 生态实现：Tide 负责批量测试与合并、Blunderbuss 插件负责推荐 reviewer、assign/approve/lgtm 插件负责响应/assign、/approve、/lgtm命令，repoowners包负责解析 OWNERS 与 OWNERS_ALIAS 文件。

迈出第一步：你的首次贡献

完成前置条件后，first-contribution.md 会带你找到第一个可贡献的方向：

• 找到要做的事：改进文档、澄清可重命名的代码/变量/函数、编写测试、帮助 issue 分类（triage）都是很好的起点；也可以在带good first issue标签的 issue 中寻找任务，该标签意味着 Kubernetes 成员承诺为新贡献者提供额外协助；
• 认领 issue：在 issue 下回复/assign或/assign @yourself，k8s-ci-robot 会自动把 issue 分配给你，你的名字会出现在 Assignees 列表；
• 了解 SIG：Kubernetes 社区按 Special Interest Groups（SIGs）组织以改进工作流。SIG 是开放社区，任何人都可以加入修复 issue、评论设计提案、评审代码，且 SIG 有对所有人开放的定期视频会议、Slack 频道与会议纪要。可通过 sig-list.md 查阅全部 SIG 的联系信息；例如提交 CNI（Container Networking Interface）相关 issue 时，在评论中回复/sig network即可打上 Network SIG 标签；
• SIG 专属贡献指南：部分 SIG 在社区目录下有专属的CONTRIBUTING.md，如 sig-apps/CONTRIBUTING.md、sig-cli/CONTRIBUTING.md、sig-multicluster/CONTRIBUTING.md、sig-node/CONTRIBUTING.md、sig-storage/CONTRIBUTING.md、sig-windows/CONTRIBUTING.md；
• 提交 issue：尚未准备好写代码但发现了问题？请在合适的子仓库提交 issue（如文档问题提交到 kubernetes/website），并遵循提示的提交规范，详见 issue-triage.md。

深入贡献主指南与 GitHub 工作流

当你要正式提交代码时，contributing.md 是主参考文档。其要点包括：

• PR 的 Kubernetes 特色：Kubernetes 遵循标准的 GitHub PR 流程，但增加了一层 Kubernetes 特有（甚至 SIG 特有）的差异——机器人会自动给 PR 打结构化标签，并在评论中提示可用的/command命令（用于自动打标签与通知）；
• 新贡献者常见问题：首个 PR 前未正确签署 CLA；找不到正确的 SIG/reviewer；PR 上出现与改动无关的测试失败（flaky tests）；未遵循 scalability-good-practices.md；在 commit message 中写了@mentions或fixes #xxxx等关键字（这些应放在 PR 描述而非提交信息中）；
• 评审建议：遵循 coding-conventions.md，写出清晰有意义的提交信息，把大的改动拆分成逻辑上独立、易于理解的小补丁；PR 关注度不够时可在 Slack 的#pr-reviews频道求助；
• 测试类型：单元测试（Unit，Go 原生 testing 包，与被测代码同目录）、集成测试（Integration，覆盖组件间或与 etcd 等外部资源的交互）、端到端测试（e2e，需要完整集群，见 e2e-tests.md）、一致性测试（Conformance，由 SIG Architecture 批准定义所有发行版必须支持的核心特性集）。CI 会以预提交/后提交方式运行这些测试，结果展示在 testgrid 上，相关自动化由 sig-testing 与 test-infra 仓库维护；
• Issue 管理与分类（Triage）：通过为 GitHub issue 添加多种描述性标签加速问题路由，详见 issue-triage.md。

动手前请参考 github-workflow.md 的完整流程：在云端 forkkubernetes/kubernetes→ clone 到本地并添加upstreamremote（并设置git remote set-url --push upstream no_push防止误推上游）→ 基于upstream/master创建工作分支myfeature→ 用git fetch upstream && git rebase upstream/master保持分支同步（避免使用git pull产生多余的 merge commit）→ 提交时保持 commit 清晰易懂。下图直观展示了这一流程：

结语

从注册账号、签署 CLA，到加入 SIG、完成第一个 PR，Kubernetes 的贡献体系环环相扣。这份入门指南（contributors/guide/README.md）是整个流程的起点，配合 first-contribution.md、contributing.md、community-membership.md 与 OWNERS 治理机制，你已经拥有了一条完整的、可执行的上手路径。社区的强大来自每一位成员——欢迎加入 Kubernetes！

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community