天翼|谈谈Kubernetes开源社区和未来走向( 二 ) 科技创新|中国电信

而说到 Kubernetes 项目的治理方式，其实还是比较贴近 Google 风格的，即：重视代码，重视社区的民主性。
首先， Kubernetes 项目是一个没有“Maintainer”的项目。这一点非常有意思， Kubernetes 项目里曾经短时间内存在过 Maintainer 这个角色，但是很快就被废弃了。取而代之的，则是 approver+reviewer 机制。这里具体的原理，是在 Kubernetes 的每一个目录下，你都可以添加一个 OWNERS 文件，然后在文件里写入这样的字段：
approvers:- caesarxuchaoreviewers:- lavalamplabels:- sig/api-machinery- area/apiserver
比如，上面这个例子里， approver 的 GitHub ID 就是caesarxuchao （Xu Chao）， reviewer 就是 lavalamp 。这就意味着，任何人提交的Pull Request（PR ，代码修改请求），只要修改了这个目录下的文件，那么就必须要经过 lavalamp 的 Code Review ，然后再经过caesarxuchao的 Approve 才可以被合并。当然，在这个文件里， caesarxuchao 的权力是最大的，它可以既做 Code Review ，也做最后的 Approve 。但，lavalamp 是不能进行 Approve 的。
当然，无论是 Code Review 通过，还是 Approve ，这些维护者只需要在 PR下面Comment /lgtm 和 /approve ， Kubernetes 项目的机器人（k8s-ci-robot）就会自动给该 PR 加上 lgtm 和 approve标签，然后进入 Kubernetes 项目 CI 系统的合并队列，最后被合并。此外，如果你要对这个项目加标签，或者把它 Assign 给其他人，也都可以通过 Comment 的方式来进行。
可以看到，在上述整个过程中，代码维护者不需要对Kubernetes 项目拥有写权限，就可以完成代码审核、合并等所有流程。这当然得益于 Kubernetes 社区完善的机器人机制，这也是 GitHub 最吸引人的特性之一。
顺便说一句，很多人问我， GitHub 比 GitLab 或者其他代码托管平台强在哪里？实际上，GitHub 庞大的API 和插件生态，才是这个产品最具吸引力的地方。
当然，当你想要将你的想法以代码的形式提交给 Kubernetes项目时，除非你的改动是 bugfix 或者很简单的改动，否则，你直接提交一个 PR 上去，是大概率不会被 Approve 的。这里的流程，一定要按照我下面的讲解来进行：

在 Kubernetes 主库里创建 Issue ，详细地描述你希望解决的问题、方案，以及开发计划。而如果社区里已经有相关的Issue存在，那你就必须要在这里把它们引用过来。而如果社区里已经存在相同的 Issue 了，你就需要确认一下，是不是应该直接转到原有 issue 上进行讨论。
给 Issue 加上与它相关的 SIG 的标签。比如，你可以直接 Comment /sig node ，那么这个 Issue 就会被加上 sig-node 的标签，这样 SIG-Node的成员就会特别留意这个 Issue 。
收集社区对这个 Issue 的信息，回复 Comment ，与 SIG 成员达成一致。必要的时候，你还需要参加 SIG 的周会，更好地阐述你的想法和计划。
在与 SIG 的大多数成员达成一致后，你就可以开始进行详细的设计了。
如果设计比较复杂的话，你还需要在 Kubernetes 的设计提议目录（在Kubernetes Community 库里）下提交一个 PR ，把你的设计文档加进去。这时候，所有关心这个设计的社区成员，都会来对你的设计进行讨论。不过最后，在整个 Kubernetes 社区只有很少一部分成员才有权限来 Review 和 Approve 你的设计文档。他们当然也被定义在了这个目录下面的 OWNERS 文件里，如下所示：

reviewers:- brendandburns- dchen1107- jbeda- lavalamp- smarterclayton- thockin- wojtek-t- bgrant0607approvers:- brendandburns- dchen1107- jbeda- lavalamp- smarterclayton- thockin- wojtek-t- bgrant0607labels:- kind/design