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.33.1. 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
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.
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.
- 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. Kubernetes exige que vous mettiez à niveau les noeuds de plan de contrôle une version mineure à la fois. Toutefois, il n'est pas nécessaire 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.