Kubernetes in 2020: 让我们忘记Kubernetes吧！

01

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

02

直到Kubernetes 的出现改变了这一切。与 Docker 一样，从一开始Kubernetes就拥有极好的架构基础。在它的逐步成长演进过程中，Mesos/Marathon的先天不足逐渐显露，并且慢慢被推至边缘地带，Docker 也渐渐地回到了它应有的位置——成为软件行业无数层级抽象中的一环。Docker在 Linux Kernel 之上，Kubernetes 之下，默默工作，只有在出问题时才会被人们想起。Kubernetes则成了新的核心。 而过去一年，Kubernets 也在逐渐成熟，性能更好，功能更完善，一切都在向着更稳定的方向迈进。这也是 Docker 走过的路，历史总是惊人的相似。我们永远需要一个 Platform, 这个 Platform 究竟是谁不那么重要，而且是不断变化的。因为 Platform 的稳定，它很容易被遗忘，因为我们总在思考更高层级的东西。在这整个链条中，我们知道了起点是二进制，终点是人的需求，中间的路，当下我们走到了 Kubernetes 这里。那么 Kubernetes 的上面是什么？这可能是我们在今后的一年或者很多年里探索的答案。

03

过年的一年我们已经得到了很多零碎的拼图: 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, 来保证能尽量自动化地检测产品的质量；我们还需要蓝绿发布，滚动更新，自动的故障恢复...等等。

04

即使这其中的每一步都有了优质的候选技术，将他们真正地串联起来成为真正的 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 的上方站稳了脚跟。

05

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, 却未能发展出一个合适的替代品。失去功能，会失去很多。而失去简洁，则意味着失去一切。当然，这些尝试以及未来的可能的尝试仍然是非常值得鼓励的。

总的来说，过去的2019年，我们开始关注 Kubernetes 之上的东西，对 Kubernetes 本身的注意力则越来越少，新的一年更是如此。GitOps + Service Mesh + Application 在某种程度上代表了 Kubernetes 的上一层，也许他们意味着全部，也许他们意味着错误，毕竟，它们还没有演进成一个确定的词。往前看，可以肯定的是，Kubernetes 仍在默默地支持着上述这些技术名词，是所有这些技术概念的底座。在即将功成名就之际，留下了 kubebuilder 这个强大的建造者，这也在某种程度上减轻了上层技术的分裂，给了我们在新的一年里往更高层级的抽象迈进的坚实基础。

毕竟，万物基于CRD。