众人拾柴火焰高，共建 Kubernetes

编者按：这篇帖子是关于 Kubernetes 1.8 新特性的系列深度文章的一部分，由 Microsoft 的 Jaice Singer DuMars 撰写。

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

当情况为我领导 1.8 版本打开大门时，尽管我有点紧张，但我还是答应了。在与另一位社区成员的私人谈话中，他们向我保证，“有条不紊、跟进并知道何时寻求帮助”是成功的领导者的关键。那时我知道我能做到——所以我做到了。

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

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

此外，Slack 中的表情符号的提升力量不可低估。

Kubernetes 项目正在经历一个重要的转折点。如果您曾乘坐过“创业过山车”，这是一个熟悉的故事。您想出了一个疯狂的想法，它可能会成功。您构建它，获得关注，然后慢慢地咯哒咯哒地爬上第一个大山坡。从山顶俯瞰，令人眩晕，因为您将无数的生命时间投入到完全未知的事物中。一旦您越过那个山坡，一切都改变了。惊人的加速定义或摧毁了已经建立起来的一切。

根据我的经验，那个零重力点是公司（或在这种情况下，项目）中的每个人都必须认真对待不仅要构建东西，还要维护它的时候。如果没有维护承诺，事情会很快出错。从像温彻斯特神秘屋一样的代码库到生产实现崩溃的流行病，尽管表面上成功，但混乱的火热下坠会很快发生。值得庆幸的是，Kubernetes 社区似乎在每次发布中都越来越成功地驾驭着我们的增长过山车。

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

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

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

另一个变化是，从项目层面的发布“功能主题”转向在几次发布过程中逐步交付的 SIG 层面倡议。这是一个重要的转变：SIG 有其使命，它们交付的一切最终都应服务于该使命。作为一个社区，我们需要提供便利和支持，以便 SIG 能够在最小的开销和最大的透明度下完成最佳工作。

明智的是，社区也看到了提供安全创新机制的机会，这些机制越来越不依赖于 kubernetes/kubernetes 中的代码。这反过来又为实验创造了一个蓬勃发展的栖息地，而不会阻碍整体速度。该项目还可以解决在过山车初始阶段产生的技术债务。然而，新的创新机制在定义什么是 Kubernetes 和什么不是 Kubernetes 方面提出了架构挑战。SIG 架构解决了定义 Kubernetes 边界的挑战。这是一项持续改进的进行中的工作。

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

Kubernetes 发布过程提供了一个特殊的机会，可以了解使该项目运转的一切。我看到了什么：人们齐心协力，尽力而为，为所有踏上云原生之旅的人们服务。

• ←上一篇
• 下一篇→