Kubernetes十年：盛宴已过，长路漫行

作者 | Tina

6 月 14 - 15 日 ArchSummit 全球架构师峰会·深圳，深度探索大模型时代软件架构最佳设计。

采访嘉宾｜张智博、张凯、李向辉、邓德源

编辑｜ Tina

Kubernetes 已经存在十年了。它本来是谷歌作为秘密武器而存在的容器化作业编排与管理理念，因为“开源”而迅速占领市场，成为了企业 IT 的一项基础能力，从而取得了巨大的成功。

这十年里，我们看到国内外曾遍地开花的容器和编排技术创业公司逐渐沉寂，我们也看到 Kubernetes 从羽翼未丰发展到一家独大。在 AI 时代，虽然市场的关注点已经不再是 Kubernetes，但无数开发者都是这个生态的受益者。

见证过 Kubernetes 和社区取得成功的张智博是受益的开发者之一，“我原来所在的初创公司 Rancher 被收购后，现在我还能以高龄 IT 工作者的身份，在甲方的 IT 部门寻求一份工作，都受益于 Kubernetes 生态的发展。顺势而为，作为一个平凡人，在大趋势中寻求个人的发展，这是给我自己最大的启示。“

Kubernetes 开源后，迅速崛起并取得了关键的领导地位。这也得益于公有云厂商积极提供 Kubernetes 托管服务，极大地降低了使用门槛，并且云原生已转变为腾讯、阿里、火山引擎等企业争夺的存量市场。因此，我们也同时邀请了阿里云张凯、腾讯云李向辉、火山引擎邓德源解读他们眼中的 Kubernetes 是如何改变云计算行业格局的。

谷歌的阳谋

真正达到推动行业发展的“意义”层面，我认为这顶桂冠应该颁给 Container，Kubernetes 只是在 Container 潮流下的优秀产物。

2014 年，当时的 Docker 还是一家只有 30 名员工的小公司，刚刚从 dotcloud 改名。这一年的一则重磅新闻是 Docker 1.0 的发布，从此容器化浪潮逐渐处于世界的核心。

容器技术兴起，催生了大量容器创业公司。似乎每个大型创业公司都有一个容器编排项目，彼时资本市场对容器创业公司青睐有加，融资规模和数量持续增长。国内的一些大型企业同样都有自研的一套编排调度系统，如百度 Matrix、阿里 Sigma。还有一些企业，如国内美团和国外 Twitter，使用的则是 Mesos。

这一年的DockerCon上，Docker 创始人兼 CTO 在宣布 libswarm 时，首先给大家介绍了一波已有的“竞争对手”：Shipper、Geard、Mesos、Coreos、Consul、Helios、Centurion。这些项目及背后的企业在容器编排领域展开角逐的原因也容易理解，那就是 Docker 或者容器本身的价值虽然大，但是如果想要让其产生商业价值或者说对云的价值，那么就一定需要在编排上面占据一个有利的位置。

截图来源：https://www.slideshare.net/slideshow/docker-the-road-ahead/35706350

这个时候的谷歌已经建立了世界上规模最大、性能最强的计算机网络，遍布全球的服务器数量达到数百万台。Kubernetes 的理念来源于谷歌公司内部管理着数百万服务器的 Borg 系统。

Borg 和 Kubernetes 都是容器编排系统，但它们在设计理念和细节上存在一些差异。最大的差异在于，Borg 是从谷歌内部逐步发展起来的系统，与谷歌的基础设施高度紧耦合。因此，这个系统可以深入到业务逻辑层面，做出相应的判断。Kubernetes 则是一个完全开放、可插拔的系统，不涉及内部业务逻辑的判断。

在具体的设计方向上，曾为谷歌集群管理组核心成员的邓德源介绍，Borg 进行更多的状态机管理。任务在 Borg 中以状态机的形式存在，从运行（running）到挂起（pending），有一套严格的状态流转过程，并由特定事件驱动任务的状态变化。这使得 Borg 的管理和调度难度较大。相比之下，Kubernetes 简化了状态管理，采用了异步执行的方式，没有状态机的概念，即以异步方式进行状态管理。此外，Borg 的网络设计是通过主机加端口的方式对外暴露服务，这增加了调度的复杂性和难度，经常出现问题。Kubernetes 则定义了新的网络模型，例如每个 Pod 拥有自己的 IP，Service 也有独立的 IP。Kubernetes 借鉴并优化了许多之前的架构设计理念，形成了一个更加解耦的系统。

