社区协作才能成就 Kubernetes

编者按：本文是关于 Kubernetes 1.8 新特性的系列深度文章之一，作者是来自 Microsoft 的 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 方面带来了架构挑战。SIG Architecture 解决了定义 Kubernetes 边界的挑战。这是一个持续改进的工作，正在进行中。

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

Kubernetes 发布过程提供了一个特殊的机会，可以看到让这个项目运转起来的一切。我会告诉你我看到了什么：人们，一起工作，尽力而为，为所有踏上云原生之旅的人们提供服务。

• ←上一篇
• 下一篇→