培养 Kubernetes 需要一个社区

编者注：这篇文章是关于 Kubernetes 1.8 新特性的系列深度文章的一部分，由来自微软的 Jaice Singer DuMars 撰写。

每次我们发布新版本的 Kubernetes，看到社区对其中所付出的所有辛勤工作的回应，都令人着迷。关于新功能或增强功能的博客像春天的野花一样遍布网络。演讲、视频、网络研讨会和演示也紧随其后。当社区似乎接受了这一切时，我们又会转过身来添加更多内容。成为这个项目的一部分，更重要的是成为这场运动的一部分，是一段激动人心的时刻。它不再仅仅是软件了。

当环境为我打开领导 1.8 版本发布的大门时，我签了字，尽管当时我有些许紧张。在与另一位社区成员的私下谈话中，他们向我保证“有组织、跟进并知道何时寻求帮助”是成为一名成功领导者的关键。那时我知道我能做到——所以我做了。

从那时起，我被社区的拼布包围着，它在恰当的时刻神奇地出现。社区对质量、一致性和责任的承诺和真诚热情，构成了发布本身的基石。

1.8 发布团队尽管起步较晚，但证明了其令人难以置信的凝聚力。我们以幽默、勤奋和真诚的好奇心对待即使是最困难的情况。我领导大型团队的经验对我很有帮助，并突出了这次发布的另一个不同之处：对我来说，专注于领导力比深入技术细节解决每个问题更有价值。

此外，Slack 中表情符号的振奋人心的力量不容小觑。

Kubernetes 项目正在经历一个重要的转折点。如果您经历过“创业过山车”，这是一个熟悉的故事。您提出了一个疯狂的想法，它可能行得通。您构建它，获得牵引力，然后慢慢地爬上第一个大坡。从山顶看到的景色令人眼花缭乱，因为您已经将无数小时的生命投入到完全未知的事物中。一旦您越过山顶，一切都会改变。惊人的加速定义或摧毁已经建立的东西。

根据我的经验，那个零重力点是公司（或在本例中是项目）中的每个人都必须认真对待的，不仅要构建东西，还要维护它。如果没有对维护的承诺，事情会很快出错。从类似于温彻斯特神秘屋的代码库到崩溃的生产实施的流行，尽管表面上看起来很成功，但混乱的火热降临可能会迅速发生。值得庆幸的是，Kubernetes 社区似乎在每次发布时都以越来越大的成功度过我们的增长过山车。

随着软件初创公司的成熟，在劳动分工的增加中反映出一种自然的演变。爆炸式的采用意味着需要全职的安全、运营、质量、文档和项目管理人员来提供稳定性、可靠性和可扩展性。此外，当有意的架构对于确保长期一致性变得必要时，您就知道事情正在变得严重起来。

Kubernetes 也遵循了类似的道路。在没有公司部门或特定技能团队的情况下，特别兴趣小组（SIG）围绕存储、网络、API 机制、应用程序和运营生命周期等核心项目需求而有机地形成。随着 SIG 的激增，Kubernetes 治理模型围绕它们得以巩固，为代码所有权和共同责任提供了框架。SIG 还有助于确保社区的可持续发展，因为成功往往更多地取决于人而不是代码。

在六月份的 Kubernetes 领导力峰会上，拟议的 SIG 架构以一致投票的方式获得批准，强调了一个似乎以某种方式渗透到每场对话中的稳定性主题。填补主要功能空白的日子似乎已经结束，取而代之的是一个功能深度的新时代。

另一个变化是从项目级发布“功能主题”转向在多个版本中以增量方式交付的 SIG 级计划。这是一个重要的转变：SIG 有一个使命，他们交付的一切最终都应该为之服务。作为一个社区，我们需要提供便利和支持，以便 SIG 能够以最小的开销和最大的透明度做到最好。

明智的是，社区还发现了提供安全创新机制的机会，这些机制越来越少依赖于 kubernetes/kubernetes 中的代码。这反过来又创造了一个繁荣的实验栖息地，而不会妨碍整体速度。该项目还可以解决在最初爬上过山车时产生的技术债务。但是，新的创新机制在定义什么是 Kubernetes 以及什么不是 Kubernetes 时提出了架构挑战。SIG 架构解决了定义 Kubernetes 边界的挑战。这是一项正在进行的工作，其趋势是持续改进。

这在个人层面上可能有点让人不知所措。实际上，它与任何其他成功的初创公司没有太大区别，只是权力并非来自传统的组织结构图。它来自 SIG、社区技术领导者、新成立的指导委员会，最终来自您。

Kubernetes 发布过程提供了一个特殊的机会来了解使该项目运转的一切。我会告诉你我所看到的：人们共同努力，尽其所能，为所有踏上云原生之旅的人服务。

• ←上一篇
下一篇→