生日快乐Kubernetes。哦,你去的地方!

编者注:今天的嘉宾帖子来自Kubernetes的独立撰稿人贾斯汀·圣芭芭拉(Justin Santa Barbara)。

亲爱的K8,

很难相信您只是一个人-您成长如此之快。在您的第一个生日之际,我想写一点便条,说明为什么我出生时如此兴奋,为什么我感到很幸运能成为养育您的团队的一分子以及为什么我渴望观看你继续长大!

-贾斯汀

您从一个良好的基础开始-良好的声明性功能,围绕具有定义良好的架构和机制的可靠API构建,以便我们可以不断发展。可以肯定的是,在您的第一年中,您发展如此之快:自动缩放,HTTP负载平衡支持(Ingress),对包括群集数据库(PetSet)在内的持久性工作负载的支持。您已经结交了更多的云朋友(欢迎使用Azure和OpenStack族),甚至开始跨越区域和群集(联邦)。这些只是一些最明显的变化-您的大脑内部发生了太多事情!

我觉得很高兴您所做的一切如此开放-您似乎在GitHub上写下了所有内容-不管是好是坏。我认为我们在此过程中已经学到了很多东西,例如让工程师制作比例声明,然后在没有完全相同的精确度和严格性框架的情况下权衡所提出的要求的危险。但令您感到骄傲的是,您选择不降低标准,而是迎接挑战,只是跑得更快-这可能不是最现实的方法,但这是搬山的唯一方法!

但是,以某种方式,您设法避免了其他开源软件陷入的许多常见死角,特别是当这些项目变得更大并且开发人员最终比直接使用它更多时,在此方面做更多的工作。你是怎么做到的?有个IBM员工的故事可能很荒谬,犯了一个大错误,被传唤与大老板见面,期望被解雇,但被告知“我们刚刚花了数百万美元培训您。我们为什么要解雇你?”。尽管Google投入了所有的投资(以及Redhat和其他公司),但我有时还是想知道我们避免的错误是否值得更多。这是一个非常开放的开发过程,但是还有一个“甲骨文”有时会通过告诉我们如果我们做出特定的设计决定会在两年后发生什么而纠正错误。这是您可能应该听的父母!

因此,尽管您只有一岁,但您确实有 老灵魂。我只是其中之一 很多人抚养你,但对我来说,与能够构建这些令人难以置信的系统并拥有所有这些领域知识的人们一起工作是一次很棒的学习经历。但是,因为我们是从头开始的(而不是采用现有的Borg代码),所以我们处于同一水平,并且仍然可以就如何培养自己进行真正的讨论。好吧,至少与我们曾经达到的水平差不多,但是值得他们赞扬的是,他们都太好了!

如果我只选择那些聪明的人做出的两个明智的决定:

  • 标签和选择器为我们提供了声明性的“指针”,因此我们可以说“为什么”想要东西,而不是直接列出它们。这是扩展规模的秘诀 高处;不是说出每个步骤的名称,而是说“就像第一个步骤一样,再增加一千个步骤”。
  • 控制器是状态同步器:我们指定目标,您的控制器将不懈地努力使系统进入该状态。它们通过强类型的API基础工作,并在整个代码中使用,因此Kubernetes不仅仅是一组100个小程序,而不是一个大程序。从技术上讲,这还不足以扩展到数千个节点;该项目还必须扩展到成千上万的开发人员和功能;控制器帮助我们到达那里。

依此类推,我们将继续前进!我们将替换这些控制器并在更多的基础上进行开发,并且基于API的基础架构使我们能够构建以这种方式可以表达的任何内容-大部分内容都只是标签或注释而已!但是您的想法不会被语言定义:借助第三方资源,您可以表达自己选择的任何内容。现在我们可以构建Kubernetes,而无需在Kubernetes中进行构建,从而创建与Kubernetes一样多的东西。最近增加的许多功能(例如入口,DNS集成,自动缩放和网络策略)已经完成或可以通过这种方式完成。最终,很难想象您会遇到这些事情,但是明天的标准功能可以从今天开始,没有障碍或关守,甚至对于一个观众来说也是如此。

因此,我期待着Kubernetes的核心越来越多地实现增长。我们必须在这些阶段中努力工作。从Kubernetes内核中需要发生的事情开始-例如用部署替换复制控制器。现在,我们开始构建不需要核心更改的东西。但是我们仍然在谈论基础架构和应用程序。接下来的事情变得非常有趣:当我们开始构建依赖Kubernetes API的应用程序时。我们一直都有使用Kubernetes API进行自组装的Cassandra示例,但实际上我们还没有真正开始对此进行更广泛的探索。以与S3 API改变我们构建记忆的方式相同的方式,我认为k8s API将改变我们构建思考事物的方式。

因此,我期待着您的第二个生日:我可以尝试预测一下那时的情况,但是我知道您甚至会超越我能想象的最大胆的事情。哦,你去的地方!

-Justin Santa Barbara,独立Kubernetes贡献者