Versions de Kubernetes et Kubernetes Engine (OKE)

Découvrez le schéma de gestion des versions de Kubernetes et la prise en charge de Kubernetes Engine (OKE) pour les différentes versions de Kubernetes.

Les numéros d'édition de Kubernetes se présentent au format x.y.z, où x est la Version majeure, y est la Version mineure et z est la Version de patch. 1.35.2. par exemple.

Le projet Kubernetes prend en charge les trois dernières versions mineures de Kubernetes.

Lorsque vous créez un cluster Kubernetes à l'aide de Kubernetes Engine, vous indiquez les éléments suivants :

Version de Kubernetes à exécuter sur les noeuds de plan de contrôle du cluster.
Version de Kubernetes à exécuter sur les noeuds de processus actifs dans le cluster. Les différents noeuds de processus actifs d'un même pool peuvent exécuter différentes versions de Kubernetes. Les différents pools de noeuds d'un cluster peuvent exécuter différentes versions de Kubernetes.

La version de Kubernetes que vous indiquez pour les noeuds de processus actif d'un cluster doit être identique à celle de Kubernetes exécutée sur les noeuds de plan de contrôle ou être une version de Kubernetes antérieure toujours compatible. Comme indiqué dans la stratégie de prise en charge des écarts de version de Kubernetes, une certaine variation de version est autorisée entre les noeuds de plan de contrôle et les noeuds de processus actifs d'un cluster :

Les noeuds de plan de contrôle doivent exécuter la même version de Kubernetes que celle exécutée sur les noeuds de processus actif, ou doivent avoir au maximum deux versions (ou trois versions, à partir de la version 1.28 de Kubernetes) devant eux.
Les noeuds de processus actifs peuvent exécuter une version de Kubernetes qui est en retard sur la version des noeuds de plan de contrôle de deux versions au maximum (ou trois versions, à partir de la version 1.28 de Kubernetes), mais pas plus. Si la version sur les noeuds de processus actif est supérieure à deux versions (ou trois versions, à partir de Kubernetes version 1.28) derrière la version sur les noeuds de plan de contrôle, les versions de Kubernetes sur les noeuds de processus actif et les noeuds de plan de contrôle sont incompatibles.
Les noeuds de processus dans un cluster ne doivent pas exécuter une version de Kubernetes plus récente que celle des noeuds de plan de contrôle associés.

Les restrictions garantissent que la version mineure prise en charge la plus ancienne des composants kubelet et kube-proxy exécutés sur les noeuds de processus actif d'un cluster est toujours compatible avec la version mineure prise en charge la plus récente des composants kube-apiserver, kube-scheduler, kube-controller-manager et cloud-controller-manager exécutés sur les noeuds de plan de contrôle du cluster.

Pour plus d'informations, reportez-vous à Stratégie de prise en charge des écarts de version de Kubernetes.

Prise en charge des versions mineures de Kubernetes

Remarque

A partir de la version 1.33 de Kubernetes, une version d'aperçu de Kubernetes Engine prend en charge la version de patch initiale de chaque version mineure de Kubernetes. La version de patch initiale d'une version mineure de Kubernetes a un numéro de version x.y.0, tel que 1.33.0. Nous prévoyons de mettre à disposition une version d'aperçu de Kubernetes Engine dans les 30 jours suivant le lancement en amont de la version initiale du patch Kubernetes. La version d'aperçu de Kubernetes Engine est uniquement destinée à un accès anticipé et à un test avec la version de patch Kubernetes initiale. En particulier, notez ce qui suit :

La prise en charge d'une version d'aperçu de Kubernetes Engine est limitée.
Pour les environnements de production, nous vous recommandons de ne pas utiliser de version d'aperçu de Kubernetes Engine.
Pour les environnements de production, nous vous recommandons d'attendre la version de production de Kubernetes Engine prenant en charge la version x.y.1 de Kubernetes, que nous prévoyons de rendre disponible en temps opportun après le lancement en amont de la version x.y.1 de Kubernetes.

Les versions mineures de Kubernetes introduisent généralement de nouvelles fonctionnalités et d'autres améliorations. Le projet Kubernetes publie régulièrement des versions mineures, trois fois par an.

Oracle surveille et valide les versions mineures publiées par le projet Kubernetes, et publie la prise en charge de Kubernetes Engine pour les versions mineures en temps opportun.

Kubernetes Engine prend en charge trois versions mineures de Kubernetes pour les nouveaux clusters. Pendant au moins 30 jours après l'annonce de la prise en charge d'une nouvelle version de Kubernetes, Kubernetes Engine continue de prendre en charge la quatrième version mineure de Kubernetes la plus ancienne disponible. Après cette période, l'ancienne version de Kubernetes cesse d'être prise en charge.

Lorsqu'une version mineure n'est plus prise en charge, vous ne pouvez pas :

Créez de nouveaux clusters exécutant cette version mineure.
Ajoutez de nouveaux pools de noeuds exécutant cette version mineure.

Oracle vous recommande donc de mettre à niveau tous les clusters existants qui exécutent actuellement une version mineure non prise en charge pour exécuter une version mineure prise en charge par Kubernetes Engine. Les clusters qui ne sont pas mis à niveau continueront à fonctionner comme prévu. Cependant, ils ne seront plus soutenus.

Vous pouvez mettre à niveau les noeuds de plan de contrôle via des versions mineures non prises en charge.

Versions ignorées lors de la mise à niveau

Kubernetes exige que vous mettiez à niveau les noeuds de plan de contrôle une version mineure à la fois. Toutefois, vous n'avez pas besoin de mettre à niveau les noeuds de processus actif une version mineure à la fois.

