这篇文章发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不再正确。
Kubernetes 生日快乐。哦，您将去的地方！
亲爱的 K8s，
真不敢相信你才一岁 - 你成长得太快了。在你一岁生日之际，我想写一个小纸条，说说我为什么在你出生时如此兴奋，为什么我感到很幸运能成为养育你的群体的一员，以及为什么我渴望看到你继续成长！
--Justin
你开始时就拥有一个优秀的基础 - 良好的声明式功能，围绕一个具有明确架构的可靠 API 构建，以及让我们能够在未来发展的机制。果然，在你的第一年里，你成长得如此之快：自动缩放、HTTP 负载均衡支持 (Ingress)、对包括集群数据库在内的持久性工作负载的支持 (PetSets)。你与更多的云成为了朋友（欢迎 Azure 和 OpenStack 加入这个大家庭），甚至开始跨越区域和集群（联邦）。这些仅仅是一些最明显的变化 - 在你大脑内部发生了太多事情！
我认为你一直以来所做的一切都保持着如此开放的态度，这真是太棒了 - 你似乎把所有事情都写在 GitHub 上 - 不管是好是坏。我认为我们都在这个过程中学到了很多东西，比如工程师在没有完全相同的精确性和严谨框架的情况下做出声明，然后根据这些声明来衡量的危险。但我很自豪你选择不降低你的标准，而是迎接挑战并加速前进 - 这可能不是最现实的方法，但这却是移山的唯一方法！
然而，不知何故，你成功地避免了很多其他开源软件陷入的常见死胡同，特别是随着这些项目变得更大，开发人员最终在它上面的工作时间比直接使用它的时间还要多。你是怎么做到的？有一个可能不可靠的故事，说的是 IBM 的一名员工犯了一个巨大的错误，被召去见大老板，以为自己会被解雇，结果却被告知“我们刚刚花了数百万美元来培训你。我们为什么要解雇你？”。尽管谷歌（以及 Redhat 和其他公司）对你投入了大量资金，但我有时会想，我们正在避免的错误是否可能更有价值。这里有一个非常开放的开发流程，但也有一个“预言者”，有时会通过告诉我们如果我们在某个特定设计决策中犯错，两年后会发生什么来纠正方向。这是一个你应该听从的父母！
所以，虽然你只有一岁，但你确实拥有一个 老灵魂。我只是 众多养育你的人之一，但能够与那些构建了这些令人难以置信的系统并拥有所有这些领域知识的人一起工作，对我来说是一次很棒的学习体验。然而，因为我们是从头开始的（而不是采用现有的 Borg 代码），我们处于同一水平，仍然可以就如何养育你进行真正的讨论。好吧，至少我们尽可能地处于同一水平，但值得称赞的是，他们都太友好了，绝不会提及此事！
如果我只能选择那些杰出人士做出的两个明智的决定
- 标签和选择器为我们提供了声明式“指针”，因此我们可以说出我们想要东西的“原因”，而不是直接列出这些东西。这就是你如何扩展到 很高的高度的秘诀；不是通过命名每个步骤，而是说“再进行一千个像第一个一样的步骤”。
- 控制器是状态同步器：我们指定目标，你的控制器会不知疲倦地工作，使系统达到该状态。它们通过强类型 API 基础工作，并在整个代码中使用，因此 Kubernetes 更像是一组一百个小型程序，而不是一个大型程序。仅从技术上扩展到数千个节点是不够的；该项目还必须扩展到数千名开发人员和功能；而控制器可以帮助我们实现这一点。
所以我们将继续前进！我们将替换这些控制器并在此基础上构建更多，API 基础使我们能够以这种方式构建任何我们可以表达的东西 - 大多数东西都只是一个标签或注解！但你的想法不会被语言定义：通过第三方资源，你可以表达你选择的任何内容。现在我们可以在不构建 Kubernetes 的情况下构建 Kubernetes，创造出感觉与 Kubernetes 其他部分一样的事物。许多最近的添加，如入口、DNS 集成、自动缩放和网络策略，都是以这种方式完成的或可以以这种方式完成的。最终，很难想象你在这之前会是什么样子，但今天的标准功能可以在今天开始，没有障碍或看门人，甚至可能只为一个受众。
所以我期待看到越来越多的增长发生在离 Kubernetes 核心越来越远的地方。我们必须经历这些阶段；从需要在 Kubernetes 内核中发生的事情开始 - 比如用部署替换复制控制器。现在我们开始构建不需要核心更改的东西。但我们仍然在将基础设施与应用程序分开讨论。接下来真正有趣的是：当我们开始构建依赖于 Kubernetes API 的应用程序时。我们一直都有使用 Kubernetes API 自组装的 Cassandra 示例，但我们甚至还没有真正开始更广泛地探索它。正如 S3 API 改变了我们构建记住事物的方式一样，我认为 k8s API 将改变我们构建思考事物的方式。
所以我很期待你的两岁生日：我可以尝试预测你那时会是什么样子，但我知道你会超越我所能想象的最胆大的事情。哦，你会去的地方！