培养Kubernetes需要一个村庄

编者注:这篇文章是 系列深入文章 由Microsoft的Jaice Singer DuMars撰写的Kubernetes 1.8的新功能。

每次我们发布新版本的Kubernetes时,令人着迷的是,社区如何响应其中的所有艰苦工作。具有新功能或增强功能的博客像春天的野花一样遍布整个网络。讲座,视频,网络研讨会和演示都紧随其后。一旦社区似乎将所有这些都考虑进去,我们就会转身并添加更多内容。成为这个项目的一部分,这是一个激动人心的时刻,更重要的是,这个运动。不再只是软件了。

当情况为我打开1.8版本的大门打开了大门时,尽管有少量蝴蝶,但我还是签了字。在与另一位社区成员的私人对话中,他们向我保证,“有条理,跟进并知道何时寻求帮助”是成功领导的关键。那时我知道我可以做到,所以我做到了。

从那时起,我被包裹在一个错落有致的社区被子中,在适当的时机神奇地出现了。社区对质量,一致性和责任制的承诺和热忱构成了发布本身的基础。

尽管起步较晚,但1.8发布团队的凝聚力令人难以置信。我们甚至以幽默,勤奋和真诚的好奇心来应对最困难的情况。我领导大型团队的经验为我提供了很好的帮助,并强调了此版本的另一个区别:对我而言,专注于领导力比投入技术性杂草解决所有问题更有价值。

还有, Slack中的表情符号 不能被高估。

Kubernetes项目正在进行中一个重要的转折点。如果您乘坐的是“过山车过山车”,这是一个熟悉的故事。您想到的想法太疯狂了,可能会奏效。您建造它,获得牵引力,然后慢慢地单击咔哒一声爬上那座第一座大山。顶部的景色令人眼花,乱,因为您将无数小时的生命投入了完全未知的事物。一旦您越过山顶,一切都会改变。突如其来的加速度定义或破坏了建造的东西。

以我的经验,零重力点是公司中每个人(或在本例中为项目)必须认真对待不仅要构建事物而且要维护它的地方。没有维护的承诺,事情就会很快变糟。从外观类似于Winchester Mystery House的代码库,到崩溃的生产实现的流行,尽管表面上看起来很成功,但很快就会陷入混乱。值得庆幸的是,Kubernetes社区似乎正乘着我们的增长过山车,每次发行都越来越成功。

随着软件初创公司的成熟,劳动力分配的增长自然反映了这一变化。爆炸性采用意味着必须有专职安全,操作,质量,文档和项目管理人员来提供稳定性,可靠性和可扩展性。另外,您知道当有必要使用有意识的架构来确保随时间推移的一致性时,事情变得越来越严重。

Kubernetes也遵循类似的道路。在没有公司部门或专门技能的团队的情况下,围绕存储,网络,API机械,应用程序和操作生命周期等核心项目需求,有机地组织了特殊兴趣小组(SIG)。随着SIG的激增,Kubernetes治理模型围绕它们逐渐形成,为代码所有权和责任分担提供了框架。 SIG还可帮助确保社区的可持续发展,因为成功通常与人有关而不是与代码有关。

在Kubernetes 领导峰会 六月,提议的SIG体系结构获得一致通过,强调了一个稳定主题,该主题似乎以一种或另一种方式渗透到每个对话中。填补主要功能差距的日子似乎已经过去,并且功能深度的新时代已经出现。

另一个变化是从项目级别的发布“功能主题”过渡到在多个版本的过程中以增量方式交付的SIG级别的计划。这是一个重要的转变:SIG承担着使命,他们提供的一切最终都应为之服务。作为一个社区,我们需要提供便利和支持,以便SIG能够以最小的开销和最大的透明度来尽力而为。

明智地,社区还发现了提供创新的安全机制的机会,这种机制越来越不依赖于kubernetes / kubernetes中的代码。反过来,这又为实验创造了一个繁华的栖息地,而又不影响整体速度。该项目还可以解决在过山车最初行驶期间产生的技术债务。然而,新的创新机制在定义什么是Kubernetes或什么不是Kubernetes方面提出了架构挑战。 SIG架构解决了定义Kubernetes边界的挑战。这项工作正在朝着持续改进的方向发展。

在个人层面上,这可能有些令人不知所措。实际上,除了授权并非来自传统的组织结构图之外,它与其他任何成功的启动公司都没有太大区别。它来自SIG,社区技术负责人,新组建的指导委员会,最后是您。

Kubernetes的发布过程提供了一个特殊的机会来查看使该项目产生变化的所有内容。我将告诉您我所看到的:人们共同努力,尽其所能,为出发于云原生之旅的每个人提供服务。