1.29 版本信息和更新操作

查看有关 IBM Cloud® Kubernetes Service版本 1.29 的信息。有关 Kubernetes 项目版本 1.29的更多信息，请参阅 Kubernetes 更改日志。

此版本已弃用。请尽快将您的仪表盘更新到受支持的版本。

此徽章表示 Kubernetes 版本 1.29 IBM Cloud Kubernetes Service — Kubernetes 版本 1.29 认证徽章

IBM Cloud Kubernetes Service 是 CNCF 软件一致性认证计划下版本的认证产品。Kubernetes 1.29 Kubernetes Kubernetes® 是基金会在美国和其他国家的注册商标，根据基金会的许可使用。Linux Linux

发布时间线

下表包含 IBM Cloud® Kubernetes ServiceV 1.29 的预期发布时间线。您可以将此信息用于规划目的，例如，估算版本可能变为不受支持的一般时间。

标记有短剑 (†) 的日期表示这是暂定时间，会随时更改。

IBM Cloud Kubernetes Service V 1.29
版本	是否受支持？	发布日期	不受支持的日期
1.29	是	2024 年 2 月 14 日	2025 年 7 月 31 日 `†`

准备更新

此信息汇总了将集群更新到 V 1.29时可能对已部署的应用程序产生影响的更新。要获取更改的完整列表，请查看社区 Kubernetes 更改日志和 IBM 版本更改日志 for V 1.29。您还可以查看 Kubernetes 有用的警告。

Ubuntu 24 的默认 cgroup 是 cgroup v2。 Ubuntu 24 不支持 cgroup v1。查看 cgroup v2 的 Kubernetes 迁移文档，并验证您的应用程序是否完全支持 cgroup v2。旧版本的 Java 存在一些已知问题，可能会导致工作负载出现内存不足 (OOM) 问题。

在更新主节点之前更新

下表说明了在更新 Kubernetes 主节点之前必须执行的操作。

在将主节点更新到 Kubernetes 1.29
Type	描述
不受支持: `v1beta2` 版本的 `FlowSchema` 和 `PriorityLevelConfiguration` API	迁移清单和 API 客户机以使用自 Kubernetes V 1.26以来可用的 `flowcontrol.apiserver.k8s.io/v1beta3` API 版本。有关更多信息，请参阅不推荐使用的 API 迁移指南- v1.29。
不支持： `CronJob` 时区规范	创建 `CronJob` 资源时，不再允许使用 `.spec.schedule` 设置 `CRON_TZ` 或 `TZ` 时区规范。迁移 `CronJob` 资源以改为使用 `.spec.timeZone`。请参阅不受支持的 TimeZone 规范以获取详细信息。
已更新额外的用户声明前缀	在 Kubernetes API 服务器审计记录中，额外的用户声明信息以 `cloud.ibm.com/authn_` 而不是 `authn_` 为前缀。如果应用程序已解析此信息，请相应地更新这些信息。
Tigera 操作程序名称空间迁移	添加并管理 Calico 安装。因此，Calico 资源在 `calico-system` 和 `tigera-operator` 名称空间 (而不是 `kube-system`) 中运行。这些名称空间配置为像 `kube-system` 名称空间一样具有特权。升级期间，Tigera 操作程序将 Calico 资源和定制从 `kube-system` 名称空间迁移到 `calico-system` 名称空间。您可以在迁移期间继续执行正常集群操作，因为在集群主节点升级完成后，迁移可能正在进行中。如果应用程序或操作工具依赖于在 `kube-system` 名称空间中运行的 Calico，请相应地更新这些应用程序或操作工具。在更新集群主服务器之前，请查看了解 Tigera 迁移部分。
Calico 定制资源短名称	对于新集群，将从 `globalnetworkpolicies.crd.projectcalico.org` 和 `hostendpoints.crd.projectcalico.org` 定制资源定义中除去 Calico 定制资源短名称 `gnp` 和 `heps`。升级后的集群将保留短名称。无论如何，如果 `kubectl` 命令依赖于短名称，请将其更新为使用 `globalnetworkpolicies` 和 `hostendpoints` 的标准名称。
旧服务帐户令牌清除	Kubernetes 旧服务帐户令牌清除程序会自动标记，失效和删除未使用的旧服务帐户令牌。标记会在一年内未使用时进行标记并失效，如果另一年未使用，那么会将其删除。您可以使用 `kubectl get secrets -A -l kubernetes.io/legacy-token-last-used -L kubernetes.io/legacy-token-last-used` 命令来确定上次使用旧服务帐户令牌的时间，并使用 `kubectl get secrets -A -l kubernetes.io/legacy-token-invalid-since -L kubernetes.io/legacy-token-invalid-since` 命令来确定是否有任何旧服务帐户令牌无效以及将来要删除的候选者。可以通过除去 `kubernetes.io/legacy-token-invalid-since` 标签来重新激活标记为无效的标记。有关这些标签的更多信息，请参阅 `kubernetes.io/legacy-token-last-used` 和 `kubernetes.io/legacy-token-invalid-since`。
已除去: Node `Hostname` 地址类型	Kubernetes 不再向 `.status.addresses` 添加 `Hostname` 地址类型。如果依赖于先前行为，请改为迁移到 `InternalIP` 地址类型。有关更多信息，请参阅相关 Kubernetes 社区问题

在更新主节点之后更新

下表说明了在更新 Kubernetes 主节点之后必须执行的操作。

将主节点更新为 Kubernetes 1.29 后要进行的更改
Type	描述
Tigera 操作程序名称空间迁移	集群主节点升级完成后，Tigera 操作程序名称空间迁移可能仍在进行中。对于较大的集群，迁移可能需要几个小时才能完成。在迁移期间，Calico 资源同时存在于 `kube-system` 和 `calico-system` 名称空间中。迁移完成后，将使用下一个集群主操作从 `kube-system` 名称空间中完全除去 Calico 资源。请等待迁移完成，然后再升级工作程序节点，因为在迁移期间更新，重新装入，替换或添加节点会使此过程需要更长时间才能完成。必须先完成迁移，然后才能允许集群升级到 V 1.30。要验证迁移是否完成，请运行以下命令。如果没有返回数据，则迁移完成。`kubectl get nodes -l projectcalico.org/operator-node-migration --no-headers --ignore-not-found ; kubectl get deployment calico-typha -n kube-system -o name --ignore-not-found`。如果应用程序或操作工具依赖于在 `kube-system` 名称空间中运行的 Calico，请相应地更新这些应用程序或操作工具。
定制 Calico 配置	定制 Calico 配置已更改。将为您迁移现有定制。但是，要在将来定制 Calico 配置，请参阅更改 Calico 最大传输单元(MTU) 和禁用端口映射插件。

了解 Tigera Operator 名称空间迁移

在 V 1.29中，引入了 Tigera Operator 来管理 Calico 资源。所有 Calico 组件都将从 kube-system 迁移到 calico-system 名称空间。在主升级过程中，将出现名为 Tigera Operator 的新部署，用于管理 Calico 组件 (例如 calico-node，calico-typha 和 calico-kube-controllers) 的迁移过程和生命周期。

在执行主更新之前，如果你的集群有任何受污染的节点，请确保你至少有 6 个未受污染的节点，以便 calico-typha pods可以有效地迁移。如果没有 6 个未受污染的节点，也可以完成以下步骤。

确保至少有 4 个未受污染的节点。
在 master 更新之前立即运行以下命令1.29减少 kube-system/calico-typha pod 要求为 1。
```
kubectl scale deploy -n kube-system calico-typha --replicas 1
```
更新之前，请检查Calico成分。仅当所有 Calico 组件都正常运行，启动和运行时，操作员才能启动其作业。如果 Calico 组件运行正常，那么命令针对每个组件返回的转出状态为 successfully rolled out。
```
kubectl rollout status -n kube-system deploy/calico-typha deploy/calico-kube-controllers ds/calico-node
```
继续主更新。

主升级完成后，某些 Calico 资源可能会保留在 kube-system 名称空间中。 Calico 不再使用这些资源，并且在迁移完成后不再需要这些资源。下一个主操作将除去这些主操作。请勿自行将其除去。

- "kind": "ConfigMap", "name": "calico-config"
- "kind": "Secret", "name": "calico-bgp-password"
- "kind": "Service", "name": "calico-typha"
- "kind": "Role", "name": "calico-node-secret-access"
- "kind": "RoleBinding", "name": "calico-node-secret-access"
- "kind": "PodDisruptionBudget", "name": "calico-kube-controllers"
- "kind": "PodDisruptionBudget", "name": "calico-typha"
- "kind": "ServiceAccount", "name": "calico-cni-plugin"
- "kind": "ServiceAccount", "name": "calico-kube-controllers"
- "kind": "ServiceAccount", "name": "calico-node"
- "kind": "ClusterRole", "name": "calico-cni-plugin-migration"
- "kind": "ClusterRole", "name": "calico-kube-controllers-migration"
- "kind": "ClusterRoleBinding", "name": "calico-cni-plugin-migration"
- "kind": "ClusterRoleBinding", "name": "calico-kube-controllers-migration"