Kubernetes in 2020: Let's Forget About Kubernetes

犹记得 Docker 横空出世的时候，像明星一般，吸引了无数的人去研究它，使用它，推广他。技术的狂热让我们隐隐约约觉得它似乎解决了无数的业内问题，即使它实际上只是适用于单机环境的一个容器实现。没关系，我们有 Mesos / Marathon, 或者其他类似的东西来弥补它的不足, Docker 仍然是我们关注和研究的核心，其他的都是陪衬。

Kubernetes 的出现改变了这一切，与 Docker 一样，从一开始它就拥有了极好的架构基础。在它的逐步成长中，Mesos/Marathon的先天不足逐渐被显露出来，并且逐渐被推至边缘地带，Docker 也渐渐地回到了它应有的位置上，成了软件行业中，无数层级抽象中的一环，在 Linux Kernel 之上，在 Kubernetes 之下，默默工作，只有在出问题时才会被人们想起。Kubernetes 成了新的核心。

而过去一年，我们看着 Kubernets 也在逐渐成熟，性能更好，功能更完善，一切都在向着更稳定的方向迈进，也在紧随着 Docker 走过的路。我们永远需要一个 Platform, 这个 Platform 是谁则是在不断变化的。 因为 Platform 的稳定，所以它应该被遗忘，因为我们在思考更高层级的东西。在这整个链条中，我们知道了起点是二进制，终点是人的需求，中间的路，我们走到了 Kubernetes 这里。那么 Kubernetes 的上面是什么？这可能是我们在今后的一年或者很多年里探索的答案。

过年的一年已经给了我们很多零碎的拼图: ServiceMesh, DevOps, GitOps, Application, Helm, Servrveless, Cloud Native…. 这些名词如雨后春笋般冒了出来，让人眼花撩乱。它们并不能总是解决所有的问题，但却给我们指明了一定的方向。

从代码自动到产品，这一个长久而又清晰的诉求，在 DevOps 提了这么多年的情况下，依然在被呼吁，说明我们仍未达成目标，因为它本身需要的前置条件太多, 我们需要良好的 CI/CD, 能够适配各种 VCS;我们需要简明清晰的语法，来描述出了流水线的 Steps;我们需要统一的 Artifact Storage, 用来存储诸如 Test Coverage Output, Docker Image, Binary…等各种各样的文件;我们需要完善的 Unit Test, Integration Test, 来保证能尽量自动化地检测产品的质量，我们需要蓝绿发布，滚动更新，自动的故障恢复…等等。即使这其中的每一步都有了优质的候选技术，将他们真正地串联起来成为真正的 GitOps, 才是更难的地方。因为成功的 GitOps 也需要达到像 Docker / Kubernetes 那样既是一个稳定的核心，也是一个扩展性良好的平台。而这正是开源社区的弱项，人们更容易被技术的偏好分心而不断 fork 分裂，而不像公司那样能有一个稳定的目标和节奏。Docker 和 Kubernetes 的成功历史都证明，公司 + 开源的模式才是最有效的。期待在新的一年里在此方面能有大的突破。

GitOps 的两端，处于源头的Git 的地位确定无疑，而产品如何描述也是一个我们需要重新考虑的问题。我们从 Monolith走到了 Micro Service, 结果发现带来的问题更多。Micro Service 不是最终的目的，构建于 Service Mesh 之上的 Application 才是。我们把 Monolith 打散成了 Micro Service, 又通过 Service Mesh把他们拼在了一起，变成了 从内到外，纤毫毕现的 Application, 因为我们有了 OpenTracing, 有 Monitor, 有拓扑，像是X光下的人体结构一样清晰。遗憾的是，不管是 Service Mesh 还是 Application, 社区仍未统一好发展的方向。大家都扔处于摸索之中。

Service Mesh 作为一个相当底层的 Building Blocks, 我们既希望它能稳定，性能好，无感知，同时我们也希望它能以一个高层次的蓝图形式展现给用户，让用户能够在需要的时候概览全局，定位问题。这样高的要求，自然不能一蹴而就，Service Mesh 正处于一个相当早期的阶段，标准未定，开发方向分化，过于重量级而让用户无法忽略它存在的成本等等。抛开开源社区本身的局限性以及厂商力量的介入，Service Mesh 本身仍然是在茁壮成长着，并且在 Kubernetes 的上方站稳了脚跟。

Application作为一个更为古老的概念，在 Kubernetes 的语境下需要我们更多的重新思考。我们如何用这个概念来表达出用户的需求？如何尽可能地屏蔽掉底层的细节而让用户不用被迫去学习更多的概念。当 Docker 兴起，用户需要了解 Container, Image, Registry, 当 Kubernetes 兴起，用户需要了解 Deployment, Service, Secret….这其中哪些是必须的？哪些又是不必的呢？过去一年，我们已经见到了无数的工具在尝试在用户面前屏蔽掉像 Deployment/Pod 这样的概念，而代之于一个更为上层的 Application。Helm，Kustomize, Application CRD…都在尝试达成这个目标，却都有各自的缺陷。抑或是 OAM，CNAB, 这样的 Spec, 也不可避免地涉及到厂商的偏向。Service Mesh 难在技术，而 Application 则难在交互。难到在如今众多的想要用 YAML 来表述应用的概念的尝试中，仍然没有能超越 Docker 最初的 compose 语法的简洁性的，不管其初衷是想提供多么强大的特性。Kubernetes 摧毁了 Docker Compose, 却仍然未能发展出一个合适的替代品。 失去功能，失去很多。失去简洁，则失去一切。当然，这些尝试以及未来的可能的尝试仍然是非常值得鼓励的。

总的来说，过去一年，我们开始逐渐关注 Kubernetes 之上的东西，而对 Kubernetes 本身的注意力则越来越少，新的一年更是如此。GitOps + Service Mesh + Application 在某种程度上代表了 Kubernetes 的上一层，也许他们就是全部，也许他们并不对，毕竟，他们还不是一个词。往下看，可以肯定的是，Kubernetes 仍在默默地支持着这些技术名词，在即将功成名就之际，还留下了 kubebuilder 这个强大的建造者，这也在某种程度上也减轻了上层技术的分裂，给了我们在新的一年里往更高层级的抽象迈步时坚实的基础。毕竟，万物基于CRD。