Kubernetes 弃用 cgroup v1：接下来会发生什么

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

在本期中，我们探讨当计算工作负载需要在边缘运行 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

Edge deployment on Kubernetes has been gaining steam for years, with CNCF projects like KubeEdge and many vendor platforms emerging to support Kubernetes at the edge. This year’s KubeCon + CloudNativeCon will host a dedicated, co-located Kubernetes on Edge Day to explore this intersection of cloud-native and edge computing.

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

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

节点交换使 Kubernetes 密度提升最高达 3 倍

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

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

他们提议在 Kubernetes 节点上运行 node swap，这一功能已在 Kubernetes v1.34 中达到正式可用状态，可以在流量高峰期间充当“减震器”。

在他们的基准测试中，作者报告称，在某些场景下，当 node swap 由快速 NVMe SSD 支持时，密度提升最高可达三倍。该分析为在实践中缓解智能体 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 是 CNCF 毕业项目，专注于基于 eBPF 的网络、可观测性和安全，将于今年 11 月 9 日在盐湖城举办另一场同址活动。与会者可以期待会议聚焦于云原生 AI 和安全。

正如 Isovalent（思科旗下）的 Joe Stringer 和 Google 的 Jordan Rife 在 CNCF 博客上写道：“今年的议程直指当 AI 和 GPU 工作负载将 Kubernetes 网络推向其设计初衷之外时所暴露出的问题。”

社区持续回应新的 GPU 需求和 AI 驱动的可观测性要求，以及新的漏洞。近期还涌现出大量其他有趣的案例研究，展示了 Cilium 以及 eBPF 如何获得越来越多的生产环境应用。

“Cilium 近期与 Splunk、Celonis 和 Preferred Networks 的案例研究讲述了 eBPF 如何被用于安全和 AI 用例，我认为这很好地预示了未来的发展方向，”Cilium 和 eBPF 社区推动者 Bill Mulligan 对 The New Stack 表示。

他还提到了 BpfJailer，这是来自 Meta 的一款开源 eBPF 安全工具。它是对 Meta 内部闭源 eBPF 安全工具的实验性开源重写。

关注 Cilium、Tetragon 或 eBPF 的 Hiveminders 应该知道：Isovalent 还将在盐湖城举办其盛大的 Hive Mind Mingle……但请尽快报名；名额有限。

跟随通往 KubeCon 之路

Road to KubeCon 是由 HPE 在盐湖城举办的 KubeCon + CloudNativeCon North America 上呈现的八部分系列。出发前，探索 HPE Software 如何帮助 IT 团队以更少的复杂性做更多的事。

如果你还没有购票，The New Stack 读者可享受由云原生计算基金会（CNCF）提供的特别折扣。在通过此链接注册时使用代码 KCNA26MED10，即可享受门票 10% 的折扣。

在正式活动之前，我们每周五都会在这里为你介绍通往 KubeCon 之路上你需要了解的内容。

与此同时，你可以回顾往期内容，涵盖 Kubernetes v1.37、推理成本、OpenTelemetry 更新和云原生 AI 工具集。或者阅读完整存档。

本系列的撰稿人 Bill Doerrfeld 欢迎投稿。可通过他的个人联系页面发送 PR、更新、项目、引述或热门观点。

热门故事