然而，当 Kubernetes 团队提出开源计划时，却遭到了谷歌技术基础设施高级副总裁的质疑：“开源？这能给谷歌带来什么好处？”但最终谷歌还是 2014 年的 DockerCon 上宣布了开源 Kubernetes。这显然并非仅仅出于技术分享，更蕴含着其深层的战略考量。当时亚马逊在云计算领域拥有了不可撼动的领先地位，虽然谷歌拥有令人惊叹的云基础设施，但没有有力的商业云业务来与 AWS 竞争，因此，谷歌需要一种方法来提高其相关性，抵消 AWS 的优势。

谷歌最初提出了“三级火箭”技术，即 Anthos、Kubernetes 和 GCP。首先通过 Kubernetes 的开源，先奠定一个容器领域调度和编排的事实标准，当各数据中心都用上 Kubernetes 之后，再通过给数据中心提供 Anthos 达到管理 Azure 或 AWS 异构基础设施的目的，并为用户提供无缝的多云体验。

基于这个目标，Kubernetes 提供了容器、微服务和声明式 API 的理念和标准。无论是云厂商还是自家的 IDC，甚至是多云环境，都可以通过它的标准 API 来管理底层的所有资源。

随后不过三年时间，业界就结束了调度编排领域的纷争，谷歌主导下的 Kubernetes 迅速成为业界最受欢迎的容器编排平台，阿里、腾讯、字节跳动等企业也纷纷迁到了 Kubernetes 上。2017 年底，甚至连亚马逊也发布了一款 Kubernetes 产品。而各家厂商投入 Kubernetes，又进一步奠定了它不可颠覆的地位。

对于云和容器厂商来说，它们会服务大量的客户，对技术的导向和用户选择的东西会更敏感。

“Rancher 一直都是企业级容器产品的提供商，但是最早并没有以 Kubernetes 作为核心编排引擎。在 2017 年时，我们的生意碰到了很大困难，越来越多的客户期望使用 Kubernetes，而不是我们自研的编排引擎，于是 2018 年我们果断放弃了之前的技术积累，将产品完全改造为 Kubernetes 管理平台。”张智博也提到了这一点。

虽然当时 Kubernetes 并没有达到企业级能力，大多数用户也几乎不会把核心业务落到 Kubernetes 上，但开源用户的基础量级确实非常庞大，而且发展膨胀速度极快。Kubernetes 技术也在开源社区的促进下不断发展，在这个过程中有两个不得不提的节点，其中一个是 1.7 版本中 Custome Resource Definition （CRD）机制的推出。Kubernetes 通过 CRD 机制，把不同场景下的差异性交给用户和社区去扩展实现，基本能覆盖企业应用的不同模式和各类架构。

另一个是 K8s 调度器在 1.19 后全面转向 Scheduler framework 架构，将 Pod 走过整个调度周期的每一个阶段都通过 hook 机制暴露出来，容许用户的 plugins 重新组合、编排出各种 Pods 与 Nodes 的装箱策略。自此之后，K8s 调度不再局限于单个 Pod 的资源分配，社区很快就扩展出 Batch 任务调度、异构资源调度、离在线混部、面向 SLO 的精细化调度、面向云资源的弹性调度等等，这些丰富的调度能力，为 K8s 支撑更多工作负载类型提供了基础保障。大量 AI/ML 领域的训练和推理任务，大数据领域的 Spark 批、Flink 流，通用分布式计算框架领域的 Ray，甚至 HPC 领域的 Slurm 作业，都可以在 K8s 集群中调度。

这些进展推动了 kubernetes 架构和能力的成熟，并体现出差异化优势，进而推动它从开源场景，逐步走入企业场景。

落地 Kubernetes 最实际的收益必然是资源的节省，以及应用的弹性能力的提升。

K8s 首先带来的是运维效率的提升，这也是 K8s 最开始想解决的问题。过去，部署应用得手动操作，费时费力不说，还容易出错。有了 K8s 后，运维人员通过配置文件，就能一键搞定部署，升级、回滚、灰度都可以通过 K8s 统一的管理平台搞定。

