Kubernetes 十年回顾：从云原生走向 AI 时代

采访嘉宾 ｜ 张凯

编辑 ｜ Tina

Kubernetes 是用于管理容器化应用程序的开源平台。它于 2014 年由 Google 发布，并在短短十年内成为业界事实上的容器编排标准。K8s 的普及推动了容器化技术的快速发展，并彻底改变了软件开发和部署的方式。在 Kubernetes 十周年之际，InfoQ 采访了阿里云张凯，回顾 K8s 的发展历程，总结开源项目的得失，展望 K8s 的未来。

采访嘉宾简介：张凯，阿里云资深技术专家，阿里云容器智算方向负责人。多年云计算领域研发经历，深耕云原生技术在企业应用、微服务、AI、大数据、高性能计算等众多场景的落地。带领的团队开拓云原生 AI 领域，创立 Fluid、Kube-Queue、GPUShare、Arena 等多个相关开源项目。

InfoQ：您认为，“云原生”和 “Kubernetes”的出现，给行业带来的意义是什么？

张凯：“云原生”为分布式应用开发者和企业系统更科学、更高效地使用云资源和云服务带来了完整且合理的支撑。不仅提供了系统架构设计的原则和参考，也提供了大量可生产落地的技术实现和最佳实践。

“Kubernetes”是其中最重要的技术之一，它以标准的 API，稳定的分布式核心架构，和灵活的可扩展性，帮助应用轻松获得高弹性、高可用、服务化等加持，并在应用开发者和运维人员之间明确了“接口”和“协议”。

跳出云计算的场景，以容器，Kubernetes 为代表的云原生技术，也让企业看到了以一致架构和技术栈，统一业务应用，大数据，智能/AI 等内部“烟囱”系统的可行技术路径。

InfoQ：这十年里，K8s 技术发展的关键节点您认为是什么样的？

张凯：K8s 的发展过程中，另人兴奋的点很多。我个人印象比较深的有三个关键节点。

第一个是与 Docker Swarm，Mesos 等容器编排调度方案的竞争。抛开 Google 大厂的体量不谈。K8s 之所以能后来居上，并快速形成碾压，还是体现了其在分布式系统架构设计方面的经验，在大规模生产环境下的实践积累，以及在社区中的老道和江湖地位。Swarm 的反击不是不够快，但事后看，Docker 的确在复杂系统架构设计上的功力尚浅。依稀记得 Swarm mode 概念设计提出时的那种割裂感，就让人隐隐觉得一种“力不从心”。

第二个是 K8s 1.7 版本中 Custome Resource Definition （CRD）机制的推出。从更早的 Third Party Resource（TPR）演进到 CRD，K8s 从很早就准备好了一个巧妙的可扩展架构。通过一种“状态”-“观察”-“调整”的简单循环，几乎满足了管控各类对象的生命周期的所有需求。K8s 最核心的架构只需做好、做稳交互接口管理（API server），全局状态管理（ETCD）和资源调度管理（Scheduler）。

通过 CRD 机制，把不同场景下的差异性交给用户和社区去扩展实现，基本能覆盖企业应用的不同模式和各类架构。当然 CRD 只是 K8s 架构可扩展性的方法之一。像 Webhook，Scheduler framework，Extended resource，CNI，CSI，DRA 等等，可扩展的架构原则几乎贯穿于 K8s 的各个角落。

第三个关键节点是 K8s 调度器全面转向 Scheduler framework 架构。CRD 机制为用户定义和管理特有对象（比如 Spark 作业，分布式 AI 训练任务等）的生命周期提供了扩展能力，但对象在集群中的资源需求，还需要定制化调度策略来支持，比如 batch job 常用的 Gang 调度，多租户任务间的资源配额共享，分布式训练任务对 GPU 设备和网络连接拓扑的选择，等等。

K8s 调度器在 1.19 之后全面迁移到 Scheduler-framework 架构，将 Pod 走过整个调度周期的每一个阶段都通过 hook 机制暴露出来，容许用户的 plugins 重新组合、编排出各种 Pods 与 Nodes 的装箱策略。自此之后，K8s 调度不再局限于单个 Pod 的资源分配，社区很快就扩展出 Batch 任务调度、异构资源调度、离在线混部、面向 SLO 的精细化调度、面向云资源的弹性调度等等，这些丰富的调度能力，为 K8s 支撑更多工作负载类型提供了基础保障。

