Kubernetes 是一个“数据库”吗？

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

最近，Kubernetes 社区里有一个关于“Kubernetes is the new database”的论述，引发了不少人的关注。固然，这个论述更确切的含义，指的是 Kubernetes 项目自己的工做原理相似于数据库，而不是说你应该把 Kubernetes 当数据库用。

粗看起来，这个 “Kubernetes 是一个数据库” 的论述仍是比较匪夷所思的。毕竟咱们日常所说的 Kubernetes 的工做原理，好比控制器模式、声明式 API 等等，好像跟“数据库”这个东西并无什么直接关系。但实际上，这个论述背后却有着其很是本质的含义。这里的原因，得从 Kubernetes 项目里一个最基础的理论谈起。

Kubernetes 声明式应用管理理论基础

---

在咱们讨论 Kubernetes 的时候，每每会提到这样一个概念，叫作“声明式应用管理”。实际上，这也是 Kubernetes 项目跟其余全部基础设施项目都不同的一个设计，是 Kubernetes 所独有的一个能力，那么，你有没有思考过，声明式应用管理在 Kubernetes 中具体的表现究竟是什么呢？

1. 声明式应用管理不只仅是“声明式风格的 API”

---

若是咱们回顾一下 Kubernetes 的核心工做原理，咱们其实就不难发现这样一个事实：Kubernetes 里面的绝大多数功能，不管是 kubelet 执行容器、kube-proxy 执行 iptables 规则，仍是 kube-scheduler 进行 Pod 调度，以及 Deployment 管理 ReplicaSet 的过程等等，其实从整体设计上都是在遵循着咱们常常强调过的“控制器”模式来进行的。即：用户经过 YAML 文件等方式来表达他所想要的指望状态也就是终态（不管是网络、仍是存储），而后 Kubernetes 的各类组件就会让整个集群的状态跟用户声明的终态逼近，最终达成二者的彻底一致。这个实际状态逐渐向指望状态逼近的过程，就叫作 reconcile（调谐）。而一样的原理，也正是 Operator 和自定义 Controller 的核心工做方式。

这种经过声明式描述文件，以驱动控制器执行 reconcile 逼近两个状态的工做形态，正是声明式应用管理最直观的体现。须要注意的是，这个过程其实包括了两层含义：

• 声明式描述的指望状态。这个描述必须是严格意义上使用者想要的最终状态，若是你在这个描述里面填写的是某个中间状态，或者你但愿动态的调整这个指望状态，都会破坏这个声明式语义的准确执行；
• 基于 reconcile 的状态逼近过程。Reconcile 过程的存在，确保了系统状态与终态保持一致的理论正确性。 确切地说，Reconcile 过程不停的执行“检查 -> Diff -> 执行”的循环，才使得系统可以始终对系统自己状态与终态直接的差别并可以采起必要的行动。而相比之下，仅仅拥有声明式的描述是不充分的。这个道理很容易理解，你第一次提交这个描述时系统达成了你想要的指望状态，并不能表明、也不能保证一个小时后的状况也是如此。不少人会搞混“声明式应用管理”和“声明式风格的 API” ，其实就是对 Reconcile 必要性没有正确的认识。

你也许会比较好奇，采用这种声明式应用管理体系，对于 Kubernetes 来讲有什么好处呢？

2. 声明式应用管理的本质：Infrastructure as Data

---

实际上，声明式应用管理体系背后的理论基础，是一种叫作 Infrastructure as Data （IaD）的思想。这种思想认为，基础设施的管理不该该耦合于某种编程语言或者配置方式，而应该是纯粹的、格式化的、系统可读的数据，而且这些数据可以完整的表征使用者所指望的系统状态。

注：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 上。更重要的是，相比于专有的、命令式的 API 或者 SDK，以 YAML 为载体的声明式数据可以更简单的完成对底层实现的屏蔽，从而更容易对接和集成现有的基础设施能力，这其实也是 Kubernetes 生态可以以惊人的速度蓬勃发展到今天的一个秘密武器：IaD 思想带来的声明式 API 与控制器模式，让整个社区更愿意为 Kubernetes 编写插件和对接各类能力，而且这些插件和能力的通用性和可移植性也很是高，这是其它项目好比 Mesos 和 OpenStack 所可望不可即的。能够说，IaD 正是 Kubernetes 可以达成 “The Platform for Platform” 这个目标的核心战斗力所在。

