Kubernetes v1.33:Octarine
编辑: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav
与之前版本类似,Kubernetes v1.33 版本引入了新的稳定 (stable)、Beta 和 Alpha 特性。持续交付高质量版本彰显了我们开发周期的强大以及社区充满活力的支持。
此版本包含 64 项增强功能。其中,18 项已升级到稳定 (Stable),20 项进入 Beta 阶段,24 项进入 Alpha 阶段,另有 2 项已弃用或撤回。
此版本中还有多项值得关注的弃用和移除;如果您运行的是旧版本 Kubernetes,请务必阅读相关内容。
发布主题和标志
Kubernetes v1.33 的主题是 Octarine:魔法之色1,灵感来自 Terry Pratchett 的《碟形世界》系列。此版本突出了 Kubernetes 在整个生态系统中带来的开源魔力2。
如果您熟悉《碟形世界》的世界,您可能会认出那只栖息在隐形大学塔顶的小沼泽龙,抬头仰望着 Ankh-Morpork 城上空的 Kubernetes 月亮,背景中有 64 颗星星3。
随着 Kubernetes 进入第二个十年,我们共同庆祝其维护者的魔法般技艺、新贡献者的好奇心以及推动项目发展的协作精神。v1.33 版本提醒我们,正如 Pratchett 所写,“即使你知道它是怎么做到的,它仍然是魔法。” 即使您了解 Kubernetes 代码库的来龙去脉,在发布周期结束时回顾,您会意识到 Kubernetes 仍然充满魔力。
Kubernetes v1.33 证明了开源创新的持久力量,全球数百名贡献者4共同努力创造了非凡的成果。在每一个新特性背后,Kubernetes 社区都在努力维护和改进项目,确保其安全、可靠并按时发布。每个版本都建立在前一个版本之上,创造出比我们单独行动更伟大的事物。
1. Octarine 是神话中的第八种颜色,只有那些对奥术敏感的人才能看到——巫师、女巫,当然还有猫。偶尔,也包括盯着 IPtables 规则看了太久的人。
2. 任何足够先进的技术都与魔法无异……?
3. v1.33 中包含 64 个 KEP(Kubernetes Enhancement Proposals)并非巧合。
4. 请参阅 v1.33 的项目速度部分 🚀
关键更新亮点
Kubernetes v1.33 包含了大量新功能和改进。以下是发布团队希望重点介绍的一些精选更新!
稳定 (Stable):Sidecar 容器
Sidecar 模式涉及部署独立的辅助容器来处理网络、日志记录和指标收集等领域的额外能力。Sidecar 容器在 v1.33 中升级到稳定阶段。
Kubernetes 将 Sidecar 实现为具有 restartPolicy: Always
的一种特殊类型的初始化容器 (init container),确保 Sidecar 在应用容器之前启动,在 Pod 的生命周期内保持运行,并在主容器退出后自动终止。
此外,Sidecar 可以利用探针(启动、就绪、存活)来指示其操作状态,并且其内存不足 (OOM) 分数调整与主容器对齐,以防止在内存压力下过早终止。
要了解更多信息,请阅读Sidecar 容器。
这项工作是 KEP-753: Sidecar 容器 的一部分,由 SIG Node 领导。
Beta:Pod 纵向扩缩容的原地资源调整
可以使用 Deployment、StatefulSet 等 API 定义工作负载。这些 API 描述了应运行的 Pod 的模板,包括内存和 CPU 资源,以及应运行的 Pod 的副本数量。工作负载可以通过更新 Pod 副本数量进行水平扩缩容,或者通过更新 Pod 容器中所需的资源进行纵向扩缩容。在此增强功能之前,Pod 的 spec
中定义的容器资源是不可变的,更新 Pod 模板中的任何这些细节都会触发 Pod 重建。
但是,如果您可以在不重启现有 Pod 的情况下动态更新其资源配置,会怎么样?
此 KEP-1287 正是为了实现此类 Pod 原地更新。此功能在 v1.27 中以 Alpha 状态发布,并在 v1.33 中升级到 Beta 阶段。这为有状态进程的纵向扩容提供了各种可能性,无需停机;流量较低时无缝缩容;甚至可以在启动期间分配更大的资源,然后在初始设置完成后再进行缩减。
这项工作是 KEP-1287: Pod 资源原地更新 的一部分,由 SIG Node 和 SIG Autoscaling 领导。
Alpha:kubectl 新增 .kuberc
用户偏好配置选项
在 v1.33 中,kubectl
引入了一个新的 Alpha 功能,通过可选的配置文件 .kuberc
来设置用户偏好。此文件可以包含 kubectl
别名和覆盖设置(例如,默认使用 server-side apply),同时将集群凭证和主机信息保留在 kubeconfig 中。这种分离使得无论使用哪个目标集群和 kubeconfig,都可以共享相同的用户偏好来进行 kubectl
交互。
要启用此 Alpha 功能,用户可以设置环境变量 KUBECTL_KUBERC=true
并创建一个 .kuberc
配置文件。默认情况下,kubectl
会在 ~/.kube/kuberc
中查找此文件。您还可以使用 --kuberc
标志指定备用位置,例如:kubectl --kuberc /var/kube/rc
。
这项工作是 KEP-3104: 从集群配置中分离 kubectl 用户偏好 的一部分,由 SIG CLI 领导。
升级到稳定阶段的功能
以下是 v1.33 版本后已达到稳定阶段的一些精选改进。
Indexed Job 的单索引回退限制
此版本推出了一项新功能,允许为 Indexed Job 设置按索引维度的回退限制。传统上,Kubernetes Job 中的 backoffLimit
参数指定了在将整个 Job 视为失败之前允许的重试次数。此增强功能允许 Indexed Job 中的每个索引拥有自己的回退限制,从而对单个任务的重试行为进行更精细的控制。这确保了特定索引的失败不会过早终止整个 Job,允许其他索引独立继续处理。
这项工作是 KEP-3850: Indexed Job 的单索引回退限制 的一部分,由 SIG Apps 领导。
Job 成功策略
使用 .spec.successPolicy
,用户可以指定哪些 Pod 索引必须成功(succeededIndexes
)、有多少 Pod 必须成功(succeededCount
),或两者的组合。此功能适用于各种工作负载,包括部分完成即被视为成功的模拟,以及仅 leader 成功就决定 Job 整体结果的 leader-worker 模式。
这项工作是 KEP-3998: Job 成功/完成策略 的一部分,由 SIG Apps 领导。
绑定 ServiceAccount Token 安全性改进
此增强功能引入了多项特性,例如在 Token 中包含唯一的 Token 标识符(即 JWT ID Claim,亦称 JTI)和节点信息,从而实现更精确的验证和审计。此外,它支持节点特定限制,确保 Token 仅可在指定节点上使用,从而降低 Token 滥用和潜在安全漏洞的风险。这些改进现已正式可用 (GA),旨在增强 Kubernetes 集群中 Service Account Token 的整体安全态势。
这项工作是 KEP-4193: 绑定 Service Account Token 改进 的一部分,由 SIG Auth 领导。
kubectl 中的子资源支持
--subresource
参数现已正式可用 (GA),适用于 kubectl 子命令,例如 get
、patch
、edit
、apply
和 replace
,允许用户获取和更新所有支持子资源的资源的子资源。要了解更多支持的子资源,请访问 kubectl 参考。
这项工作是 KEP-2590: 为 kubectl 添加子资源支持 的一部分,由 SIG CLI 领导。
多 Service CIDR
此增强功能引入了 Service IP 分配逻辑的新实现。在整个集群中,每个 type: ClusterIP
的 Service 都必须分配一个唯一的 IP 地址。尝试创建具有已分配的特定集群 IP 的 Service 将返回错误。更新后的 IP 地址分配器逻辑使用了两个新的稳定 API 对象:ServiceCIDR
和 IPAddress
。这些 API 现已正式可用 (GA),允许集群管理员动态增加 type: ClusterIP
Service 的可用 IP 地址数量(通过创建新的 ServiceCIDR 对象)。
这项工作是 KEP-1880: 多 Service CIDR 的一部分,由 SIG Network 领导。
kube-proxy 的 nftables
后端
kube-proxy 的 nftables
后端现已稳定,它增加了一个新的实现,显着提高了 Kubernetes 集群内 Service 实现的性能和可伸缩性。出于兼容性考虑,在 Linux 节点上 iptables
仍然是默认设置。如果您想尝试,请查看迁移指南。
这项工作是 KEP-3866: kube-proxy 的 nftables 后端 的一部分,由 SIG Network 领导。
使用 trafficDistribution: PreferClose
的拓扑感知路由
此版本将拓扑感知路由和流量分发升级到正式可用 (GA),这将使我们能够在多区域集群中优化 Service 流量。EndpointSlice 中的拓扑感知提示将使 kube-proxy 等组件能够优先将流量路由到同一区域内的端点,从而降低延迟和跨区域数据传输成本。在此基础上,Service 规范中新增了 trafficDistribution
字段,其中 PreferClose
选项根据网络拓扑将流量导向最近的可用端点。此配置通过最大程度地减少区域间通信来提升性能和成本效率。
这项工作是 KEP-4444: Service 的流量分发 和 KEP-2433: 拓扑感知路由 的一部分,由 SIG Network 领导。
拒绝非 SMT 对齐工作负载的选项
此功能向 CPU Manager 添加了策略选项,使其能够拒绝与同时多线程 (SMT) 配置不对齐的工作负载。此增强功能现已正式可用 (GA),确保当 Pod 请求独占使用 CPU 核心时,CPU Manager 可以在启用 SMT 的系统上强制分配整个核心对(包含主线程和 sibling 线程),从而防止工作负载以非预期方式共享 CPU 资源的情况。
这项工作是 KEP-2625: 节点:cpumanager:添加选项以拒绝非 SMT 对齐工作负载 的一部分,由 SIG Node 领导。
使用 matchLabelKeys
和 mismatchLabelKeys
定义 Pod affinity 或 anti-affinity
matchLabelKeys
和 mismatchLabelKeys
字段可在 Pod affinity 术语中使用,使用户能够精细控制 Pod 预期共存 (Affinity) 或不共存 (AntiAffinity) 的范围。这些新的稳定选项补充了现有的 labelSelector
机制。affinity 字段有助于增强调度以实现灵活的滚动更新,并隔离由工具或控制器基于全局配置管理的服务。
这项工作是 KEP-3633: 为 Pod Affinity 和 Pod Anti Affinity 引入 MatchLabelKeys 的一部分,由 SIG Scheduling 领导。
计算 Pod 拓扑分布倾斜时考虑 taints 和 tolerations
此增强功能通过引入两个字段增强了 PodTopologySpread
:nodeAffinityPolicy
和 nodeTaintsPolicy
。这些字段允许用户指定在计算跨节点 Pod 分布时是否应考虑节点 affinity 规则和节点 taints。默认情况下,nodeAffinityPolicy
设置为 Honor
,这意味着只有匹配 Pod 节点 affinity 或 selector 的节点才会包含在分布计算中。nodeTaintsPolicy
默认为 Ignore
,表示除非指定,否则不考虑节点 taints。此增强功能提供了对 Pod 放置的更精细控制,确保 Pod 调度到满足 affinity 和 taint 容忍度要求的节点上,从而防止 Pod 因约束未满足而处于 Pending 状态的情况。
这项工作是 KEP-3094: 计算 PodTopologySpread 倾斜时考虑 taints/tolerations 的一部分,由 SIG Scheduling 领导。
卷填充器
在 v1.24 中以 Beta 状态发布后,卷填充器在 v1.33 中升级到正式可用 (GA)。这项新的稳定功能提供了一种方式,允许用户使用来自各种源的数据预填充卷,而不仅仅是来自 PersistentVolumeClaim (PVC) 克隆或卷快照。此机制依赖于 PersistentVolumeClaim 中的 dataSourceRef
字段。此字段比现有的 dataSource
字段提供了更大的灵活性,并允许使用自定义资源作为数据源。
一个特殊的控制器,volume-data-source-validator
,以及一个新的稳定 CustomResourceDefinition (CRD),用于名为 VolumePopulator 的 API Kind,共同验证这些数据源引用。VolumePopulator API 允许卷填充器控制器注册它们支持的数据源类型。您需要使用适当的 CRD 设置集群才能使用卷填充器。
这项工作是 KEP-1495: 通用数据填充器 的一部分,由 SIG Storage 领导。
始终遵守 PersistentVolume 回收策略
此增强功能解决了 PersistentVolume (PV) 回收策略未始终遵守的问题,该问题可能导致潜在的存储资源泄露。具体而言,如果在关联的 PersistentVolumeClaim (PVC) 之前删除了 PV,则可能不会执行“删除”回收策略,导致底层存储资产保持不变。为了缓解此问题,Kubernetes 现在在相关的 PV 上设置了 Finalizer,确保无论删除顺序如何,都将执行回收策略。此增强功能可防止意外保留存储资源,并维护 PV 生命周期管理的一致性。
这项工作是 KEP-2644: 始终遵守 PersistentVolume 回收策略 的一部分,由 SIG Storage 领导。
Beta 阶段的新功能
以下是 v1.33 版本后已达到 Beta 阶段的一些精选改进。
Windows kube-proxy 中对 Direct Service Return (DSR) 的支持
DSR 通过允许路由经过负载均衡器的返回流量绕过负载均衡器直接响应客户端,从而提供性能优化;这减少了负载均衡器的负载,也降低了整体延迟。有关 Windows 上 DSR 的信息,请阅读Direct Server Return (DSR) 概述。
DSR 支持最初在 v1.14 中引入,现已由 SIG Windows 作为 KEP-5100: 支持 Windows kube-proxy 中的 Direct Service Return (DSR) 和覆盖网络 的一部分升级到 Beta 阶段。
结构化参数支持
尽管结构化参数支持在 Kubernetes v1.33 中仍然是 Beta 功能,但此动态资源分配 (DRA) 的核心部分已获得显着改进。新的 v1beta2 版本简化了 resource.k8s.io
API,并且拥有命名空间级别集群 edit
角色的普通用户现在可以使用 DRA。
kubelet
现在包含无缝升级支持,使作为 DaemonSets 部署的驱动程序能够使用滚动更新机制。对于 DRA 实现,这可以防止 ResourceSlices 被删除和重新创建,从而允许它们在升级期间保持不变。此外,kubelet
在取消注册驱动程序之前引入了 30 秒的宽限期,为不使用滚动更新的驱动程序提供了更好的支持。
这项工作是作为由 WG Device Management(一个包含 SIG Node、SIG Scheduling 和 SIG Autoscaling 的跨职能团队)进行的 KEP-4381: DRA: structured parameters 的一部分完成的。
网络接口的动态资源分配 (DRA)
通过 DRA 实现的网络接口标准化报告在 v1.32 中引入,并已在 v1.33 中升级到 Beta。这使得更原生的 Kubernetes 网络集成成为可能,简化了网络设备的开发和管理。这一点先前已在v1.32 版本发布公告博客中介绍过。
这项工作是作为由 SIG Network、SIG Node 和 WG Device Management 牵头的 KEP-4817: DRA: Resource Claim Status with possible standardized network interface data 的一部分完成的。
在调度器 activeQ 没有 Pod 时尽早处理未调度的 Pod
此功能改善了队列调度行为。在底层,调度器通过在 activeQ 为空时,从 *backoffQ* 中弹出未因错误而延迟的 Pod 来实现这一点。之前,即使 activeQ 为空,调度器也会进入空闲状态;此增强功能通过防止这种情况来提高调度效率。
这项工作是作为由 SIG Scheduling 牵头的 KEP-5142: Pop pod from backoffQ when activeQ is empty 的一部分完成的。
Kubernetes 调度器中的异步抢占
抢占通过驱逐低优先级 Pod 来确保高优先级 Pod 获得所需的资源。异步抢占于 v1.32 中作为 Alpha 引入,并已在 v1.33 中升级到 Beta。通过此增强功能,诸如删除 Pod 的 API 调用等繁重操作可以并行处理,从而使调度器能够继续调度其他 Pod 而不产生延迟。此改进在 Pod 频繁创建/销毁或调度频繁失败的集群中特别有益,可确保更高效、更具弹性的调度过程。
这项工作是作为由 SIG Scheduling 牵头的 KEP-4832: Asynchronous preemption in the scheduler 的一部分完成的。
ClusterTrustBundles
ClusterTrustBundle 是一种集群范围的资源,用于存放 X.509 信誉锚(根证书),已在 v1.33 中升级到 Beta。此 API 使集群内证书签名者更容易向集群工作负载发布和通信 X.509 信誉锚。
这项工作是作为由 SIG Auth 牵头的 KEP-3257: ClusterTrustBundles (previously Trust Anchor Sets) 的一部分完成的。
细粒度 SupplementalGroups 控制
此功能于 v1.31 中引入,在 v1.33 中升级到 Beta,现已默认启用。如果集群启用了 SupplementalGroupsPolicy
特性门,则 Pod securityContext
中的 supplementalGroupsPolicy
字段支持两种策略:默认的 Merge 策略通过将指定组与容器镜像的 /etc/group
文件中的组相结合来保持向后兼容性,而新的 Strict 策略仅适用于显式定义的组。
此增强功能有助于解决安全问题,其中来自容器镜像的隐式组成员身份可能导致意外的文件访问权限并绕过策略控制。
这项工作是作为由 SIG Node 牵头的 KEP-3619: Fine-grained SupplementalGroups control 的一部分完成的。
支持将镜像挂载为卷
在 Pod 中使用开放容器倡议(OCI)镜像作为卷的支持于 v1.31 中引入,现已升级到 Beta。此功能允许用户在 Pod 中将镜像引用指定为卷,并在容器中将其重用为卷挂载。它开辟了单独打包卷数据的可能性,并在 Pod 中的容器之间共享它们,而无需将其包含在主镜像中,从而减少了漏洞并简化了镜像创建。
这项工作是作为由 SIG Node 和 SIG Storage 牵头的 KEP-4639: VolumeSource: OCI Artifact and/or Image 的一部分完成的。
Linux Pod 中对用户命名空间的支持
截至撰写本文时,最古老的未关闭 KEP 之一是 KEP-127,它通过使用 Linux 用户命名空间来改进 Pod 安全性。此 KEP 最初于 2016 年末提出,经过多次迭代,于 v1.25 中发布了 Alpha 版本,在 v1.30 中首次发布 Beta 版本(当时默认禁用),并作为 v1.33 的一部分升级到默认启用 Beta 版本。
此支持不会影响现有 Pod,除非手动指定 pod.spec.hostUsers
选择启用。正如v1.30 预告博客中所强调的,这是缓解漏洞的重要里程碑。
这项工作是作为由 SIG Node 牵头的 KEP-127: Support User Namespaces in pods 的一部分完成的。
Pod procMount
选项
procMount
选项于 v1.12 中作为 Alpha 引入,在 v1.31 中作为默认禁用 Beta,现已在 v1.33 中升级到默认启用 Beta。此增强功能通过允许用户微调对 /proc
文件系统的访问来改善 Pod 隔离。具体来说,它在 Pod securityContext
中添加了一个字段,允许覆盖屏蔽某些 /proc
路径并将其标记为只读的默认行为。这对于用户希望在使用用户命名空间的 Kubernetes Pod 内部运行非特权容器的场景特别有用。通常,容器运行时(通过 CRI 实现)以严格的 /proc
挂载设置启动外部容器。然而,为了成功运行带有非特权 Pod 的嵌套容器,用户需要一种机制来放松这些默认设置,而此功能正好提供了这一点。
这项工作是作为由 SIG Node 牵头的 KEP-4265: add ProcMount option 的一部分完成的。
CPUManager 策略以跨 NUMA 节点分配 CPU
此功能为 CPU Manager 添加了一个新的策略选项,用于将 CPU 分配到跨非统一内存访问 (NUMA) 节点,而不是将其集中在单个节点上。它通过在多个 NUMA 节点之间平衡工作负载来优化 CPU 资源分配,从而提高多 NUMA 系统中的性能和资源利用率。
这项工作是作为由 SIG Node 牵头的 KEP-2902: Add CPUManager policy option to distribute CPUs across NUMA nodes instead of packing them 的一部分完成的。
容器 PreStop 钩子的零秒睡眠
Kubernetes 1.29 为 Pod 中的 preStop
生命周期钩子引入了 Sleep 操作,允许容器在终止前暂停指定的持续时间。这提供了一种简单直接的方法来延迟容器关闭,从而方便连接排空或清理操作等任务。
现在,preStop
钩子中的 Sleep 操作可以接受零秒持续时间作为 Beta 功能。这允许定义一个无操作的 preStop
钩子,这在需要 preStop
钩子但不希望有延迟时很有用。
这项工作是作为由 SIG Node 牵头的 KEP-3960: Introducing Sleep Action for PreStop Hook 和 KEP-4818: Allow zero value for Sleep Action of PreStop Hook 的一部分完成的。
用于 Kubernetes 原生类型声明式验证的内部工具
在底层,Kubernetes 内部正在开始使用一种新的机制来验证对象和对象变更。Kubernetes v1.33 引入了 validation-gen
,这是 Kubernetes 贡献者用来生成声明式验证规则的内部工具。总体目标是通过允许开发人员声明式地指定验证约束来提高 API 验证的健壮性和可维护性,从而减少手动编码错误并确保代码库的一致性。
这项工作是作为由 SIG API Machinery 牵头的 KEP-5073: Declarative Validation Of Kubernetes Native Types With validation-gen 的一部分完成的。
Alpha 版中的新功能
以下是在 v1.33 版本发布后进入 Alpha 阶段的一些改进:
HorizontalPodAutoscalers 的可配置容差
此功能为 HorizontalPodAutoscalers 引入了可配置的容差,可减弱对微小指标变化的扩展反应。
这项工作是作为由 SIG Autoscaling 牵头的 KEP-4951: Configurable tolerance for Horizontal Pod Autoscalers 的一部分完成的。
可配置的容器重启延迟
此功能于 v1.32 中作为 Alpha1 引入,提供了一组 kubelet 级别配置,可微调 CrashLoopBackOff 的处理方式。
这项工作是作为由 SIG Node 牵头的 KEP-4603: Tune CrashLoopBackOff 的一部分完成的。
自定义容器停止信号
在 Kubernetes v1.33 之前,停止信号只能在容器镜像定义中设置(例如,通过镜像元数据中的 StopSignal
配置字段)。如果想修改终止行为,需要构建自定义容器镜像。通过在 Kubernetes v1.33 中启用(Alpha)ContainerStopSignals
特性门,现在可以直接在 Pod 规范中定义自定义停止信号。这在容器的 lifecycle.stopSignal
字段中定义,并且需要存在 Pod 的 spec.os.name
字段。如果未指定,容器将回退到镜像定义的停止信号(如果存在),或容器运行时默认值(Linux 通常为 SIGTERM)。
这项工作是作为由 SIG Node 牵头的 KEP-4960: Container Stop Signals 的一部分完成的。
DRA 增强功能 galore!
Kubernetes v1.33 继续开发动态资源分配(DRA),并引入了专为当今复杂基础设施设计的功能。DRA 是一种 API,用于在 Pod 和 Pod 内的容器之间请求和共享资源。通常这些资源是 GPU、FPGA 和网络适配器等设备。
以下是 v1.33 中引入的所有 Alpha DRA 特性门:
- 与 Node 污点类似,通过启用
DRADeviceTaints
特性门,设备支持污点和容忍。管理员或控制平面组件可以对设备设置污点以限制其使用。依赖于这些设备的 Pod 的调度可以在存在污点时暂停,并且/或者使用带有污点设备的 Pod 可以被驱逐。 - 通过启用特性门
DRAPrioritizedList
,DeviceRequests 获得了一个名为firstAvailable
的新字段。此字段是一个有序列表,允许用户指定请求可以通过不同方式满足,包括在特定硬件不可用时根本不分配任何资源。 - 启用特性门
DRAAdminAccess
后,只有被授权在标记为resource.k8s.io/admin-access: "true"
的命名空间中创建 ResourceClaim 或 ResourceClaimTemplate 对象的用户才能使用adminAccess
字段。这确保了非管理员用户无法滥用adminAccess
功能。 - 虽然自 v1.31 起就可以使用设备分区,但供应商必须预先分区设备并进行相应的广告。通过在 v1.33 中启用
DRAPartitionableDevices
特性门,设备供应商可以广告多个分区,包括重叠的分区。Kubernetes 调度器将根据工作负载请求选择分区,并防止同时分配冲突的分区。此功能使供应商能够在分配时动态创建分区。分配和动态分区是自动且对用户透明的,从而提高了资源利用率。
除非您同时启用 DynamicResourceAllocation
特性门,否则这些特性门不会生效。
这项工作是作为由 SIG Node、SIG Scheduling 和 SIG Auth 牵头的 KEP-5055: DRA: device taints and tolerations、KEP-4816: DRA: Prioritized Alternatives in Device Requests、KEP-5018: DRA: AdminAccess for ResourceClaims and ResourceClaimTemplates 和 KEP-4815: DRA: Add support for partitionable devices 的一部分完成的。
强大的镜像拉取策略,用于验证 IfNotPresent
和 Never
镜像的身份
此功能允许用户确保 kubelet 对每组新凭证都需要进行镜像拉取身份验证检查,无论镜像是否已存在于节点上。
这项工作是作为由 SIG Auth 牵头的 KEP-2535: Ensure secret pulled images 的一部分完成的。
节点拓扑标签通过 downward API 可用
此功能使节点拓扑标签可通过 downward API 公开。在 Kubernetes v1.33 之前,一种变通方法是使用 init 容器查询 Kubernetes API 以获取底层节点信息;此 Alpha 功能简化了工作负载访问节点拓扑信息的方式。
这项工作是作为由 SIG Node 牵头的 KEP-4742: Expose Node labels via downward API 的一部分完成的。
通过 generation 和 observed generation 改进 Pod 状态
在此变更之前,Pod 中未使用 metadata.generation
字段。除了扩展以支持 metadata.generation
之外,此功能还将引入 status.observedGeneration
以提供更清晰的 Pod 状态。
这项工作是作为由 SIG Node 牵头的 KEP-5067: Pod Generation 的一部分完成的。
kubelet CPU Manager 对分层 3 级缓存架构的支持
之前的 kubelet CPU Manager 不了解分层 L3 缓存架构(也称为 Last Level Cache,或 LLC),并且在分配 CPU 时可能不考虑分层 L3 缓存,从而导致“邻居噪音”问题。此 Alpha 功能改进了 CPU Manager,以更好地分配 CPU 核心以获得更好的性能。
这项工作是作为由 SIG Node 牵头的 KEP-5109: Split L3 Cache Topology Awareness in CPU Manager 的一部分完成的。
PSI(压力停顿信息)指标用于调度改进
此功能增加了对 Linux 节点的支持,使用 cgroupv2 提供 PSI 统计信息和指标。它可以检测资源短缺,并为节点提供更细粒度的 Pod 调度控制。
这项工作是作为由 SIG Node 牵头的 KEP-4205: Support PSI based on cgroupv2 的一部分完成的。
使用 kubelet 实现无 Secret 的镜像拉取
kubelet 的磁盘凭证提供程序现在支持可选的 Kubernetes ServiceAccount(SA)令牌获取。这通过允许云提供商更好地集成 OIDC 兼容身份解决方案来简化与镜像仓库的身份验证。
这项工作是作为由 SIG Auth 牵头的 KEP-4412: Projected service account tokens for Kubelet image credential providers 的一部分完成的。
v1.33 中的升级、弃用和移除
升级到 Stable
这列出了所有已升级到 Stable(也称为*普遍可用*)的功能。有关包括新功能和从 Alpha 升级到 Beta 在内的所有更新的完整列表,请参阅发行说明。
此版本总共有 18 项增强功能升级到 Stable
- 在计算 PodTopologySpread skew 时考虑污点/容忍
- 在 Pod Affinity 和 Pod Anti Affinity 中引入
MatchLabelKeys
- Bound Service Account 令牌改进
- 通用数据填充器
- 多 Service CIDR
- 拓扑感知路由
- Portworx 文件树内迁移到 CSI 驱动程序
- 始终遵守 PersistentVolume 回收策略
- nftables kube-proxy 后端
- 弃用 status.nodeInfo.kubeProxyVersion 字段
- 为 kubectl 添加子资源支持
- 针对索引 Jobs 的每索引回退限制
- Job 成功/完成策略
- Sidecar 容器
- CRD 验证棘轮
- node: cpumanager: 添加选项以拒绝非 SMT 对齐的工作负载
- 服务的流量分发
- 递归只读 (RRO) 挂载
弃用和移除
随着 Kubernetes 的发展和成熟,某些功能可能会被弃用、移除或替换为更好的功能,以提高项目的整体健康状况。有关此过程的更多详细信息,请参阅 Kubernetes弃用和移除策略。其中许多弃用和移除已在v1.33 弃用和移除博客文章中宣布。
弃用 Stable Endpoints API
EndpointSlices API 自 v1.21 起已稳定,有效地取代了原始的 Endpoints API。虽然原始 Endpoints API 简单直观,但在扩展到大量网络端点时也带来了一些挑战。EndpointSlices API 引入了双栈网络等新功能,使原始 Endpoints API 适合弃用。
此弃用仅影响直接从工作负载或脚本使用 Endpoints API 的用户;这些用户应迁移以使用 EndpointSlices。将有一篇专门的博客文章提供有关弃用影响和迁移计划的更多详细信息。
可以在 KEP-4974: Deprecate v1.Endpoints 中找到更多信息。
移除节点状态中的 kube-proxy 版本信息
继 v1.31 中弃用该字段后,如 v1.31 发布公告中所强调的,Nodes 的 .status.nodeInfo.kubeProxyVersion
字段已在 v1.33 中移除。
此字段由 kubelet 设置,但其值不始终准确。由于自 v1.31 起已默认禁用,此字段已在 v1.33 中完全移除。
可以在 KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field 中找到更多信息。
移除树内 gitRepo 卷驱动
gitRepo 卷类型自 v1.11 起已被弃用,距今已有近 7 年。自弃用以来,存在安全问题,包括如何利用 gitRepo 卷类型在节点上以 root 身份执行远程代码。在 v1.33 中,树内驱动代码被移除。
存在 git-sync 和 initContainers 等替代方案。Kubernetes API 中的 gitVolumes
并未移除,因此带有 gitRepo
卷的 Pod 将被 kube-apiserver 准入,但将 feature-gate GitRepoVolumeDriver
设置为 false 的 kubelets 将不会运行它们并向用户返回适当的错误。这允许用户选择在 3 个版本中重新启用驱动,以便他们有足够的时间修复工作负载。
计划在 v1.39 版本中移除 kubelet 和树内插件代码中的特性门。
可以在 KEP-5040: Remove gitRepo volume driver 中找到更多信息。
移除对 Windows Pod 的 host network 支持
Windows Pod 网络旨在实现与 Linux 的功能对等,并通过允许容器使用节点的网络命名空间来提高集群密度。最初的实现于 v1.26 作为 Alpha 版本落地,但由于它面临意料之外的 containerd 行为并且存在替代解决方案,Kubernetes 项目决定撤回相关的 KEP。此支持已在 v1.33 中完全移除。
请注意,这不影响HostProcess containers,它提供 host network 以及主机级别的访问。在 v1.33 中撤回的 KEP 是关于仅提供 host network,由于 Windows 网络逻辑的技术限制,此功能从未稳定。
可以在 KEP-3503: Host network support for Windows pods 中找到更多信息。
发行说明
请在我们的发行说明中查看 Kubernetes v1.33 版本的完整详细信息。
可用性
Kubernetes v1.33 可在 GitHub 或Kubernetes 下载页面下载。
要开始使用 Kubernetes,请查看这些交互式教程,或使用 minikube 运行本地 Kubernetes 集群。您也可以使用 kubeadm 轻松安装 v1.33。
发行团队
Kubernetes 的成功离不开社区的支持、承诺和辛勤工作。发行团队由专注的社区志愿者组成,他们共同构建了构成您所依赖的 Kubernetes 版本所需的许多组件。这需要来自社区各个角落的人员具备专业技能,从代码本身到文档和项目管理。
我们要感谢整个发行团队为向社区交付 Kubernetes v1.33 版本所付出的辛勤工作。发行团队成员包括首次参与的影子成员和具有多轮发行经验的回归团队负责人。在本发行周期中采用了新的团队结构,即将发行说明和文档子团队合并为一个统一的文档子团队。感谢新文档团队在组织相关信息和资源方面付出的细致努力,发行说明和文档跟踪都实现了平稳成功的过渡。最后,特别感谢我们的发行负责人 Nina Polshakova,感谢她在整个成功发行周期中的支持、她的倡导、她确保每个人都能有效贡献的努力以及她对改进发行流程的挑战。
项目速度
CNCF K8s DevStats 项目汇总了与 Kubernetes 及各种子项目速度相关的几个有趣数据点。这包括从个人贡献到贡献公司数量的一切,并展示了投入到发展这个生态系统中的努力的深度和广度。
在 v1.33 发行周期(从 2025 年 1 月 13 日到 4 月 23 日,共 15 周)中,Kubernetes 收到了来自多达 121 家不同公司和 570 名个人(截至撰写本文时,距离发布日期还有几周)的贡献。在更广泛的云原生生态系统中,这一数字上升到 435 家公司,总共有 2400 名贡献者。您可以在此仪表板中找到数据源。与之前 v1.32 版本的速度数据相比,我们看到公司和个人的贡献水平相似,表明社区兴趣浓厚且参与度高。
请注意,“贡献”计算的是某人提交、代码评审、评论、创建 Issue 或 PR、评审 PR(包括博客和文档)或在 Issue 和 PR 上评论。如果您有兴趣贡献,请访问我们的贡献者网站上的入门指南。
查看 DevStats,了解更多关于 Kubernetes 项目和社区的整体速度。
活动更新
探索即将到来的 Kubernetes 和云原生活动,包括 KubeCon + CloudNativeCon、KCD 以及全球其他知名会议。随时了解并参与 Kubernetes 社区!
2025 年 5 月
- KCD - Kubernetes Community Days: Costa Rica:2025 年 5 月 3 日 | 哥斯达黎加埃雷迪亚
- KCD - Kubernetes Community Days: Helsinki:2025 年 5 月 6 日 | 芬兰赫尔辛基
- KCD - Kubernetes Community Days: Texas Austin:2025 年 5 月 15 日 | 美国奥斯汀
- KCD - Kubernetes Community Days: Seoul:2025 年 5 月 22 日 | 韩国首尔
- KCD - Kubernetes Community Days: Istanbul, Turkey:2025 年 5 月 23 日 | 土耳其伊斯坦布尔
- KCD - Kubernetes Community Days: San Francisco Bay Area:2025 年 5 月 28 日 | 美国旧金山湾区
2025 年 6 月
- KCD - Kubernetes Community Days: New York:2025 年 6 月 4 日 | 美国纽约
- KCD - Kubernetes Community Days: Czech & Slovak:2025 年 6 月 5 日 | 斯洛伐克布拉迪斯拉发
- KCD - Kubernetes Community Days: Bengaluru:2025 年 6 月 6 日 | 印度班加罗尔
- KubeCon + CloudNativeCon China 2025:2025 年 6 月 10-11 日 | 香港
- KCD - Kubernetes Community Days: Antigua Guatemala:2025 年 6 月 14 日 | 危地马拉安提瓜
- KubeCon + CloudNativeCon Japan 2025:2025 年 6 月 16-17 日 | 日本东京
- KCD - Kubernetes Community Days: Nigeria, Africa:2025 年 6 月 19 日 | 非洲尼日利亚
2025 年 7 月
- KCD - Kubernetes Community Days: Utrecht:2025 年 7 月 4 日 | 荷兰乌特勒支
- KCD - Kubernetes Community Days: Taipei:2025 年 7 月 5 日 | 中国台湾台北
- KCD - Kubernetes Community Days: Lima, Peru:2025 年 7 月 19 日 | 秘鲁利马
2025 年 8 月
- KubeCon + CloudNativeCon India 2025:2025 年 8 月 6-7 日 | 印度海得拉巴
- KCD - Kubernetes Community Days: Colombia:2025 年 8 月 29 日 | 哥伦比亚波哥大
您可以在此处找到最新的 KCD 详细信息。
即将到来的发布网络研讨会
加入 Kubernetes v1.33 发行团队的成员,在**2025 年 5 月 16 日星期五下午 4:00 (UTC)** 了解此版本的重点功能以及弃用和移除项,以帮助规划升级。有关更多信息和注册,请访问 CNCF 在线项目网站上的活动页面。
参与贡献
参与 Kubernetes 最简单的方式是加入众多与其兴趣一致的特别兴趣小组(SIG)之一。有什么想向 Kubernetes 社区广播吗?在我们的每周社区会议以及以下渠道中分享您的声音。感谢您一如既往的反馈和支持。
- 在 Bluesky 上关注我们 @kubernetes.io 获取最新动态
- 加入 Discuss 上的社区讨论
- 加入 Slack 上的社区
- 在 Server Fault 或 Stack Overflow 上提问(或回答问题)
- 分享您的 Kubernetes故事
- 在博客上阅读更多关于 Kubernetes 的动态
- 了解更多关于Kubernetes 发行团队的信息