应用管理的两大难题
今天我们主要讨论这两个方面的挑战：
-
对应用研发而言，K8s API 针对简单应用过于复杂，针对复杂应用难以上手；
-
对应用运维而言，K8s 的扩展能力难以管理；K8s 原生的 API 没有对云资源全部涵盖。
总体而言，我们面临的挑战就是：如何基于 K8s 提供真正意义上的应用管理平台，让研发和运维只需关注到应用本身。
研发对应用管理的诉求
1. K8s all in one 的 YAML 文件
让我们来看一下这样一个 K8s 的 yaml 文件，这个 yaml 文件已经是被简化过的，但是我们可以看到它仍然还是比较长。
面对这样一个广受“复杂”诟病的 YAML 文件，我相信大家都会忍不住想该怎么简化。
自上而下，我们大致把它们分为三块：
-
一块是扩缩容、滚动升级相关的参数，这一块应该是应用运维的同学比较关心的；
-
中间一块是镜像、端口、启动参数相关的，这一块应该是开发的同学比较关心的；
-
最后一块大家可能根本看不懂，通常情况下也不太需要明白，可以把它们理解为 K8s 平台层的同学需要关心的。
看到这样一个 yaml 文件，我们很容易想到，只要把里面的字段封装一下，把该暴露的暴露出来就好了。确实，我们内部就有 PaaS 平台这么做。
2. 只透出部分字段：简单却能力不足
内部的某个 PaaS 平台精心挑选了部分字段，并做了一个漂亮的前端界面给用户，只透出给用户 5 个左右的字段，大大降低了用户理解 K8s 的心智负担。然后底层实现用类似模板的方式把用户这五个字段渲染出来一个完整的 yaml 文件。
突出的字段大概如下图所示：
不得不说这种方式是非常有效的，针对简单无状态的应用，精简 API 可以大大降低 K8s 的门槛，快速并且高效的对接用户，PaaS 平台也顺利让大家使用了起来。同时，我也从一些技术分享中了解到许多其他公司也是用这种类似的方式简化的 K8s API。
但是当用户的业务开始大规模对接以后，我们就会自然而然遇到有状态的复杂应用，用户就会开始抱怨 PaaS 平台能力不够了。比如我们的 Zookeeper 多实例选主、主从切换这些逻辑，在这五个字段里就很难展开了。
归根结底就是屏蔽大量字段的方式会限制基础设施本身的能力演进，但是 K8s 的能力是非常强大而灵活的。我们不可能为了简化而放弃掉 K8s 强大的能力。
就比如当前这个例子，我们很容易想到，针对复杂有状态的应用，应该通过 K8s 里面的 CRD 和 Operator 来解决。
3. CRD+Operator: K8s 扩展能力强大却难以上手
确实，我们内部对接复杂应用云原生化的时候，也推荐他们编写 Operator，但是经常出现这样一段对话。
中间件的工程师跟我们说，我这有个 Zookeeper 该用哪种 K8s 的 Workload 接入啊？我们想了想，K8s 设计如此精妙，自然没有解决不了的问题，于是我们推荐他们使用 Operator。他们就懵了，说你们搞云原生的这几年造新词的能力绝对一流，之前都没听说过。
想想也是，业务方理解这些新概念不难，但是真的要自己去上手实现，还是非常困难的。我们自然也觉得业务方更应该专注于他们的业务本身，于是我们不得不帮他们一起写。
可以看到，我们及需一个统一的模型去解决研发对应用管理的诉求。