张贴在 2026

  • Kubernetes v1.36 抢先一览

    借由 Chad Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Utkarsh Umre | 2026.03.30 在 博客

    Kubernetes v1.36 将于 2026 年 4 月底发布。 本次发布将包含移除和弃用项，并带来数量可观的增强功能。 以下是我们在这个发布周期中最期待的一些特性。 请注意，本文信息反映的是 v1.36 开发的当前状态，发布前仍可能发生变化。 Kubernetes API 的移除与弃用流程 Kubernetes 项目针对功能有一套文档完善的弃用策略。 该策略规定，稳定版 API 只有在有新的稳定替代版本时才会被弃用，并且 API 在每个稳定级别都有最短生命周期。 被弃用的 API 会被标 …

    更多

  • Ingress2Gateway 1.0 正式发布：通往 Gateway API 的途径

    借由 Beka Modebadze (Google), Steven Jin (Microsoft) | 2026.03.20 在 博客

    随着 Ingress-NGINX 计划于 2026 年 3 月正式退役，Kubernetes 网络图景正处于一个转折点。 对于大多数组织而言，问题不在于是否迁移到 Gateway API，而在于如何安全地完成迁移。 从 Ingress 迁移到 Gateway API 是 API 设计的根本性转变。 Gateway API 提供了一个模块化、可扩展的 API，并对 Kubernetes 原生的基于角色的访问控制（RBAC）提供了强大的支持。 相反，Ingress API 较为简单， …

    更多

  • 在 Kubernetes 上使用 Agent Sandbox 运行智能体

    借由 Janet Kuo Justin Santa Barbara | 2026.03.20 在 博客

    人工智能领域正经历着一场巨大的架构变革。 在生成式人工智能的早期，与模型交互通常被视为一个瞬态的、无状态的函数调用：一个启动、执行可能仅 50 毫秒便终止的请求。 如今，人工智能 2.0 正在取代人工智能 1.0。 人工智能生态系统正从短暂、孤立的任务转向部署多个持续运行的、协同工作的 AI 智能体。 这些自主智能体需要维护上下文信息、使用外部工具、编写和执行代码，并在较长时间内相互通信。 当平台工程团队寻找合适的架构来托管这些新型 AI 工作负载时， Kubernetes 脱颖而出，成为自然 …

    更多

  • 宣布成立 AI 网关工作组

    借由 Keith Mattix, Nir Rozenbaum, Morgan Foster, Flynn | 2026.03.09 在 博客

    Kubernetes 社区包含多个特别兴趣小组（SIG）和工作组（WG）， 旨在促进相关贡献者之间就重要议题展开讨论。 今天，我们很高兴地宣布成立 AI 网关工作组， 这是一项专注于为 Kubernetes 环境中支持 AI 工作负载的网络基础设施制定标准和最佳实践的新举措。 什么是 AI 网关？ 在 Kubernetes 环境中，AI 网关指的是网络网关基础设施（包括代理服务器、负载均衡器等）， 它通常实现 Gateway API 规范，并针对 AI 工作负载提供增强功能。 AI 网关并非定 …

    更多

  • 节点就绪控制器简介

    借由 Ajay Sundar Karuppasamy (Google) | 2026.02.03 在 博客

    在标准的 Kubernetes 模型中，节点是否适合运行工作负载取决于一个简单的“就绪”状态。 然而，在现代 Kubernetes 环境中，节点需要复杂的底层架构依赖项 （例如网络代理、存储驱动程序、GPU 固件或自定义健康检查）才能完全运行，从而可靠地托管 Pod。 今天，我代表 Kubernetes 项目宣布推出节点就绪控制器。 该项目引入了一个声明式系统来管理节点污点，从而在节点启动过程中扩展了就绪保护机制，使其超越了标准条件。 通过基于自定义健康信号动态管理污点，该控制器确保工作负载仅 …

    更多

  • Ingress NGINX：Kubernetes 指导委员会和安全响应委员会的声明

    借由 Kat Cosgrove（指导委员会） | 2026.01.29 在 博客

    Kubernetes 将于 2026 年 3 月停止维护 Ingress NGINX， 该基础设施是大约一半云原生环境的关键组成部分。 Ingress NGINX 的停止维护计划已于 2026 年 3 月正式宣布，此前多年来， Kubernetes 一直公开警告该项目急需贡献者和维护者。 项目停止维护后，将不再发布任何错误修复、安全补丁或任何类型的更新。 此事不能被忽视、敷衍了事，更不能拖延到最后一刻才处理。 我们再怎么强调这种情况的严重性，以及立即开始迁移到替代方案 （例如 Gateway …

    更多

  • Headlamp 2025 年度项目亮点

    借由 Evangelos Skopelitis (Microsoft) | 2026.01.22 在 博客

    本公告是对最初在 Headlamp 博客上发布的帖子的回顾。 Headlamp 在 2025 年取得了长足的发展。该项目持续成长，覆盖了更多平台和团队； 通过插件机制支持了新的工作流和集成方式；同时也看到了来自更广泛社区的协作不断增强。 我们想借此机会分享一些最新进展，并重点介绍 Headlamp 在过去一年中的演进与变化。 更新 加入 Kubernetes SIG UI 今年标志着该项目的一个重要里程碑：Headlamp 现已成为 Kubernetes SIG UI 的正式组成部分。此举使路 …

    更多

  • 宣布成立 Checkpoint/Restore 工作组

    借由 Radostin Stoyanov, Viktória Spišaková, Adrian Reber, Peter Hunt | 2026.01.21 在 博客

    Kubernetes 社区包含多个特别兴趣小组（SIG）和工作组（WG）， 旨在促进感兴趣的贡献者之间就重要议题展开讨论。 今天，我们宣布成立新的 Kubernetes Checkpoint Restore WG， 专注于将 Checkpoint/Restore 功能集成到 Kubernetes 中。 动机和应用场景 工作组讨论了以下几个高层次的应用场景： 优化交互式工作负载（例如 Jupyter Notebook 和 AI 聊天机器人）的资源利用率 加速初始化时间较长的应用程序启动， …

    更多

  • Kubernetes v1.35：扩展容忍度运算符以支持数值比较（Alpha）

    借由 Heba Elayoty (Microsoft) | 2026.01.05 在 博客

    许多生产级 Kubernetes 集群会混合使用按需（on-demand，高 SLA）节点与 spot/可抢占（preemptible，低 SLA）节点， 以在保证关键工作负载可靠性的同时优化成本。平台团队需要一个“安全默认值”，让大多数工作负载远离风险容量， 同时又允许特定工作负载用明确阈值显式选择接受（opt-in），例如“我可以容忍失败概率最高 5% 的节点”。 目前，Kubernetes 的污点与容忍度（taints and tolerations）可以匹配精确值或检查键是否存在， 但 …

    更多

  • Kubernetes v1.35: 通过就地重启 Pod 实现更高的效率

    借由 Yuan Wang Giuseppe Tinti Tomio Sergey Kanzhelev | 2026.01.05 在 博客

    Kubernetes 1.35 版本引入了一项强大的新特性，满足了用户对 Pod 就地重启的迫切需求。 这项名为“重启所有容器”（Restart All Containers，1.35 版本为 Alpha 版）的特性， 相比于资源用量较高的删除并重建整个 Pod 的方式，能够更高效地重置 Pod 的状态。 该特性对于 AI/ML 工作负载尤为实用，使应用程序开发人员能够专注于核心训练逻辑， 同时将复杂的故障处理和恢复机制交给边车容器和声明式 Kubernetes 配置来处理。 …

    更多