Kubernetes 是否会因其复杂性而崩溃？

作者：Paul Dix / 用例, 开发者
2018 年 5 月 24 日

关于服务应用开发者的重要性的思考

几周前，我参加了在欧盟举办的 KubeCon 大会并发表了演讲。这是一场盛大的活动，约有 4,700 人参加。这让我想起了 2014 年 11 月在巴黎举行的 OpenStack 峰会。它同样充满了疯狂的炒作、供应商展示以及在公共场所举办的大型会议派对，那里被程序员们占领了。然而，我感觉整个盛况背后隐藏着一个问题：我交谈过的每个人要么是运营商，要么是 SRE。应用开发者都在哪里？难道这些复杂的基础设施不应该是为他们服务的吗？这个社区真的与用户的需求联系在一起吗？这让我不禁想：Kubernetes 是否过于复杂？它最终会因其自身的复杂性而崩溃吗？它会像 OpenStack 自 2014 年以来似乎已经衰落那样逐渐消失吗？

好吧，既然我已经变得有点戏剧化和夸张了，我应该说我最终不认为情况会是这样。Kubernetes 有一些 OpenStack 从未有过的优势。首先，它已经更具可扩展性，因此它实际上能够实现数千台服务器环境中的大规模集群调度的梦想。其次，所有三家主要的云供应商都开通了托管 Kubernetes 的服务。在短短不到四年的时间里，Kubernetes 已经将自己定位为云和基础设施领域的通用语言。然而，复杂性问题仍然是一个令人头疼的问题。

大多数开发者没有 Google 规模的问题

这其中的核心思想是，Kubernetes 的开发是为了解决 Google 规模的复杂性和问题类型。您需要的是自我修复、水平可扩展和声明式（如基础设施即代码）的基础设施。然而，绝大多数应用程序和应用程序开发者并没有在这种世界中工作。大多数应用程序要么在规模（项目规模和用户群）上要小得多，要么是正在寻找产品市场契合度的应用程序的开始。

对于那些根本没有规模问题的应用程序，它们通常不需要自我修复、水平可扩展系统的额外复杂性。考虑能够处理您的负载的单服务器数据库和应用服务器要容易得多。如果它在 99.5% 的时间内可用，并且为运营商提供体面的警报来启动它，那么对于许多应用程序和工作负载来说就足够了。部署分布式系统所带来的复杂性和上市时间增加根本不值得麻烦和投资。

对于全新的应用程序，它们最大的风险是找不到产品/市场契合度。也就是说，它们被部署了但从未使用过。最终会被扔掉的代码，因为它是一些没有人真正想要构建的东西。这代表了绝大多数被编写的应用程序代码。这当然是我花费了大量职业生涯的地方，迭代代码和功能，以寻找正确的集合。一旦您找到了该应用程序和功能集，您就可以对其进行扩展。但在那之前这样做是一种过早的优化。

我看到的 Kubernetes 的问题是，在项目的早期阶段，认知负荷实在太高了。您需要创建和担心的东西的数量是启动项目并快速迭代的障碍。在项目的早期阶段，功能速度和迭代速度是最重要的因素。我将 Heroku 模式视为理想的开发模式。您有一个托管的 Postgres 数据库，只需 git push 即可部署新代码并发布。几乎没有什么可考虑的。它可能无法扩展到无限，而且可能会变得昂贵，但一旦您真正获得了成功，您就可以担心这些事情。

简而言之，Kubernetes 使简单的事情变得困难，使困难的事情变得可能（感谢 Tom Wilkie 的这句话，他在引用另一个项目时使用了这句话）。如果 Kubernetes 真的要取得成功，它需要使项目的早期阶段变得容易。它需要降低应用程序开发者的认知负荷。如果开发者需要在某个时候学习 Kubernetes 的所有来龙去脉和复杂性，那也没关系。在规模上，一切都是复杂而困难的。但是，成功的开发平台不会在必要之前将这些决策和智力压力放在开发者面前。David Heinemeier Hansson 在他的 RailsConf 2018 主题演讲中将此称为 “JIT 学习”。

