Kubernetes会被它厚重的复杂度压垮吗？

Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜，可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题，也给出了建议。作为一个已经在多个云端平台和企业IDC环境落地Kubernetes的团队，我们感同身受文中提到的阵痛期以及对Kubernetes未来的关切。同样希望社区和平台贡献者能看到这些观点，将Kubernetes变得对开发者更加友好，从而让生态更健康，让开发者能把优势资源更多的集中在去发布商业价值的本份上。 思考：服务好应用开发者的重要性
几周之前，我参加了欧洲区的KubeCon并讲了话。这是一次有将近4700人参加的空前的盛会。这让我想起了2014年那次在巴黎的OpenStack峰会。如出一辙的疯狂宣传，供应商的各种秀，以及在主会场的公共区域举行的由开发者组织的大型派对。然而，我感到了这整个场面之后的隐忧：每个和我聊的人不是运维就是SRE（译者：网站可靠性工程师）。我们的应用开发人员在哪里？他们不应该正是这整个复杂的基础架构要服务的人吗？社区真正将有需求的使用者联系起来了吗？进而它让我疑虑：是不是Kubernetes过于复杂了？它会被它厚重的复杂度终结吗？它会跟OpenStack当初一样在2014年后逐渐消失吗？
好吧， 我承认我演的有点过了， 但我要说的是，在我看来这根本不可能发生。Kubernetes有一些优势是OpenStack从来不具备的。首先，Kubernetes已经更具扩展性，因此，所谓能在千万级服务器规模的环境中调度的集群，它能使其梦想成真。其次，三大云供应商（AWS、Azure、Google Cloud）已经开始提供在其之上托管Kubernetes的各种服务（译者：EKS、AKS、GKE）。在短短四年内，Kubernetes已经将自己的地位提高成为云服务商和传统IT基础架构的通用平台。但是，复杂度问题依然让人头疼不已。

大部分开发者没有遇到和Google一样的扩展性问题

开发Kubernetes的初衷是为了解决Google公司在扩展性上面临的复杂度以及各种问题。你可能期望这个基础架构是可自愈的，可以横向扩展的，并能支持申明式编程（即infrastructure as code, 基础设施即代码）。然而，对绝大部分的应用和应用开发者来说并没有这样的世界观。大部分应用要么是在用更加现代和高阶的术语来描述它们所谓的扩展性（比如项目的部署规模和用户量）要么还只是刚开始调研自己的市场定位。
那些完全不会有扩展性问题的应用， 通常不需要系统具备可自愈可横向扩展，来徒增复杂度。只要简单地考虑使用单个节点的数据库服务和应用服务，就能够处理你的业务。而且，如果有人做些常规排错的运维，让它能够保持99.5%的可用性，那就已经满足了很多应用和业务的需求。建一套分布式系统所带来的无谓复杂度，以及在投放市场前所开销的额外时间，都完全不值得去纠结和投入。
对于那些全新的应用，他们最大的风险是在于找不到自己的市场定位。就是说，他们都部署好了但没人用。这些代码最终被丢弃，因为，它做出来了但没人要。这样的情况代表了绝大部分的已经写好的应用。我个人就把职业生涯大量的时间用在了寻找“恰当的代码匹配恰当的功能”。只有当你发现了对的应用场景和功能需求，你才去扩展你的应用。否则就是拔苗助长（译者：出自“premature optimization is the root of all evil”）。
我看到Kubernetes的问题在于，在它上面做一个项目，其初期的认知负荷太高。那堆你需要做和考虑的事阻碍了你快速开始和迭代一个项目。在项目初期，实现需求的效率和迭代速度是非常重要的因素。我看Heroku就有个很好的开发模式。你已经有了个托管的Postgres数据库，你只需要git push把代码部署上去并发布。几乎没什么需要去纠结。它也许不支持无限扩展，也有可能成本比较高，但至少你可以等这些真成了你的痛点之后再去操心。
简而言之， Kubernetes让简单的事变难了，也让难的事变得有可能（出自Tom Wilkie一句用在另个项目上的话）。如果Kubernetes真的要成功，它必须要让项目启动期变得更加简单。它必须要降低应用开发者的认知负荷。如果在某些时候，开发者有需要去学Kubernetes的晦涩概念的细节，那也行。因为项目做大了，每件事都会复杂和有难度。但一个成功的开发平台不会在还没必要的情况下，就把那些决策负担和认知压力放到开发者的面前。这话David Heinemeier Hansson（译者：DHH，Ruby on Rails的作者）在2018年的RailsConf的“JIT Learning" 中讲过。
说到DHH， 这里我想用Rails作为例子。首先我想来探讨的是：为什么Rail那时会那么火？不是因为Ruby的流行（它曾是一个来自日本并不为人知的语言），也不是因为Rails和Ruby曾是服务动态web页面的框架中响应速度最快的。而是因为它大幅提高了开发者的工作效率。当DHH谈如何在15分钟内搭建博客网站的时候[1]，那些动辄要用数周甚至数月才能完成相同事情的Java和.NET开发人员都惊讶不已。开发者使用Rails是因为他们能将新功能更快的发布给用户，这才应该是所有这些应用框架和系统架构的根本目的。
Rails做的另一个了不起的事是，它会为你开发的应用程序提供了一个命令行工具并帮你去生成scaffolds和项目需要的其他组成部分。这就让开发人员的事情变得简单，他们没必要在项目一开始就要去做成吨的决策。应用程序的代码该如何组织，数据模型该放哪， asset pipeline是什么样，怎么做数据库迁移，以及其他很多为你而完成的任务和决策。如果你想一试框架限定外的东西，也行的，但你不是非得在一开始就去考虑。
我想Kubernetes也可以从Rails的这些各种各样的生成器中获得灵感。事实上Kubernetes里已经有了特定资源的生成器，但还远远不及我想要的。如果对不同类型的应用能有相应模板就会很好。哪怕只有个最通用的模板也好。把关系数据库，应用层，缓存服务器，消息队列，以及worker节点池组合到一起，就能把其中的复杂度封装， 从而满足90%或更多应用在开发时的需求。如此简单的一个结构能够横向扩展进而支撑一个难以置信的请求数量和复杂度。一个模板或者生成器就能把所有东西变得开箱即用，还帮你把这些适用于Kubernetes上的资源和代码组织的好好的，对开发者而言这将会非常有帮助。
比如，要是有一个通用元素的Scaffold生成器，事情就会变得很棒。要个MySQL数据库？像这样来个命令就行：