大量 AI/ML 领域的训练和推理任务，大数据领域的 Spark 批，Flink 流，通用分布式计算框架领域的 Ray，甚至 HPC 领域的 Slurm 作业，都可以在 K8s 集群中调度。进入更多负载领域，这一点对 K8s 的未来演进很重要。

InfoQ：您认为 k8s“打败”Docker Swarm、Mesos、Openstack 的关键是什么？

张凯：前面谈到了 Docker Swarm。在我看来，Mesos 其实并没有真正进到那场战役中。从 Mesos 当时自身的技术架构、场景定位，与容器的协同性，以及对容器化未来的判断和决心上看，只能说是分布式系统的资源编排调度领域中的一个出色框架实现，对新型运行环境“容器”的兼容支持。这样的定位，使 Mesos 很快成为云原生时代的过客。

Openstack 不好评价是否真的彻底失败了，因为到今天 OS 还在迭代。而且的确也还有不少的生产环境中运行着 OS 全家桶或者部分核心组件。从场景定位，关键技术领域，甚至一些核心架构设计上，OS 和 K8s 有较高的重合度。但两者的发展，似乎像是跑在了两条平行道上。

InfoQ：之前谷歌发表的相关演讲中有说到“vm 的利用率是 5%，而 k8s 的节点利用率达到 20%”。K8s 利用率的提升实际比 vm 高多少，主要是因为什么？现在您们的利用率最高能达到多少？

张凯：把资源利用率归结到 VM 和容器的维度是把问题过于简单化了。虚拟化的开销与容器化相比当然是不一样的，但大家都在做控制面的 offloading 到 DPU 上，尽可能把 CPU 资源留给客户应用，使这部分的差异在变小。如果是单机维度，容器密度高，在一定程度上比通过 VM 交付给应用的资源使用率会提升。但在集群纬度，整体资源利用率的差异还与调度能力、应用负载的特征、运维策略（可用性/可靠性优先，成本/效率优先）、运营策略（TCO、售卖率、超卖率）等很多因素相关，单纯下一个用 VM 就会比用容器 K8s 的资源利用率低的判断，实际意义不大。

InfoQ：发展到现在，您认为推动 K8s 广泛采用的最关键因素是什么？

张凯：大家比较共识的因素主要有：标准化（包括容器作为标准化的交付、运维和调度单元，标准化 API），兼顾 Dev 和 Ops 的体验，可扩展的架构，与 CNCF 其他领域项目的集成与协同，良好的抽象和中立的架构实现（不绑定、便于迁移、统一管理）。当然还有越来越多行业的生产落地实践和非常好的知识传播和推广，以及背后 CNCF 的成功运营。

InfoQ：在 AI 时代，K8s 在哪些方向上需要有所改进？

张凯：K8s 设计之初目标支撑的主要场景还是无状态类工作负载（比如 web 应用和微服务），后来随着系统稳定性和存储卷管理能力的增强，很多有状态类负载也被跑在 K8s 上，比如数据库、分布式中间件等。到这里，K8s 的核心架构都还没有碰到特别大的挑战。明显的变化发生在 AI 时代，尤其以深度学习为代表的 AI 任务，与以 Spark 批和 Flink 流为代表的大数据处理任务，被大家尝试运行在 K8s 集群上。

最突出的 gap 在调度，概括来说，主要是 GPU 等异构资源的调度和任务级调度。异构资源的调度方面，K8s 需要能够针对各类异构设备的体系结构、软硬件协同手段和设备间的约束（共享、隔离、连接等），通过资源调度，最大化集群整体资源利用率。任务级调度方面，K8s 需要能够从面向单个 Pod 的调度，扩展到面向一组 Pods 的调度，满足 Pods 间的各种依赖、关联和约束，提升任务整体效率。Scheduler-framework 架构，就是 K8s 调度管理 AI 任务的关键改进之一。

本质上，需要 K8s 能够高效支撑一个大规模的任务系统。从架构上，除了调度器（batch scheduler）和任务对象的生命周期控制器（job controller），还缺少重要的一个组件 – 任务队列（job queue）。K8s 社区也意识到了这一点，孵化中的 Kueue，Kube-queue 等项目就在试图补上这一块关键拼图。