K8s 另一项收益是资源利用率的提升，从 VM 时代 5%的水平先提升到了 20%，再到目前的 65%左右（这也是一个大家认为的安全水位）。容器建立了比 VM 更细粒度的划分理念，从而能更有效地利用资源。

截图来源：2017年谷歌Kubernetes 高级产品经理 David Aronchick 演讲

现在，无论是腾讯还是字节跳动，都通过统一的 Kubernetes 集群整合了数据库、AI、大数据、在线业务等多个业务，并通过混部增强了调度和单机管控能力，整个集群作为一个标准的算力支撑服务，最终提升整体资源利用率。根据腾讯的公开数据，统一资源池后，整体资源利用率从 12%提升至 45% ，在离线利用率达 65%，3 年累计节省 30 亿。

“多云”愿景真的成功了吗？

回顾 Kubernetes 发展的关键节点，最核心的事件就是 K8s 的开源，以及开源社区为 K8s 的快速发展和普及提供了支持。

另一个关键节点是 K8s v1.0 的发布，我们认为它意味着 Kubernetes 真正从测试到生产可用，很多用户也逐步接受了 Kubernetes。

还有一个节点是 2015 年到 2016 年，在容器编排领域，Kubernetes 在与 Swarm、Mesos 的角逐中取得了有利的地位。

最后还有一个重要节点，即 2018、2019 年这个时间段，公有云下场提供 Kubernetes 托管服务，而且托管的费用极低（有些云甚至免费），极大降低了使用 Kubernetes 的门槛，同时也改变了这个市场的商业游戏规则。对于 Kubernetes 来说，作为一个开源项目如果没有商业化的支持，其实很难走得长久。

现在不同的云厂商都会提供自己的基于 K8s 的容器平台产品，如亚马逊 EKS、谷歌 GKE、阿里 ACK、腾讯 TKE、火山引擎 VKE 等。值得注意的是，AWS 的 EKS 应该是全球使用量最大的 Kubernetes 发行版。

有观点认为这些 Kubernetes 托管产品应该分为两个流派：原生派和魔改派。原生派，更倾向提供原汁原味的 Kubernetes，且紧跟 Kubernetes 的生命周期。托管的精髓在于，帮助用户解决 Kubernetes 的运维管理升级等问题。魔改派，更倾向把自己魔改的功能加入到 Kubernetes 中，打包提供给用户。

而我们想象的 Kubernetes，应该是一个能运行所有东西的平台，某种程度可以说是云原生应用的虚拟“操作系统”，像安卓一样暴露出统一的一套开发接口，让开发者完全无差别地交付自己的应用到世界任何一个地方。Kubernetes 之所以能成功并被企业广泛接受，某种程度上也是因为它的标准性和可移植性。如果云厂商在托管产品设计上各有特色，那么这是否跟 Kubernetes 理念相悖？

从用户角度来讲，用户确实会根据自身业务场景产生多云的诉求，比如基于稳定性的需求，需要把业务部署到多家云；或基于成本的需求，哪一家云价格便宜用哪一家；或基于安全性的需求，有些业务部署到国内的云，有些部署到国外的云。还有一些用户，会因缺乏经验和实践，导致整体效率未能达到预期。比如权限管理混乱，多租户间出现越权访问，比如在运维实践中，对 K8s 理解不深入，缺乏最佳实践，导致小故障引发大规模问题。所以也有些云厂商遵循标准并封装一些功能，用这些附加价值，来提升自己的竞争力。

那么这看起来就是一个矛盾点，因为用户的多云价值主张跟云厂商的价值主张并不一样。每一家云厂商价值主张都是希望用户“多多地用自己的，少少地用别人的”，努力去提高自己的核心收入和利润。这也是为什么我们所看到国外的 AWS、Azure 和 Google，国内的阿里云、腾讯云和华为云等等，他们对于多云混合云的投入其实都不那么感冒。所以，即使是实施多云，也会以自己为“主云”去实现多云管控和迁移，同时为了满足用户的需求去提供一些非标准的能力。

