在过去的几年中，Kubernetes 已经做到了在分布式领域“如日中天”，本文表达一个 Kubernetes 的欠缺，它距离标准化还很远，标准化的程度依然需要提高。

本文围绕两个事实、三个争议点来说明：

• 事实一：Kubernetes 自身分裂非常严重

• 事实二：Kubernetes 的新特性使用不广范

• 争议点一：标准的 API≠标准的逻辑

• 争议点二：标准化部署容易，标准化运维难

• 争议点三：Kubernetes 的价值观并非“标准化底座”

在 2021 年，Kubernetes 的下一仗可能是提升标准化程度。

事实一：Kubernetes 自身分裂非常严重

在过去的三年中，Kubernetes 基本上是按照“每年四个版本”的速度发布，几个主要的双数版本是下面的样子：

• Kubernetes 1.10 （2018-03）

• Kubernetes 1.12 （2018-09）

• Kubernetes 1.14 （2019-03）

• Kubernetes 1.16 （2019-09）

• Kubernetes 1.18 （2020-03）

• Kubernetes 1.20 （2020-12）

迭代快，代表 Kubernetes 发展快，这显然是好事。但是，Kubernetes 使用方的节奏，远远根本不 Kubernetes 本身的发展速度，更跟不上 Kubernetes 新特征的发布速度。

道理很简单，Kubernetes 的使用方是运行分布式系统的服务器，而非 PC、WorkStation。线上的分布式系统，切换的难度远远高于单机，因此 Kubernetes 新版本应用慢，并非是技术问题，而是效率的问题。

对于 Kubernetes 来说，2018 年初发布的 1.10 版本已经是“比较旧”的，但是对于使用方来说，它其实又很新。

对于大型互联网应用来是，一年能完成一个线上系统的切换，已经是非常快的速度。以 Kubernetes 的发布速度，应用者完全不可能跟不上节奏。最为关键的是，即便能跟上 Kubernetes 的节奏，本身 ROI 也很低。

Kubernetes 1.20 发布时候的标志。

事实二：Kubernetes 的新特性使用不广范

Kubernetes 的新特性使用并不广范。从使用者的角度来说，Kubernetes 眼花缭乱的新特性并不是很吸引人，反而是从技术储备的角度，更需要稳定。

Kubernetes 1.10 发布了存储和网络的两大特性：CSI 的 Beta 版本、CoreDNS 的 Beta 版。事实上，即便应用方。然而，从使用方的角度，使用 CSI 还是 FlexVolumn 都能满足一般的需求，使用 CoreDNS、Kube-dns、SkyDns 其实也只是一个形式上面的区别。

Kubernetes 1.18 的主要特征之一：使用 IngressClass 扩展 Ingress。对于使用者来说，有能用的 Ingress 是关键，而如何实现 Ingress 只是 Kubernetes 自己的事情。

Kubernetes 的新特征很多，但是能带来“应用者效益”并没有那么多，这是新特征使用不广范的根本原因。在 Kubernetes 的发布过程中，Alpha、Beta 的新特征非常多，这也是让很多应用方不敢升级的原因。

争议点一：标准的 API≠标准的逻辑

标准的 API≠标准的逻辑，Kubernetes 的目标是前者，而非后者。

在没有标准的逻辑的情况下，Kubernetes 使用的灵活度非常高，扩展能力非常强。但逻辑上的不标准，依然是困扰使用者的方面。

Kubernetes 的标准化，就如同“定义了键盘的布局，但没有定义每个按键的功能”。

试想，对于“标准化的键盘”来说，如果没有明确说明 QWERTY 的位置，却由“自由化定制”，这个键盘能算标准化的吗？

Kubernetes 各种 Workload（Pod、RC、RS、DS、Job 等）都是统一的形式：

• Write Operations

• Create

• Patch

• Replace

• Delete

• Delete Collection

• Read Operations

• Read

• List

• List All Namespaces

• Watch

• Watch List

• Watch List All Namespaces

• Status Operations

• Patch Status

• Read Status

• Replace Status

API 是相同的，里面的参数不相同，形式上是标准的，但里面能自定义的范畴很广泛。过于灵活的扩展性，本身也是降低了 Kubernetes 的标准化程度。

一个显而易见的事实就是，即便不考虑 Kubernetes 的多版本，在一个版本的 Kubernetes，由于扩展方法不同，使用的方法也不同。

争议点二：标准化部署容易，标准化运维难

标准化 DevOps 的全流程，并不是一个简单的事情，对于 Kubernetes 也不例外。标准化部署容易，标准化运维难的情况，已经广泛性的难题。

在任何一个体系中，完成 Relase、Deploy 只是部署阶段，完成 Operate、Monitor 才是完全的流程。

对于 Kubernetes，Helm 可以帮助一些“应用”完成标准化的安装，但周期更长的运维阶段，却是无定义的。

争议点三：Kubernetes 的价值观并非“标准化底座”

Kubernetes 的价值观并非“标准化底座”。“是否标准”如何认定？可以参考 Window 的发行版、Linux 的发行版的使用方式。Window 一向以标准性、兼容性著称，Linux 虽然标准化不如 Windows，但是 Deb、RPM 终究是相对标准的地方。

与之相比，Kubernetes 甚至没有将“标准化”列为主要特征。一个简单的事实就是，虽然在 Kubernetes 的不同版本中，应用都可以通过 yaml 来安装，但 yaml 的内容却常常需要是不同的。

在官网上面，Kubernetes 的核心价值观很清楚：可伸缩性（Planet Scale）、柔性（Never Outgrow）、各处运行（Run Anywhere），这里面却没有提到兼容性。

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

Planet Scale

Designed on the same principles that allows Google to run billions of containers a week, Kubernetes can scale without increasing your ops team.

Never Outgrow

Whether testing locally or running a global enterprise, Kubernetes flexibility grows with you to deliver your applications consistently and easily no matter how complex your need is.

Run K8s Anywhere

Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.

总结

对于发展期的 Kubernetes，在深度上提升品质，在广度上扩大场景，依然很重要。“标准化”可能并非 Kubernetes 的主要目标，但是“标准化”也是一个需要提上日程的事情。否则 Kubernetes 的使用者对于新版本、新特性的使用，可能并不会非常积极。

在 2021 年，Kubernetes 标准化程度仍需要提高，这可能也是 Kubernetes 下一阶段的“大仗”。

直到某一天，在 Kubernetes 的安装应用的时候，可以不关心 Kubernetes 的版本，可以不关心 Kubernetes 上面组件，这才是 Kubernetes 的标准化。