Prise en charge des versions de patch Kubernetes

Les versions de patch Kubernetes traitent généralement des bogues critiques ou des vulnérabilités de sécurité récemment identifiées dans une version mineure de Kubernetes. Le projet Kubernetes publie fréquemment des versions de patch, généralement une fois par mois, mais parfois plus fréquemment.

Oracle surveille et valide les versions de patch publiées par le projet Kubernetes, et publie la prise en charge de Kubernetes Engine pour les versions de patch critiques en temps opportun.

Lorsque Oracle vous informe de la prise en charge de Kubernetes Engine pour une nouvelle version de patch Kubernetes, nous vous recommandons de mettre à niveau dès que possible tous les clusters exécutant la version mineure correspondante de Kubernetes vers la dernière version de patch disponible. Vous disposez de trente jours après l'annonce de la prise en charge de Kubernetes Engine pour une nouvelle version de patch Kubernetes afin de mettre à niveau les clusters à partir d'une ancienne version de patch vers la nouvelle version de patch. Au bout de trente jours, les clusters exécutant l'ancienne version de patch ne sont plus pris en charge.

Bien que les clusters exécutant une ancienne version de patch cessent d'être pris en charge au bout de trente jours, l'ancienne version de patch peut continuer à être disponible pour sélection. Toutefois, Oracle vous recommande vivement de sélectionner la dernière version du patch.

Remarque sur la sélection de version de Kubernetes

Lorsque vous créez ou mettez à jour un cluster ou un pool de noeuds à l'aide de la console, de l'interface de ligne de commande et de l'API, vous indiquez la version de Kubernetes. Vous pouvez indiquer la version de Kubernetes de l'une des manières suivantes :

(Recommandé) Vous pouvez indiquer le numéro de version de Kubernetes au format major.minor (c'est-à-dire x.y). Dans ce cas, Kubernetes Engine utilise automatiquement la dernière version de patch prise en charge pour la version mineure indiquée. Il est recommandé d'utiliser le format x.y, car il permet à Kubernetes Engine de sélectionner automatiquement le patch le plus récent, le plus sécurisé et le plus stable disponible pour la version mineure que vous sélectionnez.
Vous pouvez indiquer le numéro de version de Kubernetes au format major.minor.patch (c'est-à-dire x.y.z). Dans ce cas, Kubernetes Engine utilise la version de patch Kubernetes que vous indiquez. L'utilisation du format x.y.z pour indiquer la version de Kubernetes est appropriée lorsqu'une organisation ou une stratégie de compatibilité requiert une version de patch spécifique.

Lors de l'utilisation de la console, les numéros de version de Kubernetes disponibles sont initialement affichés au format x.y. Une fois que vous avez sélectionné une version de Kubernetes au format x.y, vous pouvez éventuellement sélectionner Afficher les versions de patch et indiquer une version de patch prise en charge pour la version major.minor sélectionnée. Cependant, nous vous recommandons de sélectionner simplement une version de Kubernetes au format x.y afin de permettre à Kubernetes Engine de sélectionner automatiquement la version de patch pour la version mineure.

Lorsque vous utilisez l'interface de ligne de commande, vous pouvez obtenir les versions de Kubernetes disponibles au format x.y uniquement en incluant l'option --should-list-all-patch-versions false lors de l'utilisation des commandes oci ce cluster-options get ou oci ce node-pool-options get.

Lorsque vous utilisez l'API, vous pouvez obtenir les versions de Kubernetes disponibles au format x.y uniquement en incluant shouldListAllPatchVersions=false en tant que paramètre de requête lors de l'utilisation des opérations GetClusterOptions ou GetNodePoolOptions.

Annulation de la version de Kubernetes sur les noeuds gérés

Vous pouvez annuler la version de Kubernetes exécutée sur les noeuds gérés d'un pool de noeuds gérés existant en configurant le pool de noeuds avec une version de Kubernetes disponible antérieure et en remplaçant les noeuds gérés existants.

La version de Kubernetes que vous sélectionnez doit être disponible pour le pool de noeuds gérés et compatible avec la version de Kubernetes exécutée sur le plan de contrôle de cluster. Les versions disponibles pour un pool de noeuds gérés peuvent varier selon la location.

Pour afficher les versions de Kubernetes disponibles pour un pool de noeuds gérés, procédez comme suit :

Dans la console, affichez la liste Version lors de la modification du pool de noeuds.
Utilisez la commande oci ce node-pool-options get à l'aide de l'interface de ligne de commande.
Utilisez l'opération GetNodePoolOptions à l'aide de l'API.

La modification de la version de Kubernetes configurée pour un pool de noeuds gérés ne modifie pas la version de Kubernetes exécutée sur les noeuds gérés existants. Tant que vous n'avez pas remplacé les noeuds existants, la version de Kubernetes configurée pour le pool de noeuds peut différer des versions exécutées sur ses noeuds.

Pour terminer l'annulation, remplacez les noeuds gérés existants. Dans un cluster amélioré, vous pouvez cycler le pool de noeuds. Dans un cluster de base, supprimez et remplacez manuellement les noeuds gérés.

Lors de la mise à niveau ultérieure de la version Kubernetes du plan de contrôle de cluster, Kubernetes Engine valide à la fois la version de Kubernetes configurée pour chaque pool de noeuds gérés et les versions de Kubernetes exécutées sur les noeuds de processus actif. La mise à niveau du plan de contrôle échoue si l'un des deux est en dehors de l'écart de version autorisé pour la version du plan de contrôle cible.

Pour obtenir des instructions, reportez-vous à Annulation des noeuds gérés vers une version antérieure de Kubernetes.