AI 任务是典型的数据密集型负载，且需要 GPU 此类高性能计算资源支撑。而在存算分离架构下，必然要管理和优化计算任务使用数据的效率问题。原生 K8s 在这里还有很多缺失。CSI 和 Persistent Volume 仅提供了对异构存储服务的统一接入和卷管理的基础能力，但对于计算如何使用数据，如何管理数据，如何优化存储访问效率等都没有涉及。好在 CNCF 社区内已经有项目在着手填补这里的能力空白，比如 Fluid 提供面向 AI/大数据任务的弹性 Dataset 管理、调度和访问加速，最大化降低 Data IO 对 GPU 计算效率的影响。

InfoQ：您对 K8s 的未来感到乐观吗？未来 5-10 年，会有其他取代 K8s 的技术出现吗？如果看待 WebAssembly？

张凯：我对 K8s 的未来保持乐观，同时也期待 K8s 能有更多创新的架构演进，来满足 AI，大数据，甚至 HPC 等这些更大空间、更高价值的数据类任务的基础设施需求。

目前还没有看到取代 K8s 的技术长出来，这里的观察是，K8s 在通用性、可扩展性、中立性等核心架构设计原则上，以及稳定性、安全性和性能等具体实现质量上，都还没有出现大的问题。同时，K8s 还在被引入到更多场景（AI，大数据，HPC，Edge，多云，分布式云，Serverless 等等）这样的话，出现一种取代 K8s 的全新技术的必要性还不大。

InfoQ：有夸张的说法是：“Kubernetes 非常复杂，以至于可以把你的整个职业生涯都花在这上面”，那么我们该怎么看待复杂性问题？

张凯：并没有那么夸张。K8s 的技术体系的确已经很复杂，需要了解的子系统、组件和架构也的确很多，涉及到每部分的实现细节就更庞杂了。这个其实是正常的，毕竟要解决的是一个具备弹性的大规模分布式应用系统，要面对的几乎所有技术问题。问题域的规模决定了解决方案的层级。应该看到复杂性，但更应该理解为什么会有这样的复杂设计和实现。

K8s 其实已经实现的相当不错了，但也有不少潜在的问题。比如，CRD 滥用带来的整体架构腐化和系统负担；节点侧偏封闭的架构对灵活支持新资源类型的制约；大规模生产环境下，缺乏系统调优经验，容易碰到故障雪崩等。这些问题要比表面上的概念、配置项、和组件使用复杂性要重要的多。要做到轻松应对这些问题，只能靠足够多的一线动手实践经验积累了。 另外，如果单纯想避开 K8s 使用上的复杂度，现在的各类 AI 助手已经很有用了，比如 k8sgpt。

InfoQ：K8s 生态系统中，如果有 3 个不得不提的软件，您认为是哪 3 个？为什么？

张凯：K8s：成功帮助 IaaS 资源服务，一起构建起高效支撑各类工作负载和 PaaS 的云原生基础设施

Prometheus：被 K8s 成就的 APM 后来者，几乎一切线上运维的起点都来自可观测性

ETCD：K8s 系统状态核心，稳定性和一致性的压舱石，也是故障的源泉

InfoQ：落地 k8s 后最 top 的实际收益和痛点有哪些？以及期望未来还能利用 k8s 做些什么？

张凯：我看到用户的收益是可以在一个标准，稳定，可扩展的集群和负载管理基础设施之上去把业务系统的 devops 流程化，业务服务化管理，资源效率和工程效率提升，这几个企业 it 最主要的方面快速落地，并能持续定制优化。给了使用者一个真正可持续建设，持续收敛投入产出比的基础。 痛点还是在如何更顺畅的将已有架构，历史业务部署，向 kubernetes 云原生架构迁移，统一。 我个人是期待基于容器，kubernetes 帮助企业所有微服务/ai/大数据平台实现一体化管理，进而统一技术栈和流程，最终达成 IT 组织架构上的统一。

InfoQ：k8s 项目以及 cncf 社区的成功，对大家如何看待开源带来了什么启示？

张凯：对于开源的启示。我个人觉得国内从开源获取的多，有效贡献的少。大家更热衷于讨论开源商业模式是什么，却少有讨论我们很多开源的项目有多少实际价值和可持续性。kubernetes 和 cncf 的开源成功可能在国内很难复制，但我们应该看到开源对一个技术领域发展所带来的加速效果。服务 provider 角度，应该把理解开源，拥抱开源当成一种战略，consumer 应该把基于开源当成一种创新加速器和可持续架构的基础选项之一。