一 、 Kubernetes 是啥？

Kubernetes（简称为K8S）是用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。该系统由 谷歌 设计并捐赠给Cloud Native Computing Foundation（属Linux基金会）。K8S于2014年首次对外开源，已成为云侧开源分布式容器管理标准平台。

K8S项目目前有80.2K Star，29.1K Fork，10000+代码提交者，58000+贡献者（包含提Issue），1000+家厂商参与共建，是开源共建的 开源社区 典范。

数据来源：

二、K8S社区是怎么运作的？

K8S社区的治理运作机制，全部归档在其 GitHub 官方账号community仓（）。

首先，下载统计一下K8S community仓下所有文件，总共1430个，包括各种流程、模板、配置文件等。

总的来说，K8S社区运作机制主要分为社区治理、沟通渠道、学习上手、如何贡献、成员规则五大块，接下来分别打开看看！

2.1 社区治理

包括社区原则、行为准则、价值观、社区组织、社区年度报告、代码管理指南以及CLA说明。社区原则中，除了说明开放、公开透明外，对项目的目标、范围及设计原则有说明。范围说明啥是K8S，能做啥，不能做啥（不能做啥其实很重要，因为要说明项目的边界）。

设计原则包括API conventions、Control logic、Architecture、Extensibility、Bootstrapping Availability，源头参考自 Eric Raymond 的 17 条 UNIX 规则。

其社区行为准则是继承自CNCF的行为准则，17国语言支持，非常全球化。

社区有行为准则委员会负责执行和维护 Kubernetes 行为准则，5名成员，有独立的章程及选举规则。假设有人在社区捣乱，不良行为由行为准则委员会处理。

问题相应流程包括：

1.负向事件驱动，召集委员会会议；

2.讨论，委员会达成一致共识；

3.采取行动，措施包括私人警告、禁止进入社区等。

此外，有社区标杆人物展示，拿奖学金那种。仔细看一下，非常political correctness。

K8S的社区价值观，和 Apache Way有点类似，其中“Automation over process”这点非常赞同，Kubernetes 社区的流程自动化做的非常好。

K8S的社区组织，总共分为下面几大类：

A.委员会 – Kubernetes 项目的管理机构，有3个委员会，分别是指导委员会，行为准则委员会（上述已有概述）、以及产品安全委员会。

• Steering Committee（指导委员会）- 提供与 Kubernetes 项目章程、子组织和财务规划有关的决策和监督。总共7名成员；有独立的指导委员会管理章程，技术的相关责任其实是委托SIG；主要管两个项目，Funding和Steering。
• Code of conduct committee(行为准则委员会)-负责执行和维护 Kubernetes 行为准则，上面说过了。
• Product Security Committee （产品安全委员会）-负责接收和响应 Kubernetes 产品安全问题报告的机构。包含7名成员。主要负责 security代码仓， CVE 安全问题有独立邮箱接受及处理流程。

B.特殊兴趣小组 (SIG) – 不同技术领域的SIG，其中最核心Architect-SIG（看护Kubernetes 核心架构）。SIG和子项目（一对多关系）。SIG 所涵盖的领域包括特定组件或功能、横切/横向、跨越项目的许多/所有功能领域，目前总共有20多个SIG。典型SIG包括：

• 垂直领域：网络、存储、节点、调度。
• 横向领域：可扩展性、架构
• 特定项目：测试、发布、文档、贡献者体验。

SIG涉及流程及文档：

• 1.SIG管理流程
• 2.SIG治理制度
• 3.SIG相关规范
• 4.SIG生命周期管理- （重点：如何清退不活跃SIG）

C.工作组（WG） – 为解决跨越 SIG 边界的问题而成立的临时工作组，工作组不管代码。工作组主要用于促进 K8S范围内但跨越 SIG 界线的讨论主题。如果社区中的一群人想要聚在一起讨论一个主题，可以在不组建工作组的情况下进行。

其章程重点：

• 1.目标及非目标；
• 2.WG和SIG的关系；
• 3.创建WG的流程及要求；
• 4.解散WG的流程。

SIG以及WG，都通过sigs.yaml进行配置。

D.用户组（UG） – 是用于促进与大量 Kubernetes 用户长期相关的主题相关信息的交流和发现的组。不拥有 Kubernetes 代码库所有权。用户组是用户和社区成员之间就没有可交付成果或超出项目范围的主题提供交流和协作的场所。这些主题不适合组建 SIG、WG 或委员会。

其章程重点：

• 1、目标-促进 Kubernetes 用户和贡献者之间关于与 Kubernetes 和 Kubernetes 子项目的使用、扩展和集成相关的主题的交流
• 2、报告-向Steering Committee提交年度报告
• 3、如何创建和解散。

社区年度报告 ，主要是为了定期检查社区项目的健康度，让委员会成员、子项目所有者、WG 和 UG 组织者、和指导委员会之间建立反馈循环，推动项目发展。

