CNCF 官方大使张磊：Kubernetes 是一个“数据库”吗？

CNCF 官方大使张磊：Kubernetes 是一个“数据库”吗？

作者 | 张磊，阿里云高级技术专家、CNCF 官方大使，CNCF 应用交付领域 co-chair，Kubernetes 项目资深维护者

最近，Kubernetes 社区里有一个关于“Kubernetes is the new database”的论述，引起了很多人的关注。当然，这个论述更确切的含义，指的是 Kubernetes 项目本身的工作原理类似于数据库，而不是说你应该把 Kubernetes 当数据库用。

注：Infrastructure as Data  有时也被称作 Configuration as Data，背后的意思是一样的。

而这样做的好处就在于，任何时候我想对基础设施做操作，最终都等价于对这些数据的“增、删、改、查”。而更重要的是，我对这些数据进行“增、删、改、查”的方式，与这个基础设施本身是没有任何关系的。所以说，我跟一个基础设施交互的过程，不会被绑定在某种编程语言、某种远程调用协议、或者某种 SDK 上。只要我能够生成对应格式的“数据”，我就能够“天马行空”地使用任何我喜欢的方式来完成对基础设施的操作。

这种好处具体体现在 Kubernetes 上，就是如果我想在 Kubernetes 上做任何操作，我只需要提交一个 YAML 文件，然后对这个 YAML 文件进行增删改查即可。而不是必须使用 Kubernetes 项目的 Restful API 或者 SDK 。这个 YAML 文件里的内容，其实就是 Kubernetes 这个 IaD 系统对应的 Data（数据）。

所以说，Kubernetes 从诞生起就把它的所有功能都定义成了所谓的“API 对象”，其实就是定义成了一份一份的 Data。这样，Kubernetes 使用者就可以通过对这些 Data 进行增删改查来达成自己想要的目标，而不是被绑定在某种具体的语言或者 SDK 上。

可以说，IaD 正是 Kubernetes 能够达成 “The Platform for Platform” 这个目标的核心战斗力所在。

等一下，这个“让系统维持在设定值”的理论，听起来好像有点耳熟？

实际上，Kubernetes 背后的这门基础课，可能绝大多数工科背景的读者都是学过的，它叫做《控制理论》。

是不是感觉豁然开朗了呢？

在明白了 Kubernetes 的这个本质之后，我们回过头来再看原本一些比较难以理解的设定，可能会更容易体会到一些本质的东西。

比如，今天我们在使用 Kubernetes 的时候之所以要写那么多 YAML 文件，其实是因为我们需要通过一种方式把 Data 提交给 Kubernetes 这个控制系统。而在这个过程中，YAML 只是一种为了让人类能够格式化的编写 Data 的一个载体。如果做一个类比，那么 YAML 就像我们小时候作业本里的“田字格”，而“田字格”里写的那些文字，才是 Kubernetes 真正关心的 Data 和整个系统运转的核心。

细心的读者此时应该已经想到了，既然 Kubernetes 需要处理这些 Data，那么 Data 本身不是也应该有一个固定的“格式”这样 Kubernetes 才能解析它们呢？没错，这里的格式在 Kubernetes 中就叫做 API 对象的 Schema。如果你经常编写自定义 Controller 的话，可能就会对这个 Schema 的体感比较深刻：CRD 就是一个专门用来定义 Schema 的一个特殊的 API 对象。

上述 Kubernetes 的 IaD 的本质，决定了它的工作原理其实更类似一个“数据库”，而不像传统意义上的分布式系统。这个差异，也是导致 Kubernetes 学习成本比较陡峭的一个根本性原因。

也正是由于  Kubernetes 这样整套体系都围绕着“数据”这个一等公民运转的设定，才使得“编写和操作 YAML文件”成为了 Kubernetes 工程师的几乎唯一的日常工作。不过，在理解了本文今天介绍的 IaD 的思想之后，你其实大可以把自己比作一个“数据库工程师”了，而且这个 TItle 确实要比“YAML 工程师”更加贴切一些。

正如前文所述，如果你从一个“数据库”的角度重新审视 Kubernetes 设计的话，就不难发现 Kubernetes 的很多设计背后其实有着非常精妙的思想。比如：

数据模型 -  Kubernetes 的各种 API 对象与 CRD 机制数据拦截校验和修改机制 - Kubernetes Admission Hook数据驱动机制 - Kubernetes Controller/Operator数据监听变更与索引机制 - Kubernetes 的 Informer 机制……

另外一方面，随着 Kubernetes 基础设施越来越复杂，第三方插件与能力越来越多，社区的维护者们也发现 Kubernetes 这个“数据库”内置的“数据表”无论从规模还是复杂度上，都正在迎来爆炸式的增长。所以  Kubernetes 社区很早就在讨论如何给 Kubernetes  设计出一个“数据视图（View）”出来，即：

而这样一个构建在 Kubernetes 内置 API 资源之上的“视图层”给 Kubernetes 使用者带来的好处，跟数据库中的“视图”是非常类似的，比如：

1. 简化和更改数据格式和表示

