无处不在的 Kubernetes，难用的问题解决了吗？

作者：望宸、木环、溪洋 等

容器本质是一项隔离技术，很好的解决了他的前任 - 虚拟化未解决的问题：运行环境启动速度慢、资源利用率低，而容器技术的两个核心概念，Namespace 和 Cgroup，恰到好处的解决了这两个难题。

Namespace 作为看起来是隔离的技术，替代了 Hypervise 和 GuestOS，在原本在两个 OS 上的运行环境演进成一个，运行环境更加轻量化、启动快，Cgroup 则被作为用起来是隔离的技术，限制了一个进程只能消耗整台机器的部分 CPU 和内存。

当然，容器技术之所以能流行，更因为他提供了标准化的软件开发交付物 - 容器镜像。基于容器镜像，持续交付这件事才能够真正落地。

我们还能罗列出许多使用容器技术的理由，这里就不再一一赘述。

同时，云计算解决了基础资源层的弹性伸缩，却没有解决 PaaS 层应用随基础资源层弹性伸缩而带来的批量、快速部署问题。于是，容器编排系统应运而生。

从第三方的调研数据看，容器和 Kubernetes 已经成为云原生时代主流的选择，但实际落地的时候，却陷入了困境。我们尝试去总结了一些共通点，以及应对方案，也许能为正在落地容器技术的企业提供一些参考。

01 难用在哪？

容器和 Kubernetes 的先进性毋庸置疑，但当大量的企业在开始拥抱容器编排领域的事实标准 Kubernetes 时，却陷入了困境。“K8s 就像一把双刃剑，既是最佳的容器编排技术，同时也存在相当高的复杂性和应用的高门槛，这个过程中往往会导致一些常见性错误”。就连 Kubernetes 的创立者和核心推动者 Google 本身都承认这个问题。

一次采访中，阿里巴巴高级技术专家张磊分析了 Kubernetes 的本质，他指出，“Kubernetes 本身是一个分布式系统而不是一个简单的 SDK 或者编程框架，这本身已经将其复杂度提升到了系统级分布式开源项目的位置。此外，Kubernetes 第一次将声明式 API 的思想在开源基础设施领域普及开来，并以此为基础提出了一系列诸如容器设计模式和控制器模型等使用范式，这些具有一定先进性和前瞻性的设计也使得 Kubernetes 项目被大众接受时会存在一定的学习周期。”

我们大致总结了 Kubernetes 的 4 大复杂性。

1、认知复杂：他和原有的后端研发体系不同，延伸出一套全新的理论，并提供了一系列全新的技术概念，并且这些概念，例如 Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，主要是面向平台研发团队而非应用开发者设计，提供很多强大灵活的能力。但是，这不仅带来了陡峭的学习曲线，影响了应用开发者的使用体验，甚至在很多情况下理解不当还会引发错误操作，乃至生产故障。

2、开发复杂：K8s 使用声明式方法来编排和管理容器。为了实现这一点，需要配置一个 YAML 文件，但再复杂的应用程序中，引入新环节影响了开发者的生产力和敏捷性。此外，缺乏内置的编程模型，开发者需要依赖第三方库来处理程序间的依赖关系，这些都会影响到开发效率，并增加不必要的 DevOps 开销。

3、迁移复杂：将现有的应用程序迁移到 K8s 比较复杂，尤其是非微服务架构，在很多情况下，必须重构特定组件或整个架构，并且需要使用云原生原理重构应用程序，例如状态依赖，如写本地目