说到 DHH，我想以 Rails 为例。我想探讨的第一件事是：为什么 Rails 在当时如此成功？这不是因为 Ruby 的流行（它主要是一种来自日本的未知事物），也不是因为 Rails 和 Ruby 在服务动态网页方面速度最快。而是因为它们实现了巨大的开发者生产力提升。当 DHH 发表关于在 15 分钟内创建一个博客的演讲时，它震惊了 Java 和 .NET 开发者，他们需要几周到几个月的时间才能做同样的事情。开发者选择 Rails 是因为他们可以更快地向用户交付功能，而这最终才是所有这些框架和基础设施的真正目的。

Rails 做的另一件很棒的事情是，它为您生成了应用程序的 shell，并为您提供了生成脚手架和项目其他部分的助手。这使得开发者可以轻松地在项目开始时不必做出大量决策。应用程序代码应该如何组织，数据库模型放在哪里，资产管道是什么样的，如何运行数据库迁移，以及许多其他任务和决策都为您做好了。如果您想超出范围，这是可能的，但您不必在一开始就考虑它。

我认为 Kubernetes 可以从更多这类生成器中受益。已经有 特定资源的生成器，但这远未达到我认为需要的程度。如果存在不同类型应用程序的模板，甚至是最常见的模板，那就太好了。关系数据库、应用层、缓存服务器、消息队列和工作池的组合可能涵盖了 90% 或更多已构建的所有应用程序所需的复杂性。这种简单的结构能够扩展到令人难以置信的请求量和复杂性。一个模板或生成器，可以开箱即用地创建所有内容，并具有 Kubernetes 资源和代码的组织结构，这将非常有帮助。

通用元素的脚手架生成器将非常棒。需要 MySQL 数据库？拥有类似下面的命令：

kubectl scaffold mysql --generate

来创建一个有状态集、服务和所有其他必要的东西将大有帮助。然后只需一个命令将脚手架部署到您的 k8s 环境中，您就可以在几个控制台命令中获得一个生产就绪的数据库。可以为流行的应用程序框架、消息代理以及我们可以想到的任何其他东西创建相同的脚手架。

也许运算符和 Helm charts 的组合涵盖了这一点，但我不认为这会奏效。然后我们迫使开发者除了 Kubernetes 之外还要学习另外两件事。即使只是增加词汇量和安装一个新的命令行工具，也需要额外的努力和思考。这些东西需要成为第一等公民，并成为 Kubernetes 开箱即用体验的一部分。它们需要通过 kubectl 访问。

CNCF 项目格局庞大且还在扩大

这并非 Kubernetes 特有的问题，但 CNCF 项目格局非常庞大。这使得 KubeCon/CNCF 会议非常分散。会议期间有 14 个演讲轨道。作为开发者，我的项目需要哪些工具？看看这张 云原生景观图。

<figcaption> 云原生景观。图片来源：https://twitter.com/dankohn1/status/989956137603747840</figcaption>

不可能理解它。最好为应用程序开发者提供一条快乐的路径，其中预先选择了工具。如果他们想插入不同的工具，那很好，但他们不应该在事先考虑它。CNCF 日益增长的复杂性和更广泛的范围可能会稀释 Kubernetes 作为构建事物的平台的重点和品牌。我不确定对此的答案可能是什么，或者我是否夸大了它，但从我在会议上的角度来看，这就像工具色情片。当你可以花费整个职业生涯来学习和构建新的基础设施工具时，为什么要费心解决用户问题呢？

我再怎么强调也不为过：基础设施是一种工具，旨在帮助应用程序开发者解决用户的实际问题。它应该优化他们的效率和交付能力。能够很好地做到这一点的开放平台将胜过所有其他平台。

所需知识

在某些时候，开发者需要更深入地学习基础设施工具。大多数在 AWS 中工作的开发者都熟悉该云中的某些组件，就像 GCP 或 Azure 上的开发者熟悉这些组件一样。将 Kubernetes 作为基础层可能更有前景，因为开发者可以学习这种范例，并将其带到任何公共或私有云中。

这种可移植性是我们选择 Kubernetes 作为正在开发的新云产品 2.0 版本的 инфраструктура 基础层的原因。但是学习曲线是存在的，因此我们的开发团队正在加速学习。为此，我将 Kubernetes: Up and Running 作为我们整个开发团队的必读书籍。

我希望学习曲线是平缓的，但 Kubernetes 作为一个生态系统需要拥抱应用程序开发者的需求才能真正成功。归根结底，基础设施是一种支持工具，服务于解决用户界面应用程序代码中表示的客户问题。提高应用程序开发者的生产力是确保平台广泛和成功采用的最佳和最可靠的方式。