现在宣布 Kubernetes v1.29：Mandala 版本正式发布，这是 2023 年发布的最后一个版本！
Kubernetes v1.29 的发布，如同以往版本一样，带来了新的稳定版（Stable）、测试版（Beta）和开发版（Alpha）特性。这次发布再次证明了我们高效的开发周期和社区的热情支持，体现了我们的强大实力。
这个版本包含了 49 个增强功能，其中 11 个已经成熟到稳定版，19 个进入 Beta 版阶段，另外 19 个达到了 Alpha 版水平。
#01
主题与标志
Kubernetes v1.29：Mandala
与我们一起踏上 Kubernetes v1.29 这场宇宙探索之旅吧！
这个版本的灵感来源于 Mandala，是完美的宇宙的象征。我们紧密相连的发布团队约 40 人，在众多社区贡献者的支持下，克服重重挑战，为全球数百万用户带来喜悦。
Mandala 主题展现了我们社区成员之间的密切联系，就像由各路热情爱好者和专家共同编织的多姿多彩的画卷。每一位贡献者都像 Mandala 艺术中的独特图案，为项目注入了他们的独特活力。Kubernetes 的繁荣发展正是建立在这种协作和 Mandala 艺术中所体现的和谐之上的。
这次版本的标志，由 Mario Jason Braganza 设计（基础 Mandala 艺术作品是 Fibrel Ojalá 提供的），象征着 Kubernetes 项目及其团队构成的小小宇宙。
在 Mandala 象征着变革的精神引导下，Kubernetes v1.29 庆祝了我们项目的成长。就像 Kubernetes 宇宙中的每一颗星星，每位贡献者、用户和支持者都在照亮我们的道路。我们一起创造了一个充满无限可能的宇宙，每一次版本更新都是我们共同创造的成果。
#02
重大改进
以下是一些在 Kubernetes v1.29 版本发布后成为稳定特性的重要改进。
ReadWriteOncePod 持久卷访问模式
在 Kubernetes 世界里，卷访问模式定义了持久存储的使用方式。这些模式是持久卷（PersistentVolumes，简称 PV）和持久卷申请（PersistentVolumeClaims，简称 PVC）规范的一部分。当我们使用存储时，有不同的模型来描述存储的消耗。
举个例子，像网络文件共享这种存储系统，可能允许多个用户同时进行读写操作。在其他场景下，可能所有人都能读取数据，但不能进行写入。对于极其敏感的数据，可能只允许一个用户进行读写，而其他人则不能。
在 v1.22 版本之前，Kubernetes 为 PV 和 PVC 提供了三种访问模式：
- ReadWriteOnce：一个卷可以被单个节点以读写的方式挂载
- ReadOnlyMany：一个卷可以被多个节点以只读的方式挂载
- ReadWriteMany：一个卷可以被多个节点以读写的方式挂载
ReadWriteOnce 访问模式将卷访问限制在单个节点，这意味着同一个节点上的多个 Pod 可以对同一个卷进行读写。这对于某些应用来说可能是个大问题，特别是在那些出于数据安全考虑需要最多一个写入者的场景中。
为了应对这个问题，v1.22 版本引入了第四种访问模式 ReadWriteOncePod，作为 CSI 卷的 Alpha 特性。如果你创建了一个使用 ReadWriteOncePod 访问模式的 PVC 的 Pod，Kubernetes 会确保这个 Pod 是你整个集群中唯一一个可以读写该 PVC 的 Pod。到了 v1.29 版本，这个功能已经普遍可用。
节点卷扩展时对 CSI 驱动程序的 Secret 支持
在 Kubernetes 中，卷扩展操作可能涉及在节点上扩展卷，包括文件系统的调整。某些 CSI 驱动在节点扩展过程中需要 Secret，比如访问 SAN 网络的凭据，这在以下情况下尤为重要：
- 当一个 PersistentVolume 代表加密的块存储时，例如使用 LUKS，你可能需要提供一个密码短语来扩展设备。
- 为了进行各种验证，CSI 驱动在节点扩展时需要用到与后端存储系统通信的凭据。
为了满足这一需求，Kubernetes v1.25 版本中引入了 CSI Node Expand Secret 功能。这一功能允许在 NodeExpandVolumeRequest 中传递一个可选的 Secret 字段，由 CSI 驱动使用，以便在底层存储系统上进行节点卷扩展操作。到了 Kubernetes v1.29 版本，这个功能已经成为普遍可用的特性。
KMS v2 静态加密功能正式上线
在保障 Kubernetes 集群安全的众多考虑中，对存储的 API 数据进行静态加密是首要任务之一。KMS 提供了一个接口，允许使用外部密钥服务中存储的密钥来执行这种加密。随着 Kubernetes v1.29 版本的发布，KMS v2 已经稳定上线，带来了性能提升、密钥轮换、健康检查与状态监控以及可观测性方面的多项改进。这些改进为用户提供了一个靠谱的方案，可以对他们的 Kubernetes 集群中的所有资源进行加密。
更多关于这方面的信息，可以参考：
https://kep.k8s.io/3299
推荐使用 KMS v2。KMS v1 的功能门默认是关闭的。如果你想继续使用它，需要主动选择加入。
#03
升级为 beta 版的新特性
以下是一些在 Kubernetes v1.29 版本发布后升级为 beta 版本的新特性。
调度器的吞吐量是我们不断面临的挑战。QueueingHint 功能为提升重新排队的效率带来了新思路，能够显著降低无效的调度重试次数。
节点生命周期与污点管理分离
正如标题所述，此举旨在将执行基于污点的 Pod 驱逐的 TaintManager 从 NodeLifecycleController 中分离，并将它们变为两个独立的控制器：NodeLifecycleController 负责向不健康的节点添加污点，而 TaintManager 则负责删除带有 NoExecute 效果的污点节点上的 Pod。
清理基于 Secret 的遗留 ServiceAccount 令牌
Kubernetes 在 1.22 版本切换到了更安全的服务账户令牌，这些令牌具有时间限制，并与特定的 Pod 绑定。到了 1.24 版本，停止了基于 Secret 的遗留服务账户令牌的自动生成。随后，在 1.27 版本中开始标记仍在使用的自动生成的基于 Secret 的令牌的最后使用日期。
在 v1.29 版本中，为了减少可能的攻击面，LegacyServiceAccountTokenCleanUp 功能将那些长时间未使用（默认为 1 年）的遗留自动生成的基于 Secret 的令牌标记为无效，并在被标记为无效后再经过长时间（默认另外 1 年）未尝试使用的情况下自动将其移除。
更多信息可参见：
https://kep.k8s.io/2799
#04
新推出的 alpha 特性
使用 matchLabelKeys 定义 Pod 的亲和性或反亲和性
PodAffinity/PodAntiAffinity 将在 alpha 版本中引入一项增强功能。这将提高在滚动更新过程中计算准确性的能力。
nftables 作为 kube-proxy 的后端
目前 Linux 上 kube-proxy 的默认实现基于 iptables，这长期以来一直是 Linux 内核中首选的包过滤和处理系统（自 2001 年的 2.4 内核开始）。然而，iptables 的一些无法解决的问题促使开发了它的继任者 nftables。iptables 的开发基本已停止，新功能和性能改进主要集中在 nftables 上。
这个特性为 kube-proxy 增加了一个基于 nftables 的新后端，因为一些 Linux 发行版已开始淘汰和移除 iptables，而 nftables 声称解决了 iptables 的主要性能问题。
用于管理服务 IP 地址范围的 API
服务是一种抽象的方式，用于暴露运行在一组 Pod 上的应用。服务可以有一个集群级的虚拟 IP 地址，这个地址从在 kube-apiserver 标志中定义的预设 CIDR 中分配。但是，用户可能想在不重启 kube-apiserver 的情况下添加、移除或调整已分配给服务的现有 IP 范围。
这个特性通过使用两个新的 API 对象：ServiceCIDR 和 IPAddress，实现了一个新的分配器逻辑，允许用户通过创建新的 ServiceCIDR 动态增加可用的服务 IP 数量。这有助于解决 IP 耗尽或 IP 重新编号等问题。
为 containerd/kubelet/CRI 添加支持，允许根据运行时类别拉取镜像
Kubernetes v1.29 新增了根据 Pod 的 RuntimeClass 拉取容器镜像的功能。这个功能在 v1.29 版本下默认关闭，属于名为 RuntimeClassInImageCriApi 的特性门。
容器镜像可以是清单或索引。当拉取的镜像是一个索引时（即镜像索引含有按平台排序的镜像清单列表），容器运行时将使用平台匹配逻辑从索引中拉取合适的镜像清单。默认情况下，平台匹配逻辑会选择与执行镜像拉取的主机匹配的清单。这对于基于 VM 的容器可能有所限制，比如用户可能希望拉取一个镜像，意图将其作为基于 VM 的容器运行，例如 Windows Hyper-V 容器。
按运行时类别拉取镜像的特性支持基于指定的运行时类别拉取不同的镜像。这是通过引用由 （imageID, runtimeClass） 元组组成的镜像实现的，而不仅仅是 imageName 或 imageID。容器运行时可以选择支持这一特性。如果他们不支持，那么 Kubernetes v1.29 之前 kubelet 的默认行为将被保留。
对 Windows Pod 的 Pod 资源进行就地更新
作为 alpha 特性，Kubernetes Pod 现在可以在资源方面进行更改，允许用户在不重启 Pod 的情况下更改 Pod 的资源请求和限制。在 v1.29 版本中，这一功能现已支持 Windows 容器。
#05
毕业、弃用和移除功能
升级为稳定版
以下列出了所有升级为稳定版（也称为通用可用）的特性。有关包括新功能以及从 alpha 到 beta 升级的完整列表，请参阅：
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md
本版本共有 11 项增强功能升级为稳定版：
- 从 KCCM 的服务控制器中移除临时节点断言
- 为动态和静态分配保留节点端口范围
- API 服务器请求的优先级和公平性
- KMS v2 的改进
- 支持从 Kubernetes API 分页 LIST 查询
- ReadWriteOncePod 持久卷访问模式
- Kubernetes 组件健康 SLI
- CRD 验证表达式语言
- 在 CSI PV 源中引入 nodeExpandSecret
- 跟踪工作状态中的就绪 Pod
- Kubelet 资源指标端点
弃用和移除
移除与云提供商的树内集成
Kubernetes v1.29 默认情况下不再集成任何云提供商的内置集成。如果你之前依赖于树内云提供商集成（例如 Azure、GCE 或 vSphere），你可以：
- 启用等效的外部云控制器管理器集成（推荐）
- 通过将相关功能门设置为 false 来选择继续使用旧版集成；需要更改的功能门包括 DisableCloudProviders 和 DisableKubeletCloudCredentialProviders
启用外部云控制器管理器意味着你必须在集群控制平面内运行适当的云控制器管理器；它还要求在每个相关节点的 kubelet 上，以及整个控制平面（kube-apiserver 和 kube-controller-manager）中设置命令行参数 --cloud-provider=external。
有关如何启用和运行外部云控制器管理器的更多信息，请参阅：
https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/
以及：
https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/
如果你需要某个旧版树内提供商的云控制器管理器，请参阅以下链接：
- 云提供商 AWS：https://github.com/kubernetes/cloud-provider-aws
- 云提供商 Azure：https://github.com/kubernetes-sigs/cloud-provider-azure
- 云提供商 GCE：https://github.com/kubernetes/cloud-provider-gcp
- 云提供商 OpenStack：https://github.com/kubernetes/cloud-provider-openstack
- 云提供商 vSphere：https://github.com/kubernetes/cloud-provider-vsphere
更多详细信息请阅读：https://kep.k8s.io/2395
移除 v1beta2 流控 API 组
Kubernetes v1.29 版本中不再提供已弃用的 flowcontrol.apiserver.k8s.io/v1beta2 API 版本的 FlowSchema 和 PriorityLevelConfiguration。
如果你有使用已弃用 beta API 组的清单或客户端软件，应在升级到 v1.29 之前更改它们。详细信息和建议请参阅已弃用 API 的迁移指南：
https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-29
Node 对象中 kubeProxyVersion 字段的弃用
Node 对象的 .status.kubeProxyVersion 字段现在被标记为弃用，Kubernetes 项目计划在未来的版本中移除这个字段。这个已弃用的字段并不准确，而且历史上一直是由 kubelet 管理的 - 实际上 kubelet 并不了解 kube-proxy 的确切版本，甚至不知道 kube-proxy 是否在运行。
如果你在客户端软件中一直在使用这个字段，请立即停止 - 这个信息不可靠，而且该字段现已被弃用。
遗留的 Linux 包存储
请注意，在 2023 年 8 月，遗留的包存储（apt.kubernetes.io 和 yum.kubernetes.io）被正式弃用，Kubernetes 项目宣布了 Debian 和 RPM 包的社区拥有的包存储的通用可用性，可在 https://pkgs.k8s.io 获取。
这些遗留存储在 2023 年 9 月被冻结，并将在 2024 年 1 月完全消失。如果你目前还在依赖这些仓存储，你必须进行迁移。
这次弃用并不是直接与 v1.29 版本相关。更多细节，包括这些变化可能对你产生的影响以及如果你受到影响应采取的措施，请查阅遗留包仓库弃用公告：
https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/
#06
其他信息
想了解 Kubernetes v1.29 版本的完整详情，请查阅我们的发行说明：
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md
GitHub 下载链接：
https://github.com/kubernetes/kubernetes/releases/tag/v1.29.0
原文链接：https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/