说到这里，你们估计也就明白了：这种 IaD 设计中的 Data 具体表现出来，其实就是声明式的 Kubernetes API 对象；而 Kubernetes 中的控制循环，则是确保系统自己可以始终跟这些 Data 所描述的状态永远保持一致。从这一点上来讲，Kubernetes 本质上实际上是一个以数据（Data）来表达系统的设定值、经过控制器（Controller）的动做来让系统维持在设定值的调谐系统。

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

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

是否是感受豁然开朗了呢？

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

好比，今天咱们在使用 Kubernetes 的时候之因此要写那么多 YAML 文件，实际上是由于咱们须要经过一种方式把 Data 提交给 Kubernetes 这个控制系统。而在这个过程当中，YAML 只是一种为了让人类可以格式化的编写 Data 的一个载体。若是作一个类比，那么 YAML 就像咱们小时候做业本里的“田字格”，而“田字格”里写的那些文字，才是 Kubernetes 真正关心的 Data 和整个系统运转的核心。

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

YAML 工程师？不，你是数据库工程师！

---

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

而从这个角度来说，Kubernetes 为你暴露出来的各类 API 对象，实际上就是一张张预先定义好 Schema 的表（Table）。而咱们绞尽脑汁编写出的那些 YAML 文件，其实就是对这些表中的数据（Data）进行的增删改查（CURD）。而 YAML 这个工具自己，则比如 SQL 同样是一个帮助你对数据库中的数据进行操做的工具和载体。而惟一跟传统数据库不太同样的是，Kubernetes 在拿到这些数据以后，并不以把这些数据持久化起来为目的，而是但愿经过这些数据来驱动 Controller 执行某些操做，从而将整个系统的状态逐步调整为跟数据中声明的终态一致，这就回到咱们前面所说的“控制理论”部分了。

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

Kubernetes 项目的“视图层”

---

正如前文所述，若是你从一个“数据库”的角度从新审视 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 上。

1. 简化复杂的数据操做（简化 SQL ）

通过抽象后产生的视图层对象，不只在 UI 上须要更加简单，还须要能够定义和管理很是复杂的底层 Kubernetes 资源拓扑，从而下降用户管理 Kubernetes 应用的复杂度和心智负担。

1. 保护底层数据表

研发和运维直接操做的是视图层对象，因此底层的 Kubernetes 原始对象是被保护起来的。这使得这些 Kubernetes 的原始对象能够在用户无感的状况下进行任意变动和升级。

1. 复用数据操做（复用 SQL）

因为视图层对象与底层基础设施是彻底解耦的，因此一个经过视图层声明的应用或者运维能力能够在任意 Kubernetes 集群漂移，而没必要担忧这些集群支持的能力是否是有差别。

1. 视图依然是表，支持标准的表操做

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 视图层依赖库，是来自 Crossplane 团队的 oam-kubernetes-runtime：https://github.com/crossplane/oam-kubernetes-runtime。

总结

---

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

在过去的 5 年里，Kubernetes 项目的巨大成功，其实是基础设施能力（好比网络、存储、容器）在声明式 API 下逐步标准化和统一化的一个过程，而随着 OAM 等 Kubernetes 应用层技术的逐步普及，咱们已经看见一个标准化应用层生态正在付出水面。愈来愈多的团队正在尝试经过更加用户友好的数据视图层，对最终用户暴露出喜闻乐见的 API，同时对基础设施工程师提供出更增强大的横向连通与模块化的平台能力。

与此同时，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 将共同出席并作关于标准化定义应用与基础设施的重要主题演讲。

在本次 Crossplane Community Day 上，你将了解到 OAM 社区同 Crossplane 项目正在展开的深度技术合做，以及世界各地的平台构建者如何经过 OAM 和 Crossplane 来配置和管理面向复杂环境的应用程序、基础架构与云服务。

在阿里巴巴云原生公众号后台回复复关键字 crossplane，或点击连接直接得到线上峰会参与方式。

招人啦！

---

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

• 工做年限：建议 P7 三年起，P8 五年起，具体看实际能力；
• 工做地点：国内：北京，杭州，深圳；
• 岗位包含：架构师、技术专家、全栈工程师等。

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

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”