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

2018年5月24日

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

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

对于那些根本不存在规模问题的应用，通常它们不需要一个自我修复、水平扩展的系统带来的额外复杂性。想象一个单台服务器数据库和应用程序服务器来处理您的负载要简单得多。如果它有99.5%的时间可用，并且有合适的警报让操作员介入，这对许多应用和工作负载来说就足够了。构建分布式系统所带来的复杂性和市场时间增加的代价，根本不值得麻烦和投资。

对于全新的应用，它们最大的风险是找不到产品/市场匹配。也就是说，它们被部署后从未被使用。这是最终被废弃的代码，因为它是某种没有人真正想要的东西所构建的。这代表了编写的大多数应用程序代码。这当然是我职业生涯中花费了大量时间的地方，不断迭代代码和功能，寻找正确的组合。一旦找到这个应用程序和功能集，就可以将其扩展。但在那之前做优化是过早的。

我看到的Kubernetes问题是项目初期认知负荷太高。需要创建和关注的事情太多，成了启动项目和快速迭代项目的障碍。在项目初期，功能速度和迭代速度是最重要的因素。我认为Heroku模型是理想的发展模式。您有一个托管的主机Postgres数据库，您只需git push就可以部署新代码并将其推出。几乎没有需要考虑的事情。它可能不会无限扩展，可能会很贵，但一旦您真的有所突破，您就可以考虑这些问题。

简单来说，Kubernetes让简单的事情变得困难，让困难的事情成为可能（感谢Tom Wilkie使用了这句话，他是在提及另一个项目时说的）。如果Kubernetes真的要成功，它需要让项目的初期变得简单。它需要降低应用开发者的认知负荷。开发者在某个时候需要学习Kubernetes的所有内部和外部细节，这是可以的。在规模上，一切都很复杂和困难。但一个成功的开发平台不会在必要时才将决策和智力压力放在开发者面前。David Heinemeier Hansson在2018年的RailsConf主题演讲中称这为“即时学习”。

说到DHH，我想用Rails作为例子。我想首先探讨的是：Rails当时为什么如此成功？这并不是因为Ruby的流行（它主要来自日本的未知事物），也不是因为Rails和Ruby在服务动态网页方面速度最快。是因为它们使开发者的生产力大幅提升。当DHH发表了他15分钟内创建博客的演讲时，它让那些花费数周甚至数月才能完成相同任务的Java和.NET开发者感到震惊。开发者选择了Rails，因为他们可以更快地将功能提供给用户，而这正是所有这些框架和基础设施真正所在。

Rails另一个伟大的地方是它为你生成应用程序的框架，并提供了生成脚手架和其他项目部分的辅助工具。这使得开发者不必在项目开始时做出大量决策。应用程序代码应该如何组织，数据库模型应该放在哪里，资产管道是什么样子，如何运行数据库迁移，以及其他许多任务和决策都是为你准备的。如果你想超出界限，那也是可能的，但你不必一开始就考虑这一点。

我认为Kubernetes可以从更多这类生成器中受益。已经有针对特定资源的生成器生成器，但这远远达不到我所认为的所需水平。如果能有一些适用于不同类型应用程序的模板那就太好了。或者至少是针对最常见模板的。结合关系数据库、应用层、缓存服务器、消息队列和工作者池可能涵盖了90%以上的所有应用程序所需的复杂性。这种简单的结构能够扩展到巨大的请求量和复杂性。一个可以创建所有内容的模板或生成器，包括Kubernetes资源和代码的组织结构，将会非常有帮助。

对于常见元素的脚手架生成器将是非常好的。需要MySQL数据库？拥有以下命令

kubectl scaffold mysql --generate

来创建有状态集合、服务以及所有必要的其他内容将会大有裨益。然后只需要一个命令将脚手架部署到你的k8s环境中，你只需几个控制台命令就能拥有一个值得生产的数据库。同样也可以为流行的应用程序框架、消息代理以及其他我们能想到的任何东西创建。

也许操作符和Helm图表的组合可以覆盖这一点，但我不认为这样就可以满足需求。这样我们就迫使开发者除了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作为一个生态系统需要满足应用开发者的需求才能真正成功。最终，基础设施是服务于解决用户界面应用代码中客户问题的支持工具。使应用开发者提高生产力是确保平台广泛和成功采用的最佳和最可靠的方式。