Kubernetes 弃用 cgroup v1，生态转向新方案

欢迎回到新一期 Road to KubeCon，我们正在为 2026 年 11 月 9 日至 12 日在犹他州盐湖城举办的 KubeCon + CloudNativeCon North America 做准备，同时追踪云原生生态系统的最新动态。

在本期内容中，我们探讨当计算工作负载需要在边缘运行 AI 时会发生什么。底层的 Kubernetes 机制会发生变化，可观测性实践和安全决策同样如此。我们来看看正在涌现的策略，以及几个关键项目如何应对这些变化。

请阅读下面的报道：释放 Kubernetes 容量、HPE 在面向 AI 的专用计算方面取得的进展、关于淘汰已弃用 Linux 内核接口的提醒，以及今年 Kubernetes on Edge Day 和 Cilium 同场活动的看点。

HPE 的专用边缘计算之道

将边缘计算用于 AI 推理有很多合理之处——减少不必要的服务器调用、降低数据出口费用，并让数据远离云端以满足合规要求。因此，许多企业正出于这些以及其他原因转向边缘 AI。

Hewlett Packard Enterprise (HPE) 是 Road to KubeCon 的展示赞助商。HPE Software 帮助 IT 组织在混合、多厂商环境中实现基础设施现代化、简化运维并加速 AI 计划。

然而，正如 HPE 的 Aaron Lamond 在近期一篇 HPE 博客文章中所指出的，组织在使用未经优化的服务器时，往往是在方枘圆凿。“随着智能变得越来越分布式，专用计算对运营成功变得愈发关键，”他写道。

在 Lamond 看来，“专用计算”应综合考虑硬件、软件、安全和运维如何协同配合。他表示 ProLiant 边缘服务器非常适合这项任务，因为它们针对资源受限、需要高等级安全性的环境进行了边缘优化。

边缘知识回归 Kubernetes on Edge Day

多年来，在 Kubernetes 上进行边缘部署一直在升温，KubeEdge 等 CNCF 项目以及众多厂商平台纷纷涌现，以支持边缘场景下的 Kubernetes。今年的 KubeCon + CloudNativeCon 将举办专门的同场活动 Kubernetes on Edge Day，探讨云原生与边缘计算的这一交叉领域。

正如 Mars Toktonaliev 和 Katerina Arzhayev 在 CNCF 博客上所写：“该活动的创办是为了弥合传统以数据中心为中心的云原生方法与边缘计算运营现实之间的差距。”他们提到可观测性和安全性是尤为相关的主题。

Kubernetes on Edge Day 的议程将展示广泛的案例研究和运维指南——对在分布式、资源受限环境中运行 Kubernetes 的工程师很有帮助。

节点 swap 将 Kubernetes 密度提升至多 3 倍

突发性的 agentic AI 工作负载可能会意外地需要大量前置内存。此后，内存往往处于闲置状态。但闲置的 RAM 成本高昂，而这种分配方式限制了 Kubernetes 集群密度。

周一，Ocean Xie 和 Yuan Wang 在 Kubernetes 博客上深入探讨了这一问题。“内存往往是 Kubernetes 集群首先撞上的硬性上限，”他们写道。“节点在 CPU 耗尽之前很久就先耗尽 RAM，而新一波 agentic AI 工作负载让情况更加糟糕。”

他们提出以节点 swap 方式运行 Kubernetes 节点，该功能在 Kubernetes v1.34 中达到正式可用，可以在流量高峰期间充当“减震器”。

在他们的基准测试中，作者报告称在某些场景下，当节点 swap 由高速 NVMe SSD 支撑时，密度提升可达三倍。这项分析为在实践中缓解 agentic AI 的高计算开销和成本贡献了新兴方法。

自托管平台部署在安装前需要做好准备

本周，托管云原生基础设施提供商 Fairwinds 为那些销售自托管 AI 平台的公司分享了实用指南。据工程总监 Munib Ali 称，安装只是开始。

Ali 认为，一个能用的安装程序是不够的。平台厂商往往在交付时没有考虑客户侧所需的周边机制——比如提前明确团队职责、设置 IAM、持续维护、与客户私有云的兼容性、受支持的 DNS 配置等等。

“AI 平台的自托管 Kubernetes 部署常常因为客户前置条件、环境限制和跨团队交接不完整而停滞，”Ali 说。如果没有这些准备，安装日期可能会推迟，项目甚至可能永远无法启动。

一些云原生厂商出于隐私、数据主权或控制权的原因提供客户托管交付。但要使其无缝进行并避免瓶颈，团队需要在“上线”之前弄清楚很多事情，而这可以说应该是共同的责任。

随着 Kubernetes 的演进，对运行它的团队的要求也在不断提高。展示赞助商 HPE 通过涵盖虚拟化、云管理、可观测性和自动化的软件，帮助团队应对这种复杂性。

Kubernetes 转向 Linux cgroup v2

周二，云原生软件公司 DaoCloud 的开源团队负责人 Paco Xu 分享了对 cgroup v2 的看法，这是用于管理 CPU 和内存等资源的内核特性。据他所说，cgroup v1 有许多局限性。

“与 cgroup v1 相比，cgroup v2 提供了单一统一层级、更一致的接口，以及更坚实的资源隔离和现代资源管理特性基础，”Xu 写道。根据 Kubernetes 版本和配置的不同，cgroup v2 支持内存服务质量更新、容器感知的 OOM 处理、无根支持以及其他特性。

自 v1.35 起，kubelet 默认拒绝在 cgroup v1 节点上启动。如果你使用的是较旧的版本，Xu 建议在升级前将每个 Linux 节点迁移到 v2。运维人员应考虑做出响应，以获取这些优势并避免架构过时。

聚焦近期 Cilium 社区动态

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）