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

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

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

有人说，容器本质也是一项隔离技术，他很好的解决了他的前任-虚拟化未解决的问题：运行环境启动速度慢、资源利用率低，而容器技术的两个核心概念，Namespace 和 Cgroup，恰到好处了解决了这两个难题。Namespace 是看起来是隔离的技术，替代了 Hypervise 和 GuestOS，在原本在两个 OS 上的运行环境演进成一个，运行环境更加轻量化、启动快，Cgroup 则是用起来是隔离的技术，限制了一个进程只能消耗整台机器的部分 CPU 和内存。

当然，容器技术之所以能流行，也和他提供了标准化的软件开发交付物 - 容器镜像，不无关系，基于容器镜像，使得持续交付这件事能够真正落地。

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

难用在哪？

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

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

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

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

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

• 迁移复杂：将现有的应用程序迁移到 K8s 比较复杂，在很多情况下，必须重构特定组件或整个架构，并且需要使用云原生原理重构应用程序。

• 运维复杂：K8s 的声明式 API 颠覆了传统的过程式运维模式，声明式 API 对应的是面向终态的运维模式。而随着 K8s 集群规模的增长，运维难度也会呈线性增长，呈现在集群管理、应用发布、监控、日志等多个环节，集群稳定性将面临极高的挑战。

是否还有别的解法？

技术总有双面性，容器革新了云计算的基础设施，成为了新的计算界面。 而 Kubernetes 则搭建了一个统一的基础设施抽象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过去我们不得不关注的基础设施概念，使得我们能够基于 Kubernetes 方便地构建出任何我们想要的垂直业务系统而无需关心任何基础设施层的细节。这正是 Kubernetes 被称为云计算界的 Linux 以及 “Platform for Platforms” 的根本原因。

但直接上手操作 Kubernetes 是否是我们应用容器技术的唯一选择呢？答案是否定的。在容器技术的演进过程中，我们也发现了不少能够降低容器编排门槛的开源项目和商业化产品，接下来，我们将从双手的解放程度由低到高，一一介绍。

围绕 Kubernetes 生态的开源工具

OAM/KubeVela 是托管在 CNCF 中的开源项目，旨在降低 K8s 在应用开发和运维上的复杂性，最初由阿里云和微软云联合发起。

KubeVela 作为开放应用架构模型 OAM 的标准实现，与底层基础设施和无关、原生可扩展，而且最重要的是它完全以应用为中心。在 KubeVela 中，“应用”被设计为整个平台的「一等公民」。应用团队只需要围绕组件、运维特征、工作流等几个跨平台、跨环境的上层抽象来进行应用的交付与管理，无需关注任何基础设施细节和差异性；平台管理员则可以随时以 IaC 的方式配置平台支持的组件类型和运维能力集等特性，以便适配任何应用托管场景。

KubeVela 是完全基于 K8s 构建的，具备天然的被集成能力和普适性，天然透出 K8s 及其生态的所有能力，而不是往上叠加抽象。因此 KubeVela 适用于那些具备一定的 K8s 平台开发和运维能力，同时希望能够使用到全套 K8s 能力，不断扩展平台能力的技术团队。

容器已经从一项隔离技术演进成一个生态，KubeVela 这类可以极大降低 K8s 使用复杂度的开源工具，会逐步释放其生命力，使开发人员无需成为 K8s 专家即可享受到云原生带来的高效与便捷。

项目地址：https://github.com/oam-dev/kubevela

sealer 是一款开源的分布式应用打包交付运行的方案，极大的简化了容器项目的交付复杂性和一致性问题。sealer 构建出来的产物可称之为"集群镜像"，并内嵌了 K8s，该"集群镜像"可以 push 到 registry 中共享给其他用户使用，也可以在官方仓库中找到非常通用的分布式软件直接使用。

交付是容器生态的另一个难题，面临着依赖复杂、一致性的问题，尤其是工业级的 Kubernetes 交付项目，交付周期变长、交付质量要求高，sealer 非常适合于软件开发商、ISV 等性质的企业，可将部署时间缩短至小时级别。

项目地址：https://github.com/alibaba/sealer

开放、标准化的企业级 Kubernetes 服务

大部分云厂商提供了 Kubernetes as a Service 的容器平台能力，比如 AWS EKS 和阿里云的 ACK，可以大幅简化 K8s 集群的部署、运维、网络存储、安全管理等能力，提供了通过 CNCF 标准化认证的 K8s 服务，可以满足几乎全场景的工作负载需求，并提供了丰富的扩展和定制能力。此外，大部分云厂商会基于基础版，在上层做不同程度的封装，来适配不同企业背景和不同场景下的需求，以提供发行版和 Pro 版，例如阿里云的 ACK Pro 就提供了托管 master 和全托管节点池的能力，将容器集群的最佳实践和全栈优化作为内置服务提供给企业。

