---
date: 2023-12-13
---
# Kubernetes 1.29 发布:宇宙主题雄心勃勃
> 作者:[mengjiao-liu](https://github.com/mengjiao-liu)
太平洋时间 2023 年 12 月 13 日,主题为 Mandala(宇宙)的 Kubernetes 1.29 正式发布。
此版本距离上版本发布时隔 4 个月,是 2023 年的第三个版本,也是今年的最后一个版本。
新版本中 release 团队跟踪了 49 个 enhancements。其中 11 个功能升级为稳定版,19 个已有功能进行优化升级为 Beta,另有多达
19 个 Alpha 级别的全新功能。1.29 版本包含了很多重要功能以及用户体验优化,本文下一小节将详细介绍部分重要功能。
## 重要功能
### [网络] KEP-3866:nftables 作为 kube-proxy 后端(Alpha)
在 Kubernetes v1.29 中,Kubernetes 使用 nftables 作为 kube-proxy 新的后端,此功能现在是 Alpha 版本。
iptables 存在无法修复的性能问题,随着规则集大小的增加,性能损耗不断增加。很大程度上由于其无法修复的问题,
内核中 iptables 的开发速度已经放缓,并且大部分已经停止。新功能不会添加到 iptables 中,新功能和性能改进主要进入 nftables。
nftables 能完成 iptables 能做的所有事情,而且做得更好。
特别是,RedHat 已宣布 iptables 在 RHEL 9 中已弃用,并且可能在几年后的 RHEL 10 中完全删除。Debian 从 Debian 11 (Bullseye)
中的 `required` 软件包中删除了 iptables。基于上述原因,kube-proxy 引入 nftables 作为 kube-proxy 新的后端。
此功能的后续目标是使 nftables 成为 kube-proxy 的默认后端(替代 iptables 和 ipvs)。
管理员必须启用特征门控 `NFTablesProxyMode` 才能使该功能可用,然后必须使用 `--proxy-mode=nftables` 标志运行 kube-proxy。
需要注意的是,虽然该 `nftables` 模式可能与 `iptables` 模式非常相似,但某些 CNI 插件、NetworkPolicy 实现等可能需要更新才能使用它。
这可能会带来一定的兼容性问题。
### [存储] KEP-2495:PV/PVC `ReadWriteOncePod` 访问模式(GA)
在 Kubernetes 中,访问模式是定义如何使用持久存储的方式。这些访问模式是持久卷 (PV) 和持久卷声明 (PVC) 规范的一部分。
`ReadWriteOncePod` 作为第四种访问模式(之前的三种访问模式:ReadWriteOnce、ReadOnlyMany、ReadWriteMany)在
Kubernetes v1.22 中作为 Alpha 功能被引入,在 Kubernetes v1.29 中到达 GA。这一功能的主要目的是提供对存储资源的更灵活的访问控制,
确保只有一个 Pod 能够以读写模式访问该存储。这种限制对于一些特定的应用场景非常有用,例如,确保只有一个 Pod 能够修改存储中的数据,以防止数据冲突或损坏。
此功能也更新了 Kubernetes 调度程序以支持与 `ReadWriteOncePod` 存储相关的 pod 抢占。这意味着,如果两个 Pod 使用
`ReadWriteOncePod` 请求 `PersistentVolumeClaim`,则具有最高优先级的 Pod 将获得对 `PersistentVolumeClaim` 的访问权限,
而任何具有较低优先级的 pod 将从节点中被抢占,并且无法访问 `PersistentVolumeClaim`。
下面的示例是使用 `ReadWriteOncePod` 访问模式创建一个新的 PVC:
```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: single-writer-only
spec:
accessModes:
- ReadWriteOncePod
resources:
requests:
storage: 1Gi
```
通过引入 ReadWriteOncePod 功能,Kubernetes 使得用户能够更好地控制存储资源的访问权限,提高了应用程序在容器化环境中对存储的管理灵活性。
### [Auth] KEP-3299:KMS v2 增强(GA)
保护 Kubernetes 集群时首先要考虑的事情之一是加密静态的 etcd 数据。 KMS 为供应商提供了一个接口,以便利用存储在外部密钥服务中的密钥来执行此加密。
Kubernetes KMS(Key Management Service)对于 secret 的安全管理和加密至关重要。随着 Kubernetes 1.29 版本的发布,
具有特性门控 `KMSv2` 和 `KMSv2KDF` 的 KMSv2 功能已升级为 GA,`KMSv1` 特性门控现在默认处于禁用状态。
这已成为一项稳定的功能,专注于改进 KMS 插件框架,这对于安全管理至关重要。这些改进确保 Kubernetes secret 仍然是存储敏感信息的强大且安全的方法。
### [节点] KEP-753: 原生支持 Sidecar 容器 (Beta)
原生支持 Sidecar 容器在 Kubernetes v1.28 中被引入作为 Alpha,v1.29 中升级至 Beta,特性门控 `SidecarContainers` 默认启用。
从 Kubernetes v1.29 开始,如果你的 Pod 包含一个或多个 sidecar 容器(具有始终重启策略的 init 容器),
Kubelet 将延迟向这些 Sidecar 容器发送 TERM 信号,直到最后一个主容器完全终止。 Sidecar 容器将以 Pod 规范中定义的相反顺序终止。
这可确保 Sidecar 容器继续为 Pod 中的其他容器提供服务,直到不再需要它们为止。
### [Auth/Apps] KEP-2799: 减少基于 Secret 的服务账号令牌(Beta)
`legacy-service-account-token-cleaner` 控制器作为 kube-controller-manager 的一部分运行,
`LegacyServiceAccountTokenCleanUp` 特性门控现在可作为 Beta 使用(默认情况下启用)。
`legacy-service-account-token-cleaner` 控制器会循环删除在 `--legacy-service-account-token-clean-up-period`
指定的时间内未使用的服务账号令牌密钥(默认为一年)。控制器通过向 Secret 添加名为 `kubernetes.io/legacy-token-invalid-since`
的标签(以当前日期作为值)来标记 Secret 无效。如果无效的 Secret 在指定时间内没有被使用,控制器将删除它。
以下是自动生成的旧令牌的示例,该令牌已标记有 `kubernetes.io/legacy-token-last-used` 和 `kubernetes.io/legacy-token-invalid-since` 标签:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: build-robot-secret
namespace: default
labels:
kubernetes.io/legacy-token-last-used: 2022-10-24
kubernetes.io/legacy-token-invalid-since: 2023-10-25
annotations:
kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
```
### [Windows] KEP-1287:Windows 支持 Pod 资源原地升级(Alpha)
Kubernetes v1.29 中,Windows 支持了 Pod 资源原地升级(In-Place Update)功能,允许在不重新创建 Pod 或重新启动容器的情况下更改资源。
### [网络] KEP-1880:动态扩展 Service 的可用 IP 范围(Alpha)
Service 是公开在一组 Pod 上运行的应用程序的抽象方式。Service 可以具有集群范围的虚拟 IP 地址,
该地址是从 `kube-apiserver` 标志中设置的预定义 `CIDR` 分配的。但是,用户可能希望添加、删除或调整为服务分配的现有 IP 范围,
而无需重新启动 kube-apiserver。
此功能允许集群管理员使用 `ServiceCIDR` 对象动态调整分配给集群的服务 IP 范围的大小,以处理 IP 耗尽或 IP 重新编号等问题,
在安装引导期间,此功能会根据 `kube-apiserver` 的 `--service-cluster-ip-range` 命令行参数的值创建一个名为
`kubernetes` 的默认 `ServiceCIDR` 对象。
如果要使用此功能,用户需要启用 `MultiCIDRServiceAllocator` 特性门控和 `networking.k8s.io/v1alpha1` API,
并且创建或删除新的 `ServiceCIDR` 对象来管理服务的可用 IP 范围。
示例如下:
```shell
cat <
2. Kubernetes 1.29 发布团队
3. Kubernetes 1.29 变更日志
4. Kubernetes 1.29 主题讨论