代码库管理指南和规范 ，主要介绍代码仓的管理规则。K8S总共6大活跃组织仓，12个历史组织仓（目前已不活跃）。其中最核心及活跃的是K8S主仓及SIG仓。

除了上面组织仓外，对类似SIG仓都有非常详细的管理规则说明。

在SIG仓新增Repo是有规则约束，其中特别强调必须和CLA、PR Merge的CI bot能适配，这就是community value 中的“automation over process”体现。

其核心仓的要求还要更加严格些，还需要adopt all Kubernetes automation，另外，所有的Repo需要最核心的SIG-Architecture的approved。

此外，代码仓管理团队包含6名成员，有3名协调员进行协助管理。此外，用prow、label_sync工具实现自动化。

CLA签署指南和规范，K8S没使用Linux基金会的DCO，而使用CLA，据说原因是觉得DCO签署比CLA复杂。

2.2 沟通渠道

这部分内容主要将开发者问题沟通的渠道，把所有官方及非官方的渠道都列全了，不过内容组织稍显杂乱。

1、开发者进行安装、部署运行 Kubernetes 等问题，官网有Troubleshooting论坛入口，方便开发者查阅FAQ。

2、每月一次的社区会议，专项答疑开发者相关问题。

Youtube直播会议：

所有开发者可在 Slack 提前发布问题（有问题模板参考）

邀请志愿者组织及答疑，奖励优秀提问者（发T恤衫）。

3、社区不同组（SIG、WG、UG等）沟通渠道，包括kubernetes-dev邮件列表- 社区最新事件及技术问题讨论地。

KEP（ Kubernetes Enhancement Proposals ）- 社区开发设计标准提案模板。

2.3 学习上手

这里的说明很详细，首先是开发及贡献代码的流程文档。

贡献指南部分，内容详细的令人发指。首先，先告诉新人社区有什么open issue，新人可以先看 Go od first issue，这一般是入门级别的issue，对新人比较友好。

然后，告诉新人先决条件，签署CLA、请务必阅读并遵守行为准则和 社区价值观、设置开发环境。

设置开发环境部分，非常详细的介绍开发、测试、日志等规范，SIG仓开发规范等等。

其中主仓规范包括如下：

• 开发指南( development.md )：设置开发环境。
• 测试( testing.md )：如何在开发沙箱中运行单元、集成和端到端测试。
• 一致性测试( conformance-tests.md )什么是一致性测试以及如何创建/管理它们。
• 寻找片状测试( flaky-tests.md )：目标是 99.9% 无片状测试。
• 日志约定（logging.md）：klog 级别。
• 分析 Kubernetes ( profiling.md )：如何将 go pprof 分析器插入 Kubernetes。
• Instrumenting Kubernetes with a new metric ( instrumentation.md )：如何向 Kubernetes 代码库添加新的指标。
• 编码约定（coding-conventions.md）：为贡献者提供的编码风格建议。
• 文档约定（Kubernetes 文档）为贡献者提供的文档风格建议。
• 在本地运行集群（running-locally.md）：用于开发的快速轻量级本地集群部署。

SIG的规范也很详细，好处是在于SIG孵化项目开发时，告诉你开发过程遵循这些规范，避免出现最后移交到主仓时，各种不符合规范，导致代码合不了。

SIG 发布：

• Cherry Picks cherry-picks.md 如何在kubernetes/kubernetes存储库中的发布分支上管理樱桃选择。
• 获得Kubernetes构建 getting-builds.md
• 针对发布里程碑的增强、问题和 PRs release.md

SIG仪表：

• 日志约定 logging.md
• 事件风格指南 event-style-guide.md
• 检测 Kubernetes instrumentation.md
• Structured Logging 迁移说明 migration-to-structured-logging.md

SIG 存储：

• 注意Flexvolume 已弃用。树外 CSI 驱动程序是在 Kubernetes 中编写卷驱动程序的推荐方式。请在此处查看此文档以获取更多信息。
• CSI 驱动程序文档 CSI 驱动程序文档 该站点记录了如何在 Kubernetes 上开发、部署和测试容器存储接口(CSI) 驱动程序。
• Flexvolume flexvolume.md Flexvolume 使用户能够编写自己的驱动程序并在 Kubernetes 中添加对他们的卷的支持。

SIG 可扩展性：

• Kubemark 用户指南 kubemark-guide.md
• 如何设置 Kubemark 集群 kubemark-setup-guide.md
• 分析 Kubernetes profiling.md

SIG调度：

• 了解 Kubernetes Scheduler scheduler.md
• Kubernetes scheduler_algorithm.md 中的调度算法
• 调度器基准测试 scheduler_benchmarking.md

SIG架构：

• API 约定api-conventions.md
• 组件配置约定 component-config-conventions.md
• 更改 API api_changes.md
• Kubernetes 中的一致性测试conformance-tests.md