从现有用户规模来看，这是大部分互联网企业落地容器技术的主流选择。

向 Serverless 演进的 Kubernetes 服务

相对于标准化的容器服务，众多云厂商也将容器和 Serverless 做进一步的融合，提出了 Serverless 容器服务的概念，例如阿里云的 Serverless 容器服务 ASK、Google GKE 的 AutoPilot，以免运维的方式降低了客户在 K8s 节点和集群上的操作复杂度，同时，仍然可以通过 K8s 命令行和 API 来部署容器应用，充分利用了 K8s 的编排能力，此外，无需购买服务器即可直接部署容器应用，并且根据应用配置的 CPU 和内存资源量进行按需付费。

这类服务非常善于处理一些 Job 类的任务，例如 AI 领域的算法模型训练，同时拥有在 K8s 环境下比较一致的开发体验，是容器服务生态非常好的补充。

容器和 Serverless 技术加持的新一代 PaaS 服务

企业级市场的需求总是分层的、多样化的，这和技术人才的分布紧密相关，并不是每家企业都能建立一个技术实力足够强的团队，尤其是在非北上广深的城市，并且落地一项新技术时，总是分阶段规划的，这就给更多的产品形态孕育了市场空间。

K8s 虽然提供了容器应用的全生命周期管理，但是太丰富、太复杂、太灵活，这既是一种优势，有时候也是一种劣势。尤其是对于习惯了在虚拟机时代，以应用为视角来管理应用的研发运维人员而言，即便像 AWS EKS、阿里云 ASK 等已经在一定程度上降低了 K8s 的操作复杂度，他们仍然希望通过某种方式，可以进一步降低容器技术的使用门槛。

容器和 K8s 并非一定要捆绑使用，在一些新型的 PaaS 服务中，例如阿里云的 Serverless 应用引擎（SAE）和 Google Cloud Run，底层将虚拟化技术改造成容器技术，充分利用了容器的隔离技术，来提升启动时间和资源利用率，而在应用管理层，则保留了原有的微服务应用的管理范式，不必动用庞大而复杂的 K8s 来管理应用。

此外，底层计算资源池化后，其天然的 Serverless 属性使得用户不必再单独购买和持续保有服务器，而是按 CPU 和内存资源量来配置所需的计算资源，让容器 + Serverless + PaaS 得以合三为一，使得技术先进性、资源利用率优化、不变的开发运维体验可以融合在一起。因此，相比于本文中的其他方案，这类方案的特色是提供了 PaaS 体验，让新技术落地更加平稳。

大部分传统业、一些技术能力偏向于业务层的互联网企业、和一些不希望因受制于后端而影响业务快递迭代的创业公司，基本都会倾向于 PaaS 形态的产品，抛开企业属性，PaaS 类的服务在处理以下场景更具交付优势：

• 上线了一个新的项目，想快速验证，不要出故障，同时控制人力的投入成本；

• 业务体量上升快，用户越来越多，业务稳定性有点 hold 不住，新版本发布、线上应用管理等环节开始有点畏手畏脚，但技术储备还无法及时应对当前变化；

• 决定要把原有的单体架构升级成微服务架构，但由于团队缺少微服务专家，评估完项目发现升级风险比较高。

适合的才是最好的

需求的越多，投入的也会越多，这是更古不变的道理。在我们决定引入容器技术后，使用 K8s 之前，需要想清楚为什么需要 K8s。

如果我们希望充分利用 K8s 的全套能力，并且团队具备一定的技术储备，那么 KubeVela 是理想的开源选型，sealer 还能帮助我们降低交付复杂度；如果希望将 K8s 上层不同程度的封装工作交给云厂商来处理，以更高效的适配不同业务场景下的需求，那么云厂商提供的商业化的容器服务是不错的选择。

但又如果我们的应用并没有那么复杂，只是朴素的希望简化应用生命周期管理和底层基础设施，保障业务的高可用，并专注在业务开发上，那么可能就不需要使用 K8s 来编排容器应用了，毕竟 K8s 是源自 Google 的 Borg，他是用来管理 Google 海量的容器应用的。

参考文章：

《云计算的前世今生》，刘超

《灵活、高效的云原生集群管理经验：用 K8s 管理 K8s》，淮右、临石

《复杂性会成为 Kubernetes 的“致命伤”吗？》，赵钰莹

《Simplifying Kubernetes For Developers》，Rishidot Research

《KubeVela 正式开源：一个高可扩展的云原生应用平台与核心引擎》，OAM 项目维护者

《KubeVela 1.0 ：开启可编程式应用平台的未来》，OAM 项目维护者

作者：望宸，汤志敏、溪洋对本文亦有贡献