但云厂商实现云原生的思路，一定是首先确保所有的组件都是基于标准的 Kubernetes。因此，我们需要明确的是，选择权是在用户手中的：如果选择使用了更深层次的自定义服务，可能就不算是标准的 Kubernetes 了，它不具备跨云的迁移能力，但用户可以在上层做一层自己的封装。例如，一些客户引用了某云厂商提供的非标准 Kubernetes 能力，同时也在其他厂商处使用了类似的能力。这些能力并不在 K8s 标准接口的定义范围内。那么他们在上层会封装一层多云平台，以便统一管理底层不同云厂商的差异化能力。核心问题在于如何选择封装层次。

虽然基于 Kubernetes 构建上层平台呈现出百花齐放、各具特色的局面，看似杂乱无章、缺乏规律，但这些平台本质上都围绕着两个核心诉求：抽象和插件能力管理。

所以，正如张智博所言，“对于兼容和可移植性，用户只要确保不同云使用相近的 Kubernetes 版本，且对附加功能相对克制，那么多云之间的迁移和移植并非难事。这事和云厂商无关，主要看用户自己。”

一家独大之后的发展路线

Kubernetes 已经热度大减，但这并不代表它的消亡，而是以成熟稳健的能力作为一个企业级的基础设施。

大约在 2018-2019，社区一直在强调一个词：“boring”，即“无聊”。这标志着 K8s 真正成为了所有企业默认认可的项目。相比较及时关注社区的每一个新功能，大家更愿意踏踏实实地研究 K8s 能为自己带来什么价值以及可以用来做什么。各个企业也开始在自己的环境中深度使用 K8s，包括将云原生安全、云原生数据库等都迁移到 K8s 上。

从行业周期来看，Kubernetes 相关企业必然会经历整合阶段。在这个时间段里，产生了一系列收购：VMware 收购了由 Kubernetes 两位联合创始人创办的 Heptio，SUSE 则收购了广受欢迎的 Rancher。还有曾被誉为“云原生容器管理领域的创新灯塔”Weaveworks 公司宣布倒闭......绝大部分容器编排项目都逐渐销声匿迹，连 Kubernetes 最大的竞争对手之一 Mesos 也于前两年移至了 Attic 下，正式宣告“退休”。

截图来源：Kubernetes 领域的收购（Acquisitions in Kubernetes Space）

现在，随着 K8s 的广泛应用，其增长速度已经逐渐放缓，因为用户和企业的总量是有限的。K8s 已经渗透到教育、能源、泛互、制造、工业等各个行业，甚至是游戏、金融、军工，真正未被渗透的行业和企业已经非常少了。

K8s 的渗透和覆盖目前达到了一个相对平稳的状态。然而，K8s 在纵向上的应用深度在不断加深。

随着整个市场的饱和，特别是在云厂商之间，例如阿里、腾讯和火山引擎，竞争逐渐转向存量市场。在存量市场的竞争中，一个核心问题是多云环境下的兼容性尚未解决。这包括 K8s 的部署、不同 K8s 版本之间的差异化，以及如何在多云环境之间进行迁移。降低用户的迁移成本和使用成本，并在保证使用稳定性的前提下实现成本优化，是关键所在。

去年 11 月，滴滴发生了大范围、长时间的故障。官方消息说是“底层系统软件发生故障”，但业界普遍认为这是一起由 K8s 的脆弱性导致的生产环境大规模故障。这类与 K8s 使用脆弱性相关的案例绝非只有一起，怎么对抗 K8s 的脆弱性，来提升整个云原生的稳定性，也是纵深发展的一个方向。目前，腾讯、滴滴、美团、阿里都是在做这种更深度的大规模的应用和实践。

李向辉表示，从行业角度来看，大规模调度（包括混合部署和各层次的调度优化）以及稳定性人才的缺失，也反映了云原生应用的下一个发展阶段应如何推进。

AI 场景下，K8s 是否还重要

生成式 AI 到来后，虽然大家的关注点都转移到了大模型上，但我们也能从公开报道看到 OpenAI 这些企业的大模型开发并没有完全脱离 K8s 环境。

2021 年，OpenAI 的工程师们公布了他们的规划——将 Kubernetes 扩展到 7,500 个节点。这个集群不仅在 3 年内规模增长了三倍，还被用于 GPT-3、CLIP 和 DALL·E 等大型模型，以及快速小规模迭代研究。而且，OpenAI利用了“数以万计”的 NVIDIA GPU。这个规模带来了其他工程挑战，包括辅助监控、自定义调度等。

