天翼|谈谈Kubernetes开源社区和未来走向( 三 )


这几位成员 , 就可以称为社区里的“大佬”了 。 不过我在这里要提醒你的是 , “大佬”并不一定代表水平高 , 所以你还是要擦亮眼睛 。 此外 , Kubernetes 项目的几位创始成员 , 被称作 Elders(元老) , 分别是jbeda、bgrant0607、brendandburns、dchen1107和thockin 。 你可以查看一下这个列表与上述“大佬”名单有什么不同 。

  1. 上述 Design Proposal被合并后 , 你就可以开始按照设计文档的内容编写代码了 。 这个流程 , 才是正常大家所熟知的编写代码、提交 PR、通过 CI 测试、进行Code Review , 然后等待合并的流程 。
  2. 如果你的 feature 是需要要在 Kubernetes 的正式 Release 里发布上线的 , 那么你还需要在Kubernetes Enhancements这个库里面提交一个 KEP(即Kubernetes Enhancement Proposal) 。 这个 KEP 的主要内容 , 是详细地描述你的编码计划、测试计划、发布计划 , 以及向后兼容计划等软件工程相关的信息 , 供全社区进行监督和指导 。
以上内容 , 就是 Kubernetes 社区运作的主要方式了 。
总结在本篇文章里 , 我为你详细讲述了 CNCF 和 Kubernetes 社区的关系 , 以及 Kubernetes 社区的运作方式 , 希望能够帮助你更好地理解这个社区的特点和它的先进之处 。
除此之外 , 你可能还听说过 Kubernetes 社区里有一个叫作Kubernetes Steering Committee的组织 。 这个组织 , 其实也是属于Kubernetes Community 库的一部分 。 这个组织成员的主要职能 , 是对 Kubernetes 项目治理的流程进行约束和规范 , 但通常并不会直接干涉 Kubernetes 具体的设计和代码实现 。
其实 , 到目前为止 , Kubernetes 社区最大的一个优点 , 就是把“搞政治”的人和“搞技术”的人分得比较清楚 。 相信你也不难理解 , 这两种角色在一个活跃的开源社区里其实都是需要的 , 但是 , 如果这两部分人发生了大量的重合 , 那对于一个开源社区来说 , 恐怕就是个灾难了 。
思考题【天翼|谈谈Kubernetes开源社区和未来走向】你能说出 Kubernetes 社区同 OpenStack 社区相比的不同点吗?你觉得这两个社区各有哪些优缺点呢?欢迎你在留言区写下自己的答案 , 我会与你交流 。