kubectl scaffold mysql --generate

原本创建一个stateful set，service以及其他的必须品都要走段很长的路。现在只要一个简单命令就能在Kubernetes环境里部署一个scaffold，并且，你还能只通过几行命令就能有一个可以直接上生产的数据库。如法炮制，各种流行的应用框架，message brokers，以及其他我们能想到的东西都能被创建出来。
也许operators与Helm Chart的组合就能搞定上面说的，但我觉得这不能算完。总不能强迫开发者还要再去学两个Kubernetes外的东西吧。虽说只是多学一些新语法和装个新的命令行工具，那也是额外费心费力的事。这样的功能应该是Kubernetes的“一等公民”，是Kubernetes拥有“开箱即用”般体验的组成部分。他们要能够通过kubectl就可以用起来。
CNCF项目版图很大而且越来越大

这不是Kubernets特有的问题，而是CNCF项目版图就很巨大。这就使得KubeCon和CNCF的峰会被极度的碎片化。光在峰会的不同场次就有14个宣讲。而作为开发人员，下图这些工具中哪些是我项目需要的呢？ 来看看这张项目版图吧：

好吧，看了也没办法搞清楚。更好的方式, 是把预先就挑好的工具提供给应用开发人员，让他们先按照简便方法走，如果他们能想到去用不同的工具，那更好，但是他们不需要一开始就非要去考虑。CNCF正在激增的复杂度和广度有可能会分散人们聚焦在Kubernetes的注意力也会弱化它作为开发平台的定位。对此我也不知道该怎么说，或者讲得夸张点，仅从我个人角度来看，现在这峰会俨然就是部工具为主角的小电影。试问，你都能把整个职业生涯消耗在去学如何为平台开发新的工具上了，还费什么劲去解决用户的问题？
怎么强调都不够：基础架构只是一个帮助开发者解决真实用户问题的工具。它应该能帮助开发者优化效率和提高发布的能力。在这点上能做得好的开放平台就能胜人一筹。

所需知识

有时，开发者需要对基础架构的各种工具有更深的了解。像大部分AWS上的开发者对那个云上的组件比较熟悉，就跟GCP或Azure上的开发者熟悉他们云上的组件一样。让Kubernetes作为项目的基础架构也许会更有前景，因为开发者只学这一种范式就能把它和项目铺上任何公有云或者私有云。
这点也许就是我们选择Kubernetes的原因，把它作为我们新开发的2.0版云服务的基础架构。可学习曲线是明摆在那儿的，所以我们开发团队还在热身。为了达到目的，我让整个研发团队必读Kubernetes : Up and Running[2]这本书。
我希望学习曲线是相对温和的， 而Kubernetes作为一个生态，要去拥抱开发者的需求才能真正成功。通过提供面向用户的应用来解决客户问题，在这样一个服务过程中，说到底，基础架构只是一个支持型的工具。“激发应用开发者的效率”是最好的也是最明确能让一个平台被广泛使用和接受的正道。
相关链接：

1. https://www.youtube.com/watch?v=Gzj723LkRJY

2. https://www.amazon.com/Kubernetes-Running-Dive-Future-Infrastructure/dp/1491935677

原文链接：https://www.influxdata.com/blog/will-kubernetes-collapse-under-the-weight-of-its-complexity/

Kubernetes入门与进阶实战培训

本次培训内容包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等， 点击了解具体培训内容。

6月22日正式上课，点击阅读原文链接即可报名。