那么，为什么是 K8s，而不是别的如 HPC 框架成为这些企业的选择呢？曾在谷歌从事开源 Kubernetes 工作的 Matt Rickard 发表了评论，他认为 Kubernetes 虽然在某些方面存在不足，但如今容器已成为开发人员主流的部署方式，因此其开发者体验和云原生集成优势足以弥补这些缺陷。我们还可以通过邓德源的回复体会到同样的答案：

“在字节跳动内部，从 2016 年开始，我们就一直在使用 K8s，因此我们没有其他选择。不论是在线服务还是离线任务，只要是技术相关的项目，只要需要使用资源，不论形态如何，都会使用 K8s。因此，我们不会区分是生成式 AI 还是其他应用类型。对于字节跳动而言，所有的资源管理都是通过 K8s 进行的。因此，这是唯一的选择。”

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

张凯认为，在资源调度方面，K8s 需要能够针对各类异构设备的体系结构、软硬件协同手段和设备间的约束（共享、隔离、连接等），通过资源调度，最大化集群整体资源利用率。

任务级调度方面，K8s 需要能够从面向单个 Pod 的调度，扩展到面向一组 Pods 的调度，满足 Pods 间的各种依赖、关联和约束，提升任务整体效率。Scheduler-framework 架构，就是 K8s 调度管理 AI 任务的关键改进之一。本质上，需要 K8s 能够高效支撑一个大规模的任务系统。从架构上，除了调度器（batch scheduler）和任务对象的生命周期控制器（job controller），还缺少重要的一个组件——任务队列（job queue）。K8s 社区也意识到了这一点，孵化中的 Kueue、Kube-queue 等项目就在试图补上这一块关键拼图。

另外，AI 任务是典型的数据密集型负载，且需要 GPU 此类高性能计算资源支撑。而在存算分离架构下，必然要管理和优化计算任务使用数据的效率问题。原生 K8s 在这里还有很多缺失。CNCF 社区内已经有项目在着手填补这里的能力空白，比如 Fluid 提供面向 AI/大数据任务的弹性 Dataset 管理、调度和访问加速，最大化降低 Data IO 对 GPU 计算效率的影响。

在训练过程中，辅助的监控和运维系统的建设并不是特别完善。尤其是在大规模训练时，如何监控 GPU 的功率并准确判断用户的任务是停止了还是仍在训练中，仍是一个挑战。举个例子，如果用户在训练模型时，发现模型训练框架在运行过程中突然停掉了，然而，使用传统的 CPU 或 GPU 监控方案并不能有效检测到这种情况。这里可能有一个关键指标，即 GPU 的功率。当 GPU 的功率下降时，意味着任务已经停止。在这种情况下，当任务停止后，如何快速启动新任务以加速训练进程，各大云服务提供商并没有很好地解决这一问题。这表明在大规模训练过程中，监控和运维系统的改进空间依然很大。

此外，在 GPU 虚拟化方面，目前已有一些成熟的方案，如 QGPU、VGPU、mGPU 和 cGPU。然而，在 GPU 应用场景下，很少有关于 GPU 利用率的数据出现。在 CPU 利用率方面，业界通常会提到 60%或 80%的利用率，但对于 GPU 利用率，什么情况下算是完全压榨了 GPU 的性能，几乎没有相应的讨论和说明。这表明在这一领域的问题仍未得到充分解决，并且缺乏完整的行业解决方案，例如，虽然我们看到 Google 等公司声称构建了 6000 个节点的 GPU 训练集群，但在业界很少有关于这种大规模 GPU 训练集群的分享或深入思考。

所以在大厂里，不管是现在 GPT 也好，或者其他各种公司大语言模型也好，都是基于 K8s 来调度 GPU 的算力。只是现阶段，因为还没有现象级应用出现，很少有 AI 应用留存率非常高，很多就是个位数，所以大家更关心的是如何更快地发一个应用、如何更快地发布模型，甚至可以烧几个亿去抢夺那么几天的首发时间。也因此，现在大厂主要还是以支持 AI 原生应用为主，去解决一些应用层的问题，比如模型加载速度慢、如何选择合适 GPU 卡、模型灰度。对于万卡级别的调度和资源管理的，以“独占”的方式去运行：单独创建一个 K8s 集群，让你用就行了。可以说，对他们来讲，无论是 GPU 也好，K8s 也好，都没那么重要。

