Kubernetes 1.29 发布：宇宙主题雄心勃勃¶

作者：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：

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 标签：

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 范围。

示例如下：

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 会被调度到同一节点。

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 端点返回的数据示例如下：

# 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 特性门控。

示例：

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。
[节点] DevicePluginCDIDevices 功能已升级至 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 个提交，详情请见贡献列表（该版本的两百多位贡献者中有来自 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 或者使用外部云控制管理器。

有关如何启用和运行外部云控制器管理器的更多信息，请阅读云控制器管理器管理。

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

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

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

更多详情以及如何迁移请参考Kubernetes 旧版软件包仓库将于 2023 年 9 月 13 日被冻结博客

其他需要注意的变化¶

删除网络 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

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

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

发布标志由 Mario Jason Braganza 制作（基于曼陀罗艺术，感谢 Fibrel Ojalá），象征着 Kubernetes 项目及其所有成员的小宇宙。

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

历史文档¶

参考¶

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