SIG API 规范：

• 合并补丁 strategy-merge-patch.md
• 控制器 controllers.md
• clientset生成和发布周期生成-clientset.md

SIG 测试：

• 测试指南 testing.md
• 编写良好的端到端测试为Kubernetes writing-good-e2e-tests.md、
• 编写好的一致性测试的Kubernetes writing-good-conformance-tests.md
• Kubernetes 中的集成测试integration-tests.md

SIG CLI：

• Kubectl 约定kubectl-conventions.md

到现在为止，社区的各种规矩都说明白了，接下来说明期望以及未来社区的打怪升级路线（怎么升级最后章节来讲）。

期望就是希望新人进社区怎么干活，比如代码审查，做审查前，先熟悉Go的常见错误，链接。

此外，告诉新人Review PR是非常严肃的事，干的不好会影响社区的整体形象，如果分配给你的Review你在deadline没法搞，那把自己的用户状态设置为“忙碌”，K8S的CI机器人就不会分配PR Review任务。如果长时间占着位子不干活，那就应该自己把自己干掉（OWNERS 文件中把自己删了），然后提名其他人替代自己。

社区相关的大型会议事件，以及Meetups都有协助参与及如何举办说明。

有非常详细的导师计划，这很重要，尤其对新人帮助很大。导师可以1对1，或者1对多形式，线上线下各种形式进行辅导，主要也从中挖掘有潜力的新人，培养成未来社区的Reviewer或approver 。

2.4如何贡献

首先告诉你社区所有的SIG，可以根据自己的爱好和专长选择具体的SIG去参与。目前总共20多个SIG，最核心的是Architecture sig。

除了architecture SIG , release SIG也很重要，在release sig中，版本发布策略、CI及dev分支方案、补丁方案、升级策略等都很详细。此外，正式的版本release, 以及SIG，都有issue和PR的处理状态 看板 。

参考

参考

接下来，告诉新人如何遵循贡献者指南，怎么提交issue，怎么贡献，怎么参与PR Review等。

其中贡献的种类很多，不仅仅是代码，还包括：

• 帮助改进 Kubernetes 文档；
• 阐明可以重命名或注释的代码、变量或函数；
• 编写测试覆盖率；
• 帮助分类问题。

PR Review之类参考下面说明，不解释了自己看吧。

新人一般没经验的话，参考下面的Best practices。“When you make a PR for small change (such as fixing a typo, stylechange, or grammar fix), please squash your commits so that we can maintain acleaner git history.”这段其实写的比较含蓄，翻译就是“ 别改个错别字就刷PR，刷单有害身体健康 ”，更重要的是会消耗社区的CI资源。

2.5成员规则

社区的成员级别，主要分为Member、Reviewer、Approver、Subproject owner。

成员（member）

硬性贡献包括：

1. 对项目或社区做出了多项贡献。贡献可能包括但不限于：

• 在 GitHub 上创作或审查 PR
• 在 GitHub 上提交或评论问题
• 参与 SIG、子项目或社区讨论（例如会议、Slack、电子邮件论坛、Stack Overflow）

1. 订阅kubernetes-dev@googlegroups.com
2. 由两名reviewers Sponsor

审核员（Reviewer）

1. 会员至少3个月
2. 代码库至少 5 个 PR 的主要审阅者
3. 审查或合并至少 20 个实质性 PR 到代码库
4. 熟悉代码库
5. 由子项目批准人赞助

• 无其他审批人反对
• 通过 PR 完成更新 OWNERS 文件

1. 可自行提名，由本子项目的审批人提名，或由CI机器人提名

批准员（Approver）

1. 至少 3 个月的代码库Reviewer
2. 代码库至少 10 个实质性 PR 的主要审阅者
3. 审查或合并至少 30 个 PR 到代码库
4. 由子项目业主提名

• 无其他子项目业主反对
• 通过 PR 来更新顶级 OWNERS 文件

子项目Owner

相比前三类，子项目Owner无硬性数据要求，主要要求如下：

1. 深入理解子项目的技术目标和方向
2. 深入了解子项目的技术领域
3. 通过完成以下所有工作对设计和方向做出持续贡献：

• 创作和审查提案
• 发起、贡献和解决讨论（电子邮件、GitHub 问题、会议）
• 识别设计和实施 PR 中的复杂问题

1. 通过实施和/或审查直接为子项目做出贡献

此外， 如何清退非活跃成员，也很重要。K8S社区希望所有的正式成员是社区中持续活跃的贡献者。因此，长期离开项目且没有活动的成员将从 Kubernetes Github 组织中删除。

如何衡量不活跃，在 18 个月内没有在K8S的任何组织中做出贡献的就算不活跃。由 CNCF DevStats 项目衡量（公正公开开源度量平台可衡量，由CNCF开源开发及维护）。

参考链接 ：