但再往后看的话，一旦这个事情有一定冷却，有更多的实际业务场景落地并进入商业化阶段，GPU 利用率就会成为这些公司最重要的事情之一。大家就会关注在 GPU 场景下，怎么去做大规模算力的支撑，怎么去优化网络、存储和并行计算架构的高效使用，这也会成为整个容器或云原生应用未来探索的方向。而且它会带来大量的岗位和职业，也会给企业带来大量的利润。

写在最后：Kubernetes 为什么成功了？

围绕 Kubernetes 的生态，还有一个不得不提的板块，就是 CNCF。

Kubernetes 开源过程中面临的最大挑战之一是治理问题。谷歌最初承诺开源 Kubernetes，但当他们开始接纳外部贡献者时，代码控制权仍然牢牢掌握在谷歌手中。开发者必须签署一份谷歌协议，该协议授予谷歌对项目近乎完全的控制权。这种做法并非罕见，大型公司往往试图在开源社区中获取利益的同时，又牢牢掌控项目主导权。

为了解决这一问题，谷歌将 Kubernetes 项目移交给了独立实体 CNCF，并将其作为 CNCF 的首个项目。这是让 Kubernetes 得以健康发展的关键举措之一。CNCF已经有了 741 个成员，190 个项目，生态版图也日益扩大。

作为一个成功的开源项目，每一位贡献者都是成就它的英雄。但如果我们要论贡献度最高的，肯定是 Founder：“没有谷歌，就没有 Kubernetes”。

如果还有一位，那么它一定是“红帽”：“没有红帽参与的开源项目都不算真正的开源项目”。

在 Kubernetes 筹谋开源时，红帽找到了谷歌。2014 年 12 月，在谷歌正式发布 Kubernetes 项目不久，红帽官方即宣布与谷歌开展战略合作，全面投入 Kubernetes。虽然这是因为红帽想进军云计算，需要给 OpenShift 一套容器管理框架，但这家从 1993 年就存在的企业在开源社区里，有非常好的影响力。有个说法是：如果一个开源项目不够纯粹，或者开源厂商对项目的主导权过于强势，红帽通常不会参与其中。

所以 Kubernetes 一方面受益于谷歌的技术影响力，另一方面也受益于红帽的开源影响力。

如今，无论是从技术理念、开源投入、工程师认知成本、生态发展，Kubernetes 都已经变得无可替代。

如果继续探寻 Kubernetes 取得成功的其他因素，我们还得到了以下多个答案：

“100%开源，且具备强大的企业级功能。即使买不起企业级产品，自己也能搞出能力丰富的 Kubernetes 集群。没有人对如此低成本且符合发展趋势的产品有抵抗力，这是市场天然的选择。”

“有一套标准和规范，API 的设计清晰优雅，适用于各种云厂商、私有数据中心和多云环境。”

“开源运作得好。依靠整个社区的力量，使其能力逐渐得到完善。”

“拥有丰富的生态系统，包括 Helm、Prometheus 等众多工具和项目，跟 Kubernetes 贴合非常紧密，可以帮助用户解决发布、部署、监控、运维等各种问题。”

“商业化和开源的平衡。云厂商的大规模应用推动了容器技术的商业化进程，商业化成功反哺了开源社区，为社区的持续发展提供了资金和资源支持。”

嘉宾简介：

张智博，前 SUSE Rancher 大中华区研发总监，一直活跃在研发一线，经历了 OpenStack 到 Kubernetes 的技术变革，在底层操作系统 Linux、虚拟化 KVM 和 Docker 容器技术领域都有丰富的研发和实践经验。目前在某头部车企 IT 部门任职。

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

李向辉，腾讯云云原生分布式云负责人，主要方向为容器基础设施，多云多集群以及容器高可用的方向，主要工作为通过云原生技术加速企业现代化应用落地并实现降本增效。拥有丰富在线业务架构和应用迁移云原生经验，同时在业务高可用，成本优化，效率和业务体验提升上有较深的积累和思考。

邓德源，火山引擎云原生应用平台总监，在企业云原生技术应用方面有着丰富的产品和架构经验。加入字节跳动之前，担任杭州才云科技联合创始人。曾为美国 Google 集群管理组核心成员，主要参与开发集群管理系统。

幸福双城资讯网

因佛科技