---
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 <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
kind: ServiceCIDR
metadata:
  name: newservicecidr
spec:
  cidrs:
  - 10.96.0.0/24
EOF
```

### [调度] KEP-3633： 将 MatchLabelKeys/MismatchLabelKeys 引入 Pod 亲和性和 Pod 反亲和性（Alpha）

Kubernetes v1.29 中 PodAffinity/PodAntiAffinity 中将引入一项增强功能作为 Alpha 版本。它将提高滚动更新期间计算的准确性。
此功能向 `PodAffinityTerm` 引入一个补充字段 `MatchLabelKeys`。这使用户能够在现有 `LabelSelector` 之上精细控制 PodAffinity
或 PodAntiAffinity 的范围。

`MatchLabelKeys/MismatchLabelKey` 是一组 Pod 标签键，用于选择要考虑哪些 Pod。key 用于从传入 Pod 标签中查找 value。
`MatchLabelKeys` 获得的 Pod key-value 标签与 `LabelSelector` 合并为 `key in (value)`，
`MismatchLabelKeys` 获得的 Pod key-value 与 `LabelSelector` 合并为 `key notin (value)`，
以选择现有 Pod 组，传入 Pod 时将考虑这些 Pod（反）亲和力。传入 Pod 标签中不存在的键将被忽略。默认值为空。
禁止在 `MatchLabelKeys/MismatchLabelKey` 和 `LabelSelector` 中同时存在相同的键。
另外，如果未设置 `LabelSelector`，则无法设置 `MatchLabelKeys/MatchLabelKeys`。
这是一个 Alpha 字段，需要启用 `MatchLabelKeysInPodAffinity` 特性门控。

设置了 `MatchLabelSelector` 后，新创建的 Pod 的调度会受到影响。所有现有的 Pod 都不受影响。

以 `matchLabelKeys` 为例，存在 key-value 对 app:database 和 存在 pod-template-hash key 以及值也相同的 Pod 会被调度到同一节点。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: application-server
---
affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - database
        topologyKey: topology.kubernetes.io/zone
        matchLabelKeys:
          - pod-template-hash
```

### [调度] KEP-4247：QueueingHint 为优化 Pod 调度带来新的可能（Beta）

对于 Kubernetes 项目来说，调度器的吞吐量多年来一直是一个永恒的挑战，SIG Scheduling 一直在努力通过许多增强来提高调度吞吐量。

QueueingHint 功能为优化重新排队效率带来了新的可能性，可以显著减少无用的调度重试。

在 v1.28 中，只有一个 alpha 插件 (DRA) 支持 QueueingHint，
在 v1.29 中，一些稳定的插件开始实现 QueueingHints。

QueueingHint 从 v1.28 引入以来就是 Beta 状态，直接跳过 Alpha 阶段，默认启用。
它不面向用户而是面向开发者，可以使用 `SchedulerQueueingHints` 特性门控来决定是否禁用它。
因为 QueueingHint 改变了调度程序的关键路径并增加了一些内存开销，具体取决于集群的繁忙程度。

### [Instrumentation] KEP-727：Kubelet 资源指标（GA）

Kubelet 使用 Prometheus 客户端库以 Prometheus 文本展示格式在 `/metrics/resource` 公开端点。它提供集群级资源指标 API 所需的指标，
用以替代 Summary API 提供的指标杂且多的问题。

在 Kubernetes v1.29 中，将以下 kubelet 资源指标升级为 GA：

- `container_cpu_usage_seconds_total`
- `container_memory_working_set_bytes`
- `container_start_time_seconds`
- `node_cpu_usage_seconds_total`
- `node_memory_working_set_bytes`
- `pod_cpu_usage_seconds_total`
- `pod_memory_working_set_bytes`
- `resource_scrape_error`
  弃用（重命名）指标 `scrape_error`，改为 `resource_scrape_error`

### [Instrumentation] KEP-3466：Kubernetes 组件运行状况 SLIs（GA）

由 `ComponentSLIs` 特性门控控制并在 `/metrics/slis` 端点提供服务的指标现在是 GA 和无条件启用的。
特性门控将在 1.31 被移除。