Kubernetes 的视图层，需要能够给研发和运维暴露更简洁的、经过抽象后的应用层 API 对象，而不是原始的基础设施层 API 对象。而一个视图层对象具体如何定义，自由度应该完全在用户手中，不需要拘束在底层 Kubernetes 内置对象的 Schema 上。

2. 简化复杂的数据操作（简化 SQL ）

经过抽象后产生的视图层对象，不仅在 UI 上需要更加简单，还需要可以定义和管理非常复杂的底层 Kubernetes 资源拓扑，从而降低用户管理 Kubernetes 应用的复杂度和心智负担。

3. 保护底层数据表

研发和运维直接操作的是视图层对象，所以底层的 Kubernetes 原始对象是被保护起来的。这使得这些 Kubernetes 的原始对象可以在用户无感的情况下进行任意变更和升级。

4. 复用数据操作（复用 SQL）

5. 视图依然是表，支持标准的表操作

Kubernetes 的视图层对象必须依然是标准的 Kubernetes 对象，这样 Kubernetes 对 API 对象的所有操作和原语对，才会对视图层对象适用。我们不能在 Kubernetes API 模型上引入额外的心智负担。

给 Kubernetes 设置视图层的想法虽然最终没有在 Kubernetes 上游落地，但是却成为了社区中大多数大规模玩家的主流做法。比如 Pinterest 就在 Kubernetes 之上设计了一个 PInterestService 的 CRD 来描述和定义 Pinterest 的应用，这个 CRD 其实就是一个视图层对象。但这个做法对于绝大多数企业来说，还是太过简陋了。要知道，数据的“视图”并不只是数据的简单抽象和翻译，在真正的生产环境中要大规模使用视图层，至少需要解决几个关键问题：

如何定义和管理视图层对象与底层 K8s 对象之间的映射关系？注意这里绝不是简单的一对一映射，一个视图层对象可能会对应多个 K8s 对象；如何对“运维能力”进行建模和抽象？一个真正的应用，绝不只是简单的 Deployment 或者 Operator，它一定是待运行程序与相应的运维能力的有机组合（比如一个容器化应用和它的水平扩展策略）。这些运维能力如何通过在应用定义里体现出来？全定义成 annotation 可行吗？如何管理运维能力同待运行程序之间的绑定关系？如何将这个绑定关系映射成底层 K8s 当中真正的执行关系？如何通过视图层对象标准化的定义云资源，比如一个阿里云的 RDS 实例？……

上述这些问题，正是 Kubernetes 上游最终没能将“视图层”落地的重要原因之一，同时也是诸如  Open Application Model （OAM）这样的 Kubernetes 应用层开源项目主要的关注点。需要指出的是，仅靠一个 OAM 这样一个“规范”是依然不足以解决上述所有问题的，Kubernetes 视图层的建立，必须借助标准的视图层依赖库在实现层予以保证，才能真正在 Kubernetes 中享受到“数据视图”带来的优势和便捷。目前社区中比较强大的 Kubernetes 视图层依赖库，是来自 阿里 团队的 oam-kubernetes-runtime。

Open Application Model （OAM） 项目地址：

https://github.com/oam-dev/spec

oam-kubernetes-runtime 项目地址：

https://github.com/crossplane/oam-kubernetes-runtime

Kubernetes 这个以 IaD 为核心的、类似“数据库”设计，正是这个社区繁荣发展背后的重要理论基础。然而，IaD 的思想本身也是一把双刃剑，它催生出来的蓬勃发展的社区的另一面，是无数个“各自为政”的 Controller/Operator，以及一个通过这些 Controller 拼装出来的、复杂度极高的 Kubernetes 集群。这样的一个生产级别复杂度的 Kubernetes 集群，距离一个真正受研发和运维喜爱的云原生应用管理平台，差距可谓十万八千里。

与此同时，Kubernetes 这个“数据库”其他欠缺的部分，也一定会越来越多的在社区涌现出来。比如今天正在迅速成熟的 Open Policy Agent（OPA）项目，可以认为是“数据拦截校验和修改机制”这一层的不断进化结果。再比如阿里巴巴内部在“万节点”集群中推进的管控链路性能调优工作，其理论基础和实践，跟今天的数据库性能优化，更是有异曲同工之妙的。

如果你有任何关于 IaD 系统想法，非常欢迎钉钉扫码加群同我们交流！

美国时间 2020 年 5 月 27 日，知名复杂环境应用交付与基础设施管理项目 Crossplane 将联合 Open Application Model （OAM）社区共同举办 Crossplane Community Day。

谷歌公司 Kubernetes 项目首席布道师 Kelsey Hightower、阿里云资深技术专家、CNCF TOC 李响与微软杰出工程师、Kubernetes 联合创始人 Brendan Burns 将共同出席并做关于标准化定义应用与基础设施的重要主题演讲。

招人啦！

云原生应用平台团队诚邀 Kubernetes/Serverless/ PaaS 应用交付 领域专家（ P7-P8 ）加盟，一起参与到 OAM 建设中：

• 工作年限：建议 P7 三年起，P8 五年起，具体看实际能力；

• 工作地点：国内：北京，杭州，深圳；

• 岗位包含：架构师、技术专家、全栈工程师等。

简历立刻回复，2~3 周出结果，简历投递：jianbo.sjb AT alibaba-inc.com