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