访问 `/metrics/slis` 端点返回的数据示例如下：

```Prometheus
# HELP kubernetes_healthcheck [ALPHA] This metric records the result of a single healthcheck.
# TYPE kubernetes_healthcheck gauge
kubernetes_healthcheck{name="autoregister-completion",type="healthz"} 1
kubernetes_healthcheck{name="autoregister-completion",type="readyz"} 1
kubernetes_healthcheck{name="etcd",type="healthz"} 1
kubernetes_healthcheck{name="etcd",type="readyz"} 1
kubernetes_healthcheck{name="etcd-readiness",type="readyz"} 1
kubernetes_healthcheck{name="informer-sync",type="readyz"} 1
kubernetes_healthcheck{name="log",type="healthz"} 1
kubernetes_healthcheck{name="log",type="readyz"} 1
kubernetes_healthcheck{name="ping",type="healthz"} 1
kubernetes_healthcheck{name="ping",type="readyz"} 1
# HELP kubernetes_healthchecks_total [ALPHA] This metric records the results of all healthcheck.
# TYPE kubernetes_healthchecks_total counter
kubernetes_healthchecks_total{name="autoregister-completion",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="autoregister-completion",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="etcd",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="etcd",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="etcd-readiness",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="informer-sync",status="error",type="readyz"} 1
kubernetes_healthchecks_total{name="informer-sync",status="success",type="readyz"} 14
kubernetes_healthchecks_total{name="log",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="log",status="success",type="readyz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="healthz"} 15
kubernetes_healthchecks_total{name="ping",status="success",type="readyz"} 15
```

### [存储] KEP-3107：NodeExpandSecret 添加到 CSI 持久卷源（GA）

NodeExpandSecret 功能在 v1.29 中移至 GA。此功能将 `NodeExpandSecret` 添加到 CSI 持久卷源，
并使 CSI 客户端能够将其作为 `NodeExpandVolume` 请求的一部分发送到 CSI 驱动程序。

### [存储] KEP-3751：VolumeAttributesClass（Alpha）

VolumeAttributesClass 功能在 v1.29 中引入，现在处于 Alpha 阶段，默认不启用。需要在 kube-apiserver、
kube-controller-manager、external-provisioner 和 external-resizer 组件都启用 `VolumeAttributesClass` 特性门控才能使用此功能。

此功能对 Kubernetes 持久卷 API 进行扩展，以允许用户在配置后更改卷属性（例如 IOPS 或吞吐量）。

需要注意的是，在 v1.29 中`·VolumeAttributesClass` 功能可能仅包含 API 更改，其功能尚未实现。
实现在 `external-provisioner` 和 `external-resizer` 中，将在 Kubernetes v1.29 发布后异步发布。

CSI 对应标准版本为 1.9，各个厂商 CSI 实现的控制器插件, 必须支持 `MODIFY_VOLUME` 能力。

### [Instrumentation] KEP-3077：kube-scheduler 已转换为上下文日志记录（Alpha）

Kubernetes v1.24 中引入的上下文日志记录功能现已成功迁移到两个组件（kube-scheduler 和 kube-controller-manager）以及一些目录。
该功能旨在为 Kubernetes 提供更多有用的日志以更好地进行问题追踪、故障排除。目前该功能处于 Alpha 阶段，如需使用请启用 `ContextualLogging` 特性门控。

示例：

```console
I1113 08:43:37.029524 87144 default_binder.go:53] "Attempting to bind pod to node" logger="Bind.DefaultBinder" pod="kube-system/coredns-69cbfb9798-ms4pq" node="127.0.0.1"
```

### [节点] KEP-127：启用 Pod 安全标准（Pod Security Standards）的用户命名空间支持 (Alpha)

添加了 `UserNamespacesPodSecurityStandards` 特性门控，以启用对 Pod 安全标准的用户命名空间支持。
启用此功能将修改所有 Pod 安全标准规则以允许设置：`spec[.*].securityContext.[runAsNonRoot,runAsUser]`。
仅当集群中的所有节点都支持用户命名空间功能并启用它时，才应启用此特性门控。
在未来的 Kubernetes 版本中，特性门控不会升级或默认启用。

### [节点] KEP-4191：Kubelet 支持镜像文件系统（Image Filesystem）被分割 (Alpha)

Kubelet 支持镜像文件系统（Image Filesystem）被分割在 v1.29 中被引入作为 Alpha，由 特性门控 `KubeletSeparateDiskGC` 控制是否启用，默认不启用。
Kubelet 可以支持将 ImageFilesystem 分为可写层和只读层，可写层与 Kubelet 位于同一磁盘上，镜像可以位于单独的文件系统上。

### [节点] KEP-4210：添加对 ImageMaximumGCAge 字段的支持 (Alpha)

将 `ImageMaximumGCAge` 字段添加到 Kubelet 配置中，该字段允许用户设置镜像在被垃圾收集之前未使用的最长期限。
该字段由特性门控 `ImageMaximumGCAge` 控制，当前为 Alpha，默认不启用。

### [Auth] KEP-4193： 绑定服务账号令牌增强 (Alpha)

Kubernetes v1.29 新增了 4 个特性门控来增强绑定服务账号令牌。
kube-apiserver 现在通过 `ServiceAccountTokenJTI` 特性门控添加了对 Alpha 版本的支持，
以在其发放的服务账户令牌中添加 `jti`（JWT ID）声明。此外，在令牌发放时，还会在审计日志中添加
`authentication.kubernetes.io/credential-id` 审计注释，并在使用令牌进行身份验证时，
在额外的用户信息中添加 `authentication.kubernetes.io/credential-id` 条目。

kube-apiserver 现在通过 `ServiceAccountTokenPodNodeInfo` 特性门控添加了对 Alpha 版本的支持,
以在服务账户令牌中添加节点名称（以及节点存在时的 UID）作为额外声明。这些令牌与 Pod 绑定，并在使用令牌进行身份验证时，
还会提供 `authentication.kubernetes.io/node-name` 和 `authentication.kubernetes.io/node-uid` 作为额外的用户信息。

kube-apiserver 现在通过 `ServiceAccountTokenNodeBinding` 特性门控添加了对 Alpha 版本的支持，以允许 `TokenRequests` 直接将令牌绑定到节点，
并在使用令牌时进行验证（通过 `ServiceAccountTokenNodeBindingValidation` 特性门控），以确保节点名称和 UID 仍然存在。

## 其他需要了解的功能

- [Node] 添加对 containerd/kubelet/CRI 的支持以支持每个运行时类的镜像拉取，在 v1.29 中，此功能为 Alpha，需要启用 `RuntimeClassInImageCriApi` 特性门控，默认关闭。
- [APIMachinery] 已弃用 kube-apiserver 中的 `--cloud-provider` 和 `--cloud-config` CLI 参数。这些参数将在未来版本中删除。
- [Auth] 结构化授权配置（Structured Authorization Configuration）在 v1.29 中进入 Alpha。增加了 structure configuring authorizers 并向 kube-apiserver 授权链添加多个 webhook 的能力。
- [APIMachinery] Structured Authentication Config 在 v1.29 中为 Alpha。在 kube-apiserver 添加了 `--authentication-config` 标志用于读取 `AuthenticationConfiguration` 文件。 `--authentication-config`标志与现有的 `--oidc-*` 标志互斥。
- [Auth] 添加了对将 `certificates.k8s.io/v1alpha1` `ClusterTrustBundle` 对象投影到 Pod 中的支持。
- [APIMachinery] CRD 基于通用表达式语言 (CEL) 的验证规则 GA。
- [APIMachinery] CRD Validation Ratcheting 进入 Alpha2。
- [Apps] Job API Pod 替换策略支持 Beta，添加 `job_pods_creation_total` 指标，用于跟踪由触发 Pod 创建的事件标记的作业控制器创建的 Pod。
- [节点] `DevicePluginCDIDevice`s 功能已升级至 Beta 并在 Kubelet 中默认启用。
- [Apps] KEP-3850: 每个索引的 Job 重试 BackOff 限制已升级至 Beta，并引入 `job_finished_indexes_total` 指标。
- [网络] `ServiceNodePortStaticSubrange` 特性已升级至 GA。它允许你为 NodePort 服务使用不同的端口分配策略。
- [网络] 将 PodHostIPs 条件提升为 Beta。该功能旨在提高 Pod 获取节点地址的能力。
- [APIMachinery] 优先级和公平性功能在 v1.29 中达到 GA，`APIPriorityAndFairness` 特性门控 将在 v1.31 中删除。
- [节点] 为 PreStop 生命周期 hook 添加新的睡眠操作功能在 v1.29 中被引入，现在为 Alpha，需要在 kubelet 和 kube-apiserver 组件启用 `PodLifecycleSleepAction` 特性门控，默认关闭。
- [CLI]添加了将 Kubernetes 客户端的双向流协议从 SPDY/3.1 过渡到 WebSockets 的新功能，添加新的 Alpha `TranslateStreamCloseWebsocketRequests` 特性门控，允许控制平面接受 WebSockets/V5 升级请求。
  添加新的 Alpha kubectl 环境变量 `KUBECTL_REMOTE_COMMAND_WEBSOCKETS`，该标志在设置时尝试将 WebSockets 协议用于 `kubectl exec`、`kubectl cp` 和 `kubectl attach`。
- [存储] 持久卷 status 包含 `lastPhaseTransitionTime` 字段，该字段保存卷上次转换其阶段的时间戳。功能 `PersistentVolumeLastPhaseTransitionTime` 在 v1.29 升级至 Beta。
- [APIMachinery] 支持 API 分页 LIST 查询 GA。
- [节点] 在 Kubernetes v1.29 中，`PodReadyToStartContainers` 升级为 Beta，默认可用。kubelet 在 Pod 的整个生命周期中管理 Pod `condition` 字段中该条件的值。
  kubelet 将使用 `PodReadyToStartContainers` 条件从容器运行时创建 Pod sandbox 和网络配置的角度准确地呈现 Pod 的初始化状态。
- [CLI] 如果子命令不存在，外部插件可以用作内置命令的子命令。此功能处于 Beta 阶段。默认情况下，将 KUBECTL_ENABLE_CMD_SHADOW 环境变量设置为 true。
- [CLI] kubectl delete 命令中的交互式标志（--interactive/-i），默认可用。`KUBECTL_INTERACTIVE_DELETE` 环境变量已删除。
- [网络] 让 Kubernetes 了解 LoadBalancer 的行为，此功能在 Service 的 `.status` 中添加了新的 `ipMode` 字段，其中 `type` 设置为 `LoadBalancer`。
  使用新字段需要启用 `LoadBalancerIPMode` 特性门控，现在处于 Alpha 阶段，默认是关闭的。
- [Apps] 将 TaintManager 与 NodeLifecycleController 解耦，以增强关注点分离和可维护性。此功能被标记为 Bata 版，但实际上是一个全新的变化（它跳过 Alpha 版本）。
  它将 `TaintManager` 与 `NodeLifecycleController` 解耦，`TaintManager` 执行基于污点的 Pod 驱逐，并使它们成为两个独立的控制器：
  `NodeLifecycleController` 用于向不健康的节点添加污点，`TaintManager` 用于对受到 NoExecute 效果污染的节点执行 Pod 删除。

## DaoCloud 社区贡献

本次发布中， DaoCloud 重点贡献了 sig-node，sig-scheduling, sig-storage，sig-instrumentation，sig-network 和 kubeadm 相关内容，具体功能点如下：

- [节点] 修复了 sysctl 进行 Pod 规范验证问题：`hostNetwork` 的 Pod 禁止配置网络命名空间的 sysctl，`hostIPC` 的 Pod 禁止配置 `IPC` 命名空间的 sysctl
- [调度] kube-scheduler `selectedSpread` 插件已被删除，请改用 `podTopologySpread` 插件。
- [调度] 修复了运行 score 插件时调度程序框架中自 v1.27.0 以来的回归问题。`SkippedScorePlugins` 数量可能大于 `enabledScorePlugins`，
  因此在初始化切片时 `cap(len(enabledScorePlugins) - len(skippedScorePlugins))` 的值可能是负的，这是不允许的。
- [调度] 向 `QueueingHint` 添加了返回值以指示错误。如果 `QueueingHint` 返回错误，调度程序会记录该错误并将该事件视为
  `QueueAfterBackoff`，以便 Pod 不会卡在不可调度的 Pod 池中。
- [调度] 在 kube-scheduler 实现 NodeAffinity 插件的调度 hints。
- [存储] 参与设计 `VolumeAttributesClass` API。
- [Instrumentation] 将 kube-scheduler 完全转化为上下文日志记录。
- [网络] 将 PodHostIPs 条件提升为 Beta。
- [Kubeadm] 允许部署比 kubeadm 版本早 3 个版本的 kubelet (N-3)。这与 SIG Architecture 最近所做的更改相一致，该更改扩展了控制平面和 kubelet 之间的支持偏差。
- [Kubeadm] 修复 `clusterrole` 的无效命名空间字段。
- [测试] 更新测试框架方法以及添加测试增加测试覆盖率。

在 v1.29 发布过程中，DaoCloud 参与一百多个问题修复和功能研发，作为作者约有 111 个提交，详情请见[贡献列表](https://www.stackalytics.io/cncf?project_type=cncf-group&release=all&metric=commits&module=github.com/kubernetes/kubernetes&date=120)（该版本的两百多位贡献者中有来自 DaoCloud 的 17 位）。
在 Kubernetes v1.29 的发布周期中，DaoCloud 的多名研发工程师取得了不少成就。其中，Paco 做为首位入选 Kubernetes 指导委员会(Steering Committee)的中国人；
蔡威成为 CNCF Fall 2023 云原生全球大使，并且是 KCD 深圳站 2023 的组织者和主持人；刘梦姣成为 WG Structured Logging Lead，并且成为 Kubernetes/klog Reviewer；
郭奇峰成为 Calico Big Cat 大使。

## 升级注意事项

### EventedPLEG 存在严重问题

`EventedPLEG` 功能（ 使用事件驱动的 PLEG）在 Kubernetes v1.27 中已经升级为 Beta，但是默认不开启。在 v1.29 测试中发现了严重问题，建议不要启用它！社区正在进行调查和修复，但尚未找到具体原因。

### in-tree cloud providers 的移除升级至 Beta 状态

in-tree cloud providers 的移除在 Kubernetes v1.29 状态升级为 Beta，用户需要注意特性门控
`DisableCloudProviders` 和 `DisableKubeletCloudCredentialProvider` 现在默认为 true，
这意味着在默认运行时不与任何云提供商（比如 Azure， GCE，vSphere）任何进行内置集成。如果你仍然需要此功能，
请设置 `DisableCloudProviders` 和 `DisableKubeletCloudCredentialProvider` 特性门控为 false 或者使用外部云控制管理器。

有关如何启用和运行外部云控制器管理器的更多信息，请阅读[云控制器管理器管理](https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/)。

如果你需要为旧的 in-tree cloud providers 提供云控制器管理器，请参阅以下链接：

- [Cloud provider AWS](https://github.com/kubernetes/cloud-provider-aws)
- [Cloud provider Azure](https://github.com/kubernetes-sigs/cloud-provider-azure)
- [Cloud provider GCE](https://github.com/kubernetes/cloud-provider-gcp)
- [Cloud provider OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
- [Cloud provider vSphere](https://github.com/kubernetes/cloud-provider-vsphere)

### Kubernetes 旧版软件包仓库已被冻结

Kubernetes 旧版软件包仓库（apt.kubernetes.io 和 yum.kubernetes.io）已于 2023 年 9 月 13 日被冻结，Kubernetes v1.29 及以后的版本将仅发布软件包到社区拥有的仓库（pkgs.k8s.io）。
已弃用的旧仓库及其内容预计将于 2024 年 1 月删除。Kubernetes 项目强烈建议尽快迁移到新的社区拥有的仓库!

更多详情以及如何迁移请参考[Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结博客](https://kubernetes.io/zh-cn/blog/2023/08/31/legacy-package-repository-deprecation/)

### 其他需要注意的变化

- 删除网络 `ClusterCIDR` Alpha API, SIG 对此功能存在合理性怀疑，经过几个月的社区讨论，删除仍在 Alpha 中的现有代码。
- 弃用 Node 的 `status.nodeInfo.kubeProxyVersion` 字段，该字段不准确，它是由 kubelet 设置的，kubelet 实际上并不知道 kube-proxy 版本，或者 kube-proxy 是否正在运行。
- 弃用 `FlowSchema` 和 `PriorityLevelConfiguration` 的 `flowcontrol.apiserver.k8s.io/v1beta2` API version，
  并且 `flowcontrol.apiserver.k8s.io/v1beta3`已升级为 `flowcontrol.apiserver.k8s.io/v1`。如果你的清单或客户端软件使用已弃用的 Beta API 组， 则应升级到 v1.29 之前更改这些。

## 版本标志

本次发布的主题是：__Mandala（曼陀罗，宇宙）__ ✨

![logo](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/blogs/images/kubernetes-1.29.png)

与我们一起踏上 Kubernetes v1.29 的宇宙之旅！

这个版本的灵感来自于曼陀罗（Mandala）这一美丽的艺术形式——它是宇宙完美表达的象征。此次发布社区大约有 40 名发布团队成员，得到数百名社区贡献者的支持，他们辛勤工作，将挑战转化为全球数百万人的喜悦。
曼陀罗主题反映了社区的相互关联，充满活力。每位贡献者都是一个至关重要的部分，他们像曼陀罗艺术中的多样图案一样，为其中添加了独特的能量。Kubernetes 在协作中茁壮成长，回应着曼陀罗创作中的和谐。

发布标志由 [Mario Jason Braganza](https://janusworx.com) 制作（基于曼陀罗艺术，感谢 [Fibrel Ojalá](https://pixabay.com/users/fibrel-3502541/)），
象征着 Kubernetes 项目及其所有成员的小宇宙。

秉持曼陀罗变革象征的精神，Kubernetes v1.29 庆祝着我们项目的演变。就像 Kubernetes 宇宙中的星星一样，每个贡献者、用户和支持者都为之照亮道路。我们共同创造了一个可能性的世界。

## 历史文档

- [Kubernetes 1.28 震撼发布，Sidecar Containers 迎面而来](https://mp.weixin.qq.com/s/Dr_JpSD9tzfahslZO2bX5A)
- [近两年功能增加最多！Kubernetes 1.27 正式发布](https://mp.weixin.qq.com/s/maDEiCGzOPSDkH9dUxIxdA)
- [Kubernetes 正式发布 v1.26，稳定性显著提升](https://mp.weixin.qq.com/s/qwzmeIM4INz-_BK_gbwOxw)
- [Kubernetes 1.25 正式发布，多方面重大突破](https://mp.weixin.qq.com/s/aRmLBYpk0MhLJAwY85DyuA)
- [Kubernetes 1.24 走向成熟的 Kubernetes](https://mp.weixin.qq.com/s/vqH8ueaZeEeZbx_axNVSjg)
- [Kubernetes 1.23 正式发布，有哪些增强？](https://mp.weixin.qq.com/s/A5GBv5Yn6tQK_r6_FSyp9A)
- [Kubernetes 1.22 颠覆你的想象：可启用 Swap，推出 PSP 替换方案，还有……](https://mp.weixin.qq.com/s/9nH2UagDm6TkGhEyoYPgpQ)
- [Kubernetes 1.21 震撼发布 | PSP 将被废除，BareMetal 得到增强](https://mp.weixin.qq.com/s/amGjvytJatO-5a7Nz4BYPw)

## 参考

1. Kubernetes 增强特性 <https://kep.k8s.io/>
2. Kubernetes 1.29 发布团队 <https://github.com/kubernetes/sig-release/blob/master/releases/release-1.29>
3. Kubernetes 1.29 变更日志 <https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md>
4. Kubernetes 1.29 主题讨论 <https://github.com/kubernetes/sig-release/discussions/2349>