Kubernetes 1.33您需要了解的和升级新功能

#作者：曹付江

Kubernetes 1.33（代号 “Octarine”）于 2025 年 4 月 23 日发布，带来了64项功能更新–18项稳定版、20项测试版和 26项 alpha 版。该版本重点关注可操作性、安全性、可扩展性和运行时控制。

Kubernetes v1.33 发布的灵感来自特里-普拉切特（Terry Pratchett）的《碟形世界》（Discworld）系列，它颂扬了开源协作和技术创新的魔力。与《碟形世界》异想天开的意象相呼应–在Kubernetes的64颗星星组成的月亮下，一条沼泽龙站在幽冥大学的塔顶–该版本向维护者的魔法、新贡献者的好奇心以及推动Kubernetes前进的充满活力的社区精神致敬。凭借数百名全球贡献者和 64 项新的 Kubernetes 增强提案（KEP），v1.33 版体现了项目对安全性、可靠性和集体卓越性的持续承诺，体现了 “即使你知道它是如何完成的，它仍然是神奇的 ”这一理念。
现在，让我们来讨论一下新功能。以下是运行、生产工作团队最关心的问题。

1、Octarine 有哪些增强功能？

1.1 Sidecar容器现在稳定了

Kubernetes 终于支持侧卡作为一等公民。借助 restartPolicy： Always 后，Sidecar 现在可以

• 在主容器之前启动
• 在主容器之后终止
  这简化了代理、日志代理和服务网格 sidecars 的生命周期协调，不再需要变通方法或初始容器黑客。

1.2无需停机即可调整正在运行的 Pod 大小

就地资源调整（Beta 版）意味着您可以调整实时 Pod 的 CPU/内存限制，而无需触发重启。

• 优势：
  • 无中断动态扩展
  • 更好地遵守 SLA
  • 更好地利用超额配置的资源
  • 这对有状态应用程序和关键路径服务尤为重要。

1.3用户命名空间（测试版）= 更安全的多租户服务

用户命名空间现在默认开启。容器可以作为非 root 内部运行，同时映射到主机上的不同 UID。这将降低

• 权限升级风险
• 对 PodSecurityPolicy 或外部加固的需求
  如果你正在运行多租户集群，这是必须关注的。
  动态资源分配（测试版）发展壮大
• DRA API 改进了对专用硬件的支持，例如
  • GPUs
  • FPGAs
  • High-performance network adapters
    这简化了调度和插件集成–这对于 AI/ML 流水线和计算量大的工作至关重要。

1.4 作为卷的 OCI 工件（Alpha）

直接将 OCI 映像作为卷挂载到 pod 中。使用案例：

• 注入工具和配置，无需臃肿的基础映像
• 加快 CI/CD 运行或短暂环境的速度
• 避免不必要的镜像重建
  虽然为时尚早，但我们处理人工制品的方式有望发生转变。

1.5 可以实际使用的安全性

• 服务帐户令牌的外部签名（Alpha）： 将令牌签名与控制平面分离。
• ProcMount 控制（Beta 版）： 与 /proc 的细粒度隔离。
• ClusterTrustBundles（测试版）： 从 Kubernetes 内部跨群集管理 CA 捆绑程序。
• 加密拉取镜像（Alpha）：保护依赖于凭证的镜像拉取： 保护依赖于凭证的镜像拉取。
• 安全与运行现实同步发展，而不是背道而驰。

1.6性能和调度器升级

• NUMA 感知调度（Beta）： AI/ML 和低延迟应用程序的理想选择。
• 异步抢占（测试版）： 在负载情况下保持调度程序的快速运行。
• 每 HPA 容差（Alpha）： 每个自动分压器的扩展逻辑更加细化。
  这些都是在繁忙集群中大规模扩展的小优势。

1.7以 DevOps 为重点的用户体验改进

• 有序的命名空间删除（Alpha）： 不再有卡死的终结器或僵尸资源。
• Pod 生成跟踪（Alpha）： 更容易跟踪配置偏移或推出问题。
• 索引作业（GA）： 更好地控制并行作业，例如 CI Worker 或 map-reduce 作业。
• 从节点状态中移除 kubeProxyVersion。
• Windows Pod 不再使用主机网络。

2、升级到稳定版

2.1索引作业的每个索引的延迟限制

在 Kubernetes 1.33 中，索引作业得到了改进，允许每个任务（索引）都有自己的重试限制（回退限制），而不是整个作业共享一个限制。以前，如果一个索引失败次数过多，即使其他任务仍然正常，整个作业也会停止。现在，每个索引的失败次数都会单独计算，因此即使某些索引失败，其他任务也能继续运行。这一变化为任务独立的大型并行工作负载提供了更精确的控制，类似于 AWS Batch 等服务所提供的功能。它还能让你使用 pod 失败策略停止重试特定的失败任务。

• 现在，每个索引都有重试的延迟限制。
• 每个索引单独计算失败次数。
• 即使某些任务失败，任务也能继续运行。
• 支持 pod 失败策略，以停止重试有问题的索引。
• 使 Kubernetes 更适合大型并行工作负载，如测试套件或批处理。

2.2 任务成功策略

在 Kubernetes 1.33 中，作业 API 得到了增强，允许用户定义自定义条件（成功策略），以确定何时应将索引作业视为成功。以前，只有当所有索引都成功时，作业才会被标记为完成，这对于 MPI 或 PyTorch 等只需要某些关键任务（如领导节点）成功的工作负载来说并不理想。现在，用户可以使用 .spec.successPolicy 设置规则，如要求特定的索引（supprocedIndexes）、最少的成功次数（supprocedCount）或两者兼而有之。一旦满足成功策略的要求，剩余的 pod 将自动终止。这一功能增强了对复杂批处理工作负载、领导者-工作者模式和部分完成场景的支持。

2.3 绑定服务帐户令牌的安全性增强

在 Kubernetes 1.33 中，通过在令牌中嵌入额外信息（如唯一令牌 ID (JTI) 和运行 Pod 的节点身份），服务帐户令牌的安全性得到了增强。这些改进可实现更强的验证、更好的审计，并防止令牌被滥用，如跨节点重放攻击。现在，服务账户令牌不仅可以绑定到 Pod 或 Secrets，还可以绑定到特定节点，确保令牌只在指定节点上有效。通过 KEP-4193 普及的这些功能改进了 Kubernetes 集群中预测令牌的安全性和信任模型。

2.4. Kubectl 子资源

由于 kubectl 命令（如 get、patch、edit、apply 和 replace）中的 --subresource 标志的普遍可用性，使用状态、缩放和调整大小等子资源变得更加容易。以前，用户不得不依赖繁琐的 kubectl --raw 调用或使用 curl 来获取或更新子资源，这对用户来说并不友好。现在，有了 KEP-2590，子资源在 kubectl 中被视为一等公民，这使得调试、测试和管理资源变得更加顺畅，内置资源和自定义资源也更加一致。

2.5 服务 CIDR

通过使用两个稳定的 API 进行新的实施，服务 IP 地址的分配方式得到了改进： ServiceCIDR 和 IPAddress。以前，服务 IP 管理有很多限制，例如无法动态扩展 IP 范围、API 服务器之间的 IP 冲突风险以及 CIDR 规模过小的 IPv6 问题。现在，群集管理员可以通过创建新的 ServiceCIDR 对象，为 ClusterIP 服务动态添加更多 IP 范围，从而提高可扩展性、一致性，并支持更大或重叠的网络。这一增强功能解决了长期存在的服务 IP 枯竭问题，帮助集群更好地处理 IPv4 和 IPv6 环境。

2.6 用于 kube-proxy 的 nftables 后端

用于 kube-proxy 的 nftables 后端现已稳定，可为管理服务提供更好的性能和可扩展性。传统上，Linux 上的 kube-proxy 使用 iptables，但随着 iptables 开发速度放缓和 nftables 变得越来越先进，Kubernetes 引入了官方 nftables 后端。虽然目前 iptables 仍是默认设置（出于兼容性考虑），但用户可以迁移到 nftables 以提高效率。这一转变为 nftables 未来最终取代 iptables 和 ipvs 后端奠定了基础。nftables 可以用更高效的规则集来处理成千上万的防火墙规则，而不是使用老式的 iptables 链（随着规则链的增加，速度会减慢），从而使服务流量更快、对系统的影响更小。

2.7 优先关闭

如果 A 区的 Pod 请求服务，Kubernetes 会首先尝试将流量路由到同样位于 A 区的端点，避免不必要的跨区跳转。现在，拓扑感知路由和流量分配已普遍可用，这让多区群集中的服务流量变得更加智能。利用 EndpointSlices 中的拓扑提示，kube-proxy 等组件可以将流量路由到同一区域内的端点，从而减少延迟并节省跨区域网络成本。服务规范中新增的流量分布字段（取代了旧的拓扑关键字和注释）可让用户控制路由行为。设置 PreferClose 优先将请求发送到最近的健康端点。

2.8 不拒绝 SMT 对齐的工作负载。

CPU 管理器现在支持 SMT 感知策略，确保在具有同步多线程（SMT）功能的系统上更好地隔离对延迟敏感的工作负载。当 pod 请求独占 CPU 内核时，CPU 管理器现在可以拒绝无法与 SMT 正确对齐的工作负载，这意味着它会分配完整的内核对（包括主线程和同级线程），而不是部分内核对。这可以防止无意中共享物理 CPU，提高关键应用程序的性能和可预测性。
在启用了 SMT 的服务器上，如果一个 pod 需要 CPU 独占权，Kubernetes 将同时分配两个硬件线程（例如，同一内核上的 CPU 0 和 CPU 1），而不是只分配一个，以避免其他 pod 的干扰。

2.9使用 matchLabelKeys 和 mismatchLabelKeys 实现 Pod 亲和或反亲和

