标准化与多样性齐头并进的 KubeCon 见闻

本文主要总结了我在 KubeCon 中主要关注到的 Platform Engineering 和 SDLC（Software Development Lifecycle）相关的一些议题。

The Experience of ChillyRoom Developing & Managing SessionBased Game on K8s with OpenKrusieGame - Qiuyang Liu & Xinhao Liu

在这个议题中，来自凉屋游戏（Chillyroom）的 Xinhao Liu 分享了他们基于 OpenKrusieGame（OKG）在 Kubernetes 上开发和部署游戏服务器的经验。我一直比较关注 OpenKrusie，也听过 OKG，但是一直不太理解这个项目的场景。 

这个充满细节的分享帮助我理解了游戏开发里一些独特的云原生诉求，例如： 

• 需要根据业务状态来扩缩容——不止是副本数，也包括结束特定的 Pod。比如房间没有玩家时自动 Kill Pod；

• 连接是有状态的，需要始终和一开始建立连接的 Pod 通信；

• 平滑更新，已在服务器的玩家不受影响，下一轮匹配开始才是新版的服务器。

这些游戏领域特定的场景正是 OKG 这个项目创建的初衷。它基于  OpenKrusie 提供的支持原地升级（InPlace Update）的增强的 Workload，提供了 GameServerSet 和 GameServer 两个 CRD， 方便游戏行业的开发者更容易在 K8s 上部署管理游戏服务器。

听完这个议题的分享感叹 K8s 作为基础设施所能提供的扩展能力之强，还有整个云原生行业的百花齐放，在每个垂直领域都有人在深耕。

更多细节参考：https://sched.co/1eYb5

Developing a Standard Multi-Cluster Inventory API | 开发标准的 多集群Inventory API - Zhiying Lin & Chen Yu, Hongcai Ren, Di Xu, Jian Qiu 

这个圆桌会议邀请了几位既是多云管理项目（例如 Karmada、OCM、Clusternet、Fleet）的 Maintainer 也是 cluster-inventory-api 的贡献者谈谈多云标准 API 的设计。这也是我一直觉得社区做得不好的地方，尽管多云项目如此之多，支持跨集群管理的项目也很多，例如 ArgoCD、Clusterpedia、Kueue，但是每个项目都是有自己的实现。比如 ArgoCD 使用 Secret 来存储集群的 Credential，Clusterpedia 有自己的 CRD。这造成了不同项目之间多级群信息的割裂，如果同时使用多个，往往需要在不同类型的资源间迁移，以适配不同项目。

讨论者也提到除了多云应用，多云管理项目之间迁移也有类似问题。Di Xu 认为在 k8s 的理念中，每个项目是 building block 而不应是一个完全自洽的产品。加上曾经的标准 KubeFed 已死，现在多集群管理项目百花齐放的现状更需要一个更加标准、通用的 API 管理多集群。

讨论者也聊到了 Cluster Inventory API 在过去一年中进展缓慢，主要是作为上游的 API 影响太大，为了不产生 break change 所以做的决策都很谨慎，因此目前提供的能力也比较有限，甚至还不支持 Credential（下一步就会开始讨论），上面提到的几个多云管理项目的 use case 都无法支持。

Hongcai Ren 也聊到像 Karmada 这样的多集群管理项目，在日后很长一段时间都会保持原来的 API 和 Cluster Inventory API 同时存在，开始的时候，Cluster Inventory API 主要是由 Karmada 创建，方便其他多级群应用直接集成和使用，在将来会渐渐以一种用户无感知的方式向该 API 迁移。 

我下去又看了下相关的设计文档，目前在不同社区都有推进，但是包括上面提到的几个多云管理项目中都还没有实现。这肯定是一个好的能解决目前痛点的方向，但可能还需要更多时间，我也将继续关注这个项目。 

Detecting and Overcoming GPU Failures During ML Training | 在 ML 训练过程中检测和克服 GPU 故障 - Ganeshkumar Ashokavardhanan & Sarah Belghiti

这个议题中讨论机器学习训练中经常碰到的 GPU 故障的问题。以 Llama 3 为例，他们在 54 天的训练过程中由于 GPU 问题导致的训练中断达到 58.7%。

除了 GPU 故障导致的 Pod 直接退出，还有 GPU hang 住和速度降低（据 Speaker 说她们曾经观察到训练速度慢了 6 倍），由于 GPU 本身就很昂贵，这带来的损失也是巨大。他们接下来的分享也从应用和基础设施提供商（node）两个层面来展开。

Sarah 主要是从应用，包括： 

• 开始训练之前，通过 initContainer 来检测诸如 GPU 带宽、NCCL tests 的问题；

• 运行过程中，检测 Node 和 Workload 两方面的指标来检测 GPU 故障 和工作负载是否 Hang 住。一旦发现，则可以基于 CUDA 来实现保存 Checkpoint、迁移，从 Checkpoint 恢复；Ganeshkumar 从基础设施提供商的视角提供了一些办法，包括：

  使用 NPD（Node Problem Detector）来巡检，这里面会有一些不同硬件预期的指标不同的问题，好在社区已经有些开源实现了；

  一旦检测问题后，就可以使用 Remedy Controller（修复控制器）通过打污点、重启等方式来修复/避开硬件故障。

两位分享者带来的议题非常系统，也很有启发性，整个方案都是基于开源的实现，特别是应用层的思路与我的同事他们的方案不谋而合，他们也在这次 KubeCon 中分享，并且已经有了一个完整的开源项目，更多的细节可以参考：kccncossaidevchn2024.sched.com/event/1eYY2

Rollout Patterns: Smoothly Migrating and Rolling Out Your Microservices | 部署模式：平稳迁移和部署您的微服务

这是我第一次以 Speaker 的身份参加 KubeCon，带去的议题是围绕微服务的灰度发布中几种场景而展开，包括： 

1. 一次发布一个服务；

2. 多个服务一起发布，但是接口向后兼容；

3. 多个服务一起发布，但是接口不兼容。

这是一个充满技巧性的非常实用的分享，基于 ArgoCD 和 Argo Rollout 而设计，也是我们在客户侧落地过程中展开的思考和总结。希望能为听众带去帮助。

一些感想

总的来说，今年的 KubeCon China 非常热闹，分享的议题质量也很高，亲身参与下来体验很好。但是我也发现了一些趋势：

• 在 KubeCon EU 和 NA 如火如荼的 ArgoCD 在国内却没有任何议题，Backstage 及平台工程也没有什么热度。我觉得有 2 个可能性：一是这些理念在国内没有什么用户 buy in，二是这次来分享的终端用户本身就少，大部分还是项目的 Maintainer 或者云厂商，所以 use case 的议题偏少；

• 很多分享的议题不再是特别宏大的叙事和愿景，而是基于一个小的点衍生出来的非常丰富、充满细节的思考和经验，我觉得这样的分享非常有意思也收获满满，就像 Linus 说的 “I don't know cloud, I know kernel”，每个人都有在自己擅长的领域持续地思考和贡献，为这些分享者点赞。

            

访问以下网址，或点击文末【阅读原文】立即体验