协作翻译
原文：Will Kubernetes Collapse Under the Weight of Its Complexity?
链接：https://www.influxdata.com/blog/will-kubernetes-collapse-under-the-weight-of-its-complexity/
译者：局长, 凉凉_, kevinlinkai
几周前，我参加 KubeCon EU 并发表演讲。这是一场约有 4,700 人参加的大型活动。这让我想起了2014年11月在巴黎举行的 OpenStack 峰会。这场活动同样的声势浩荡，有很多厂商都在里面宣传，还有很多大规模的会议，大部分参会者都是程序员。然而，我觉得这次活动存在潜在的问题：我交流的每个人几乎都是清一色的运维人员或 SRE 工程师。宣传说的大量应用程序开发者在哪里？那些复杂的基础设施不是应该服务于这些开发者吗？Kubernetes 社区是否真的有在关注用户的需求？于是我不禁想到：Kubernetes 是否太复杂了？它会因自身的复杂性而被压垮吗？会像 OpenStack 一样自2014年以来逐渐式微吗？
好吧，我承认自己的这种想法有点多虑了，我应该说最终我不认为情况会是这样。 Kubernetes 具有 OpenStack 从未有过的一些优势。首先，它已经具有更高的可扩展性，因此它实际上能够在数千台服务器的环境中实现大规模集群调度的梦想。其次，所有三家主要云供应商都推出了托管 Kubernetes 的服务产品。在短短四年内，Kubernetes 已成为云计算和基础设施领域的事实标准。然而，它的复杂性对于用户来说仍是一个重要的问题。
大多数开发者都没有面临 Google 这种规模的问题
开发 Kubernetes 主要是为了解决类似 Google 这种规模的复杂性和问题。我们希望基础设施具备自我修复、水平可伸缩和声明式配置（如基础设施即代码）的功能。但是，绝大多数应用程序和应用程序开发者都不会遇到这种问题。大多数应用程序在规模（项目规模和用户群规模）方面都要小得多，或者它们尚处在摸索产品市场的早期阶段。
对于根本没有规模问题的应用程序，它们通常不需要增加自我修复、水平可扩展系统的复杂性。考虑使用能够处理负载的单个数据库和应用程序服务器可能是更好的选择。如果在 99.5% 的时间里，它是可用的，并为运维人员提供适当的警报系统，这对于许多应用程序和工作负载来说就已经很不错了。相比之下，构建分布式系统的复杂性和延迟上线的时间可以说是不值得的麻烦和投资。
对于全新的应用程序，它们最大的风险是没有找到适合的产品/市场。也就是说，它们虽然被部署了，却从未使用过。它们的代码最终会被抛弃，因为这并不是人们真正想要的东西。这也代表了绝大多数开发者编写的应用程序代码所面临的处境。在我的职业生涯中，我把大部分时间花在了代码和功能迭代上，并尝试找寻正确的应用程序功能集。一旦找到后，我们可以对其进行扩展，但在此之前就这样做是不成熟的优化。
我在 Kubernetes 观察到的问题是，它在项目早期阶段对认知负荷的要求太高了。你需要开始和考虑的事太多，这是启动项目并快速迭代它的障碍。在项目的早期，功能开发速度和迭代速度是最重要的因素。我认为 Heroku 模型是理想的开发模型 —— 你可以使用托管的 Postgres 数据库，同时通过 git push 来获得部署的新代码并提供对外的服务。这几乎没有什么需要考虑的。它可能无法无限扩展，而且可能会变得十分昂贵，但在应用未达到较大规模之前，我们并不需要担心这些事情。
简单来说，Kubernetes 让简单的事情变得更复杂，并让解决复杂的事情成为可能。如果 Kubernetes 真的要成功，它需要让项目的早期阶段变得更容易，并降低应用程序开发者的认知负担。如果能实现开发者在某个时刻学习关于 Kubernetes 内外及各种错综复杂的细节，并且没什么问题，这就很好了。随着规模增长，任何事物都会变得十分复杂和困难。但作为一个成功的开发平台，如果不是必要的情况下，不需要将决策压力摆在开发者面前。Ruby on Rails 之父 David Heinemeier Hansson(DHH)在他的 RailsConf 2018 主题演讲中称之为“JIT学习”。
说到 DHH，我在这里想使用 Rails 作为例子。我想要探讨的第一件事是：为什么 Rails 当时如此成功？这不是因为 Ruby 备受欢迎（它当时只是一门来自日本的不知名编程语言），也不是因为 Rails 和 Ruby 在动态网页方面提供了最快的速度，而是因为它们大大提高了开发者的开发效率。当 DHH 向大家介绍如何在 15 分钟内搭建一个博客时，这极大地引起了 Java 和 .Net 开发者的注意，因为这通常需要耗费他们几个星期甚至几个月的时间才能实现同样的需求。开发者选择 Rails 是因为他们可以迅速为用户发布新功能，这恰好是所有这些框架和基础设施的真正意义所在。
Rails 做得最好的一件事是，它为你生成了一个应用程序的 shell，并为你提供了帮助生成脚手架和项目的其他部分。这使得开发者不必在项目开始时就需要做出大量决策，比如考虑如何组织应用程序代码、数据库模型应放在哪里、资源管道(asset pipeline)应该如何定义、如何进行数据库迁移，以及许多其他任务和决策。
我认为 Kubernetes 可以从这类生成器中受益良多。现在已经有针对特定资源的生成器，但这远远不能满足需求。如果能提供针对不同类型的应用程序的模板，这就更好了，哪怕是最常见的模板。关系数据库、应用程序层、缓存服务器，消息队列和工作池的组合可能占据了构建应用程序的 90% 甚至更多。这种简单的结构能够扩展到令人难以置信的请求和复杂性。创建开箱即用的模板或生成器，以及 Kubernetes 资源和代码的组织结构，将非常有用。
用于通用元素的脚手架生成器非常好。你需要一个 MySQL 数据库？不妨使用类似下面的命令：
来创建状态集、服务和其他所有必需的东西。然后，只需要一个命令就可以将脚手架放进您的 k8s 环境，接着再使用几个控制台命令就能拥有一个生产环境就绪的数据库。可以为流行的应用框架、消息代理和任何我们能想到的东西使用类似的方法进行创建。
也许运维人员和 Helm 图表的组合就能完成这些工作，但我认为还不够好。当然，除了 Kubernetes 之外，我们迫使开发者了解另外两个额外的工具。即使只是增加了解的技术术语和安装新的命令行工具，它们也需要额外的努力和思考。这些东西的定位应该是“第一公民”，并且是 Kubernetes 开箱即用体验的一部分，可以直接通过 kubectl 来访问。
CNCF 项目的领地越来越大
对于 Kubernetes 来说，CNCF 中的项目越来越多算不上是一个特别的问题，但 CNCF 项目的领地非常巨大，这就使得 KubeCon/CNCF 会议极为分散。往往一个大会期间就包含了 14 个主题。对开发者而言，怎么知道自己的项目需要哪些工具？让我们来看看 Cloud Native 这个庞大的格局。
Cloud Native Landscape. Image source: https://twitter.com/dankohn1/status/989956137603747840
要理解图中所有的这些项目是不可能的。但如果提供一个路径能获得一组已经预设好的工具，应用开发者应该会有更好的服务体验。如果他们想要在其中加入不同的工具，这也没问题，但至少不应让开发者事先就去考虑这些问题。 CNCF 日益增加的复杂性和更广泛的覆盖范围可能会削弱 Kubernetes 作为构建平台的重点和品牌。我不确定最终结果可能是什么，或者我是否在过度吹嘘，但从我在会议上的角度来看，这就像工具大杂烩(tool porn)。当我们在整个职业生涯中都把时间花在学习并构建基础设施的新工具时，该如何解决用户问题？
我要强调的是：基础设施是帮助应用程序开发者解决用户实际问题的工具。它应该能优化开发者的效率和交付能力。能做到这一点的开放平台才有机会胜出。
必要的知识
在某些时候，开发者需要更深入地学习基础设施工具。大多数在 AWS 工作的开发者都熟悉该云中的一些组件，就像 GCP 或 Azure 上的开发者熟悉这些组件的情况一样。将 Kubernetes 作为基础层可能更有前途，因为开发人员可以学习这一范例，就能将其技术与框架一起带到任何公共或私有云中。
这种可移植性是我们选择 Kubernetes 作为正在开发的新版 2.0 版本云产品的基础设施层架构的原因。但是学习曲线就摆在那里，所以我们的开发团队也正在逐渐增加人员。为此，我为整个开发团队制作了所需的阅读材料 Kubernetes: Up and Running。
我希望 Kubernetes 有一条平缓的学习曲线，Kubernetes 作为一个生态系统需要满足应用程序开发者真正的需求才能取得成功。毕竟基础设施是一种支持工具，用于解决面向用户的应用程序代码中所体现的客户问题。提高应用程序开发者的工作效率是确保一个平台能被广泛采用并取得成功的最佳和最可靠的方法。