如果希望新 Pod 在部署过程中优先选择具有相似应用程序版本的节点，但避免新旧版本混合，现在只需指定 matchLabelKeys： [matchLabelKeys 和 mismatchLabelKeys 现在在 Pod Affinity 和 AntiAffinity 规则中是稳定的，让用户可以更精细地控制 Pod 应该或不应该共存的位置。这些字段是对旧的 labelSelector 方法的补充，有助于调度程序做出更明智的决定，尤其是在滚动更新期间或隔离由不同控制器管理的服务时。

2.10 计算 Pod 拓扑扩展偏差时考虑污点和容忍度

PodTopologySpread 增加了两个新字段：节点亲和力策略（nodeAffinityPolicy）和节点污点策略（nodeTaintsPolicy）。这些设置可让用户控制在计算 Pod 在节点间的分布时是否考虑节点亲和规则和节点污点。默认情况下，nodeAffinityPolicy 设置为 Honor（只考虑符合 pod 亲和规则的节点），nodeTaintsPolicy 设置为 Ignore（除非指定，否则忽略污点）。这将确保 pod 在尊重其调度限制的同时得到更好的分布，从而降低 pod 陷入待处理状态的几率。
如果你的 pod 只能容忍 “高性能 ”节点污点，并对 “sd ”节点有亲和力，Kubernetes 现在只会将它们分散到匹配的可用节点上，而不是对所有节点一视同仁。

2.11 卷填充器

卷填充器升级为 GA，使用户能够使用来自 PVC 克隆和卷快照以外各种来源的数据填充卷。现在，PersistentVolumeClaim (PVC) 中的 dataSourceRef 字段提供了更大的灵活性，支持将自定义资源作为数据源。卷填充器通过新的自定义资源定义（CustomResourceDefinition，CRD）进行注册，卷数据源验证器控制器可确保使用有效的数据源。与旧的 dataSource 字段不同，dataSourceRef 不会默默忽略不支持的数据源，从而提高了可靠性。

2.12 持久卷回收策略

得益于新的终结者机制，如果 PV 在其 PVC 之前被删除，Kubernetes 仍将执行回收策略（就像删除底层存储一样）。Kubernetes 1.33 解决了（PV）回收策略不能始终得到遵守的问题。当一个 PV 在其关联的持久卷索赔（PVC）之前被删除时，“删除 ”回收策略可能不会触发，从而留下存储资源。Kubernetes 现在对 PV bs blo dtlr 应用终结器，确保始终执行回收策略，即使删除顺序不正确也是如此。这可以防止无意中保留存储资产，并确保 PV 生命周期管理的一致性。

3. 测试版功能

对于测试版功能，我将介绍特别有趣的功能。不过，如果您想了解更多，这里提供了所有值得注意的功能。

3.1结构化参数支持

该增强功能通过添加新的 Devices 字段改进了 ResourceClaim.Status，允许驱动程序报告详细的设备状态信息（如 IP 或配置详情）。这有助于 Kubernetes 更自然地与网络硬件集成，从而更容易观察、排除故障和开发网络功能。当网络设备分配给 Pod 时，Kubernetes 现在可以通过 API 直接显示设备的 IP 地址和状态，帮助网络服务自动配置。

3.2异步抢占

异步抢占（Asynchronous Preemption）已推进到测试版，改进了优先级较高的 Pod 的调度方式。传统上，抢占（驱逐优先级较低的 Pod）会阻塞调度程序，直到 API 调用（如 Pod 删除）完成。现在，重度操作被并行处理，调度程序无需等待即可继续调度其他 Pod。这提高了效率，尤其是在 Pod 流失率高或调度重试频繁的集群中。如果关键工作负载需要空间，调度程序可以开始删除优先级较低的 Pod，并立即继续调度其他 Pod，而无需在每次删除完成后暂停。

3.3将映像挂载为卷

将 OCI 映像作为卷的支持已进入测试阶段。这一增强功能可让用户将存储在 OCI 镜像中的文件直接作为卷附加到 Pod 中，而无需将其嵌入到主容器镜像中。它减少了漏洞，提高了可重用性，并简化了映像管理。

4. Alpha版功能

我们将再次关注特别有趣的功能（个人观点）。

4.1可配置的容器重启延迟和 HPA 容限

现在，您可以调整每个 HPA 资源的扩展容差。以前，10% 的容差是全局性的；微小的指标变化不会触发缩放。现在，为了实现更精细的控制，您可以设置自定义容差（例如 5%），从而允许对较小的指标变化进行缩放。此外，CrashLoopBackoff 现在的初始后退时间为 1 秒（低于 10 秒），最大后退时间为 1 分钟（低于 5 分钟）。

4.2 DRA 增强

现在，这一点我还不能百分百确定，因为整个方案都是可测试的，因此还没有进行太多的探索。不过，概括来说，设备现在可以像节点一样使用污点和容忍度，允许管理员限制访问，例如，污点 GPU 以将其限制在特定工作负载中。设备请求中新增的 firstAvailable 字段可让 pod 灵活地偏好一种设备类型，但在不可用的情况下又会使用另一种设备类型，例如偏好 GPU，但在需要时又会接受 CPU。管理 ResourceClaims 的管理员访问权限现在可以使用 resource.k8s.io/admin-access： “true "标签来限制某些命名空间的管理员访问权限，以确保更严格的控制。最后，设备供应商可以在运行时动态宣传和分配分区，而不需要预先分区。例如，大型存储设备可根据工作负载需求自动分割成更小的分区，从而提高资源利用率，而无需用户干预。
KEP-5055：DRA：设备污点和容差
KEP-4816: DRA：设备请求中的优先替代方案
KEP-5018： DRA：资源索赔和资源索赔模板的管理访问
KEP-4815： DRA: 增加对可分区设备的支持

4.3无秘图像拉取

kubelet 的磁盘凭据提供者现在支持可选获取 Kubernetes ServiceAccount (SA) 令牌，以便拉取映像。这一改进实现了图像注册的 “无秘 ”身份验证流，将图像拉取授权直接与 pod 的身份绑定，而无需依赖 API 中存储的长期凭据。通过利用与 OIDC 标准兼容的短暂自动旋转令牌，云提供商可以更好地将 Kubernetes 工作负载与外部身份解决方案集成。例如，一个 pod 现在可以使用其短暂的 SA 令牌从私有注册中心安全地拉取图像，而不是依赖静态图像拉取秘钥或节点范围的凭据提供商，从而提高安全性并减少运营开销。

5. 小结

Kubernetes 1.33 发布标志着在安全性、可扩展性和开发者体验方面的重大进步。建议用户根据自身需求评估新功能的适用性，并规划相应的升级策略。是一个面向操作的版本。它减少了辛劳、加强了安全性、改善了运行时的控制–所有这些都是战壕里的团队的胜利。

6. 资源

Kubernetes 1.33 Release Notes — release notes
升级、折旧和删除：— https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/#graduations-deprecations-and-removals-in-v1-33

https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/?source=post_page-----2daead6b9fb4---------------------------------------