1.29 informations sur la version et actions de mise à jour
Consultez les informations relatives à la version 1.29 de IBM Cloud® Kubernetes Service. Pour plus d'informations sur la Kubernetes 1.29, voir le journal des modificationsKubernetes.
Cette version est obsolète. Mettez à jour votre cluster vers une version supportée dès que possible.
IBM Cloud Kubernetes Service est un produit certifié Kubernetes pour la version 1.29 dans le cadre du programme de certification de conformité des logiciels de la CNCF Kubernetes. Kubernetes® est une marque The Linux Foundation aux États-Unis et dans d'autres pays, et est utilisée en vertu d'une licence de la Fondation Linux.
Calendrier de diffusion
Le tableau suivant indique le calendrier prévu pour la publication de la version 1.29 de IBM Cloud® Kubernetes Service. Vous pouvez utiliser ces informations à des fins de planification, par exemple pour estimer la durée générale pendant laquelle la version ne sera plus prise en charge.
Les dates avec l'indicateur représentant un poignard (†) sont provisoires et peuvent changer.
| Version | Pris en charge ? | Date de publication | Date de non prise en charge |
|---|---|---|---|
| 1.29 | Oui | 14 février 2024 | 30 juin 2025 † |
Préparation à la mise à jour
Ces informations résument les mises à jour susceptibles d'avoir un impact sur les applications déployées lorsque vous mettez à jour un cluster vers la version 1.29. Pour obtenir la liste complète des modifications, consultez le journal des modifications de la communauté Kubernetes et le journal des modifications de la versionIBM pour la version 1.29. Vous pouvez également passer en revue les avertissements utiles deKubernetes.
La version par défaut de cgroup pour Ubuntu 24 est cgroup v2. Dans Ubuntu 24, cgroup v1 n'est pas pris en charge. Consultez la documentation de migration Kubernetes pour cgroup v2 et vérifiez que vos applications prennent pleinement en charge cgroup v2. Il existe des problèmes connus avec les anciennes
versions de Java qui peuvent entraîner des problèmes de mémoire saturée (OOM) pour les charges de travail.
Mise à jour avant le maître
Le tableau suivant présente les actions que vous devez effectuer avant de mettre à jour le maître Kubernetes.
| Type | Description |
|---|---|
Non pris en charge: version v1beta2 de l'API FlowSchema et PriorityLevelConfiguration |
Migrer les manifestes et les clients de l'API pour utiliser la version de l'API flowcontrol.apiserver.k8s.io/v1beta3, qui est disponible depuis Kubernetes version 1.26. Pour plus d'informations, voir Obsolete API Migration Guide- v1.29. |
Non pris en charge : CronJob spécifications du fuseau horaire |
Lors de la création d'une ressource CronJob, il n'est plus possible de définir les spécifications des fuseaux horaires CRON_TZ ou TZ en utilisant .spec.schedule. Migrez vos ressources
CronJob pour utiliser .spec.timeZone à la place. Voir la spécification TimeZone non prise en charge pour plus de détails. |
| Préfixe de réclamation utilisateur supplémentaire mis à jour | Dans les enregistrements d'audit du serveur d'APIKubernetes, les informations de réclamation utilisateur supplémentaires sont préfixées avec cloud.ibm.com/authn_ au lieu de authn_. Si vos applications ont analysé ces informations, mettez-les à jour en conséquence. |
| Migration de l'espace de nom de l'opérateur tigera | Le composant opérateur tigera est ajouté et gère l'installation Calico. Par conséquent, les ressources Calico s'exécutent dans les espaces de nom calico-system et tigera-operator au lieu de kube-system.
Ces espaces de nom sont configurés pour être privilégiés comme l'espace de nom kube-system. Lors d'une mise à niveau, l'opérateur Tigera migre les ressources et les personnalisations Calico de l'espace de nom kube-system vers l'espace de nom calico-system. Vous pouvez poursuivre les opérations de cluster normales pendant la migration car la migration peut être en cours une fois la mise à niveau du maître cluster terminée. Si vos applications
ou vos outils d'opérations s'appuient sur Calico qui s'exécute dans l'espace de nom kube-system, mettez-les à jour en conséquence. Avant de mettre à jour votre maître de cluster, passez en revue les étapes décrites dans
le Comprendre la migration Tigera section. |
| Noms abrégés des ressources personnalisées Calico | Pour les nouveaux clusters, les noms abrégés de ressource personnalisée Calico gnp et heps sont supprimés des définitions de ressource personnalisée globalnetworkpolicies.crd.projectcalico.org et
hostendpoints.crd.projectcalico.org. Les clusters mis à niveau conservent les noms abrégés. Dans les deux cas, si vos commandes kubectl s'appuient sur les noms abrégés, mettez-les à jour pour utiliser les
noms standard de globalnetworkpolicies et hostendpoints à la place. |
| Nettoyage du jeton de compte de service existant | Kubernetes legacy service account token cleaner affecte automatiquement des libellés, invalide et supprime
les jetons de compte de service existants inutilisés. Les jetons sont étiquetés et invalidés lorsqu'ils sont inutilisés pendant une année, puis, s'ils sont inutilisés pendant une autre année, supprimés. Vous pouvez utiliser la commande
kubectl get secrets -A -l kubernetes.io/legacy-token-last-used -L kubernetes.io/legacy-token-last-used pour déterminer à quel moment un jeton de compte de service existant a été utilisé pour la dernière fois et la commande
kubectl get secrets -A -l kubernetes.io/legacy-token-invalid-since -L kubernetes.io/legacy-token-invalid-since pour déterminer si des jetons de compte de service existants ne sont pas valides et s'ils sont candidats à
la suppression. Les jetons étiquetés comme non valides peuvent être réactivés en supprimant le libellé kubernetes.io/legacy-token-invalid-since. Pour plus d'informations sur ces libellés, voir kubernetes.io/legacy-token-last-used et kubernetes.io/legacy-token-invalid-since. |
Retiré: Node Hostname Type d'adresse |
Kubernetes n'ajoute plus le type d'adresse Hostname à .status.addresses. Si vous vous basez sur le comportement précédent, migrez vers le type d'adresse InternalIP à la place. Pour plus d'informations,
voir le problème de communautéKubernetes associé. |
Mise à jour après le maître
Le tableau suivant présente les actions que vous devez effectuer après avoir mis à jour le maître Kubernetes.
| Type | Description |
|---|---|
| Migration de l'espace de nom de l'opérateur tigera | Une fois la mise à niveau du maître cluster terminée, la migration de l'espace de nom de l'opérateur Tigera peut être toujours en cours. Pour les clusters plus grands, la migration peut prendre plusieurs heures. Lors de la migration,
des ressources Calico existent dans les espaces de nom kube-system et calico-system. Une fois la migration terminée, les ressources Calico sont entièrement retirées de l'espace de nom kube-system avec l'opération de maître cluster suivante. Attendez la fin de la migration avant de mettre à niveau les noeuds worker car la mise à jour, le rechargement, le remplacement ou l'ajout de noeuds lors de la migration rend le processus
plus long. La migration doit être effectuée avant que votre cluster soit autorisé à effectuer une mise à niveau vers la version 1.30. Pour vérifier que la migration est terminée, exécutez les commandes suivantes. Si aucune donnée n'est
renvoyée, la migration est terminée.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. Si vos
applications ou vos outils d'opération s'appuient sur Calico qui s'exécute dans l'espace de nom kube-system, mettez-les à jour en conséquence. |
| Personnalisation de la configuration de Calico | La personnalisation de votre configuration Calico a été modifiée. Vos personnalisations existantes sont migrées pour vous. Toutefois, pour personnaliser votre configuration Calico à l'avenir, voir Modification de l'unité de transmission maximale(MTU)Calico et Désactivation du plug-in de mappe de port. |
Description de la migration de l'espace de nom de l'opérateur Tigera
Dans la version 1.29, l'opérateur Tigera a été introduit pour gérer les ressources Calico. Tous les composants Calico sont migrés de kube-system vers l'espace de nom calico-system. Lors du processus de mise à niveau
du maître, un nouveau déploiement apparaît, appelé opérateur Tigera, qui gère le processus de migration et le cycle de vie des composants Calico, tels que calico-node, calico-typha et calico-kube-controllers.
Avant d'effectuer une mise à jour principale, si votre cluster comporte des nœuds corrompus, assurez-vous que vous disposez d'au moins 6 nœuds non corrompus afin que le calico-typha les pods peuvent être migrés efficacement. Si
vous n'avez pas 6 nœuds non contaminés, vous pouvez également suivre les étapes suivantes.
-
Assurez-vous que vous disposez d'au moins 4 nœuds intacts.
-
Exécutez la commande suivante immédiatement avant la mise à jour principale vers 1.29 pour réduire le
kube-system/calico-typhaexigences du pod à 1.kubectl scale deploy -n kube-system calico-typha --replicas 1 -
Avant la mise à jour, vérifiez l'état du Calico Composants. L'opérateur peut démarrer son travail uniquement lorsque tous les composants Calico sont sains, opérationnels et en cours d'exécution. Si les composants Calico sont sains, le statut de déploiement renvoyé par la commande pour chaque composant est
successfully rolled out.kubectl rollout status -n kube-system deploy/calico-typha deploy/calico-kube-controllers ds/calico-node -
Continuez la mise à jour principale.
-
Une fois la mise à niveau du maître terminée, certaines ressources Calico peuvent rester dans l'espace de nom
kube-system. Ces ressources ne sont plus utilisées par Calico et ne sont plus nécessaires une fois la migration terminée. L'opération maître suivante les supprime. Ne les retirez pas vous-même.- "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"