Documentation Oracle Cloud Infrastructure

Versions de Kubernetes prises en charge

Découvrez les versions de Kubernetes actuellement prises en charge par Kubernetes Engine (OKE), ainsi que les détails des versions précédemment prises en charge et la prise en charge prévue pour les versions futures.

Lorsque la prise en charge par Kubernetes Engine d'une nouvelle version de Kubernetes est annoncée, une ancienne version de Kubernetes cesse par la suite d'être prise en charge. Oracle vous recommande de mettre à niveau les clusters existants pour utiliser la version de Kubernetes la plus récente prise en charge par Kubernetes Engine.

Cette rubrique répertorie les éléments suivants :

Versions de Kubernetes actuellement prises en charge

Kubernetes Engine prend en charge trois versions 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 la plus ancienne de Kubernetes disponible. Après cette période, l'ancienne version de Kubernetes cesse d'être prise en charge.

Lorsque vous créez un cluster avec Kubernetes Engine, Oracle vous recommande d'utiliser la version de Kubernetes la plus récente prise en charge par Kubernetes Engine. Lorsque Oracle annonce la prise en charge de Kubernetes Engine pour une nouvelle version de Kubernetes, Oracle vous recommande de mettre à niveau les clusters existants pour utiliser cette nouvelle version de Kubernetes dès que possible.

Calendrier de lancement

Kubernetes Engine (OKE) prend en charge les versions de Kubernetes suivantes pour les nouveaux clusters :

Version secondaire Kubernetes Version de patch Kubernetes prise en charge par OKE Date de lancement de la version mineure en amont Date de fin de vie de la version mineure en amont OKE - Date de lancement OKE - Date de fin de vie
1.33 1.33.1 2025-04-23 2026-06-28 2025-06-17 1.33 is supported for 30 days after 1.36.1 OKE Release Date (planned)
1.33 1.33.0 2025-04-23 2026-06-28 2025-05-12

(Aperçu uniquement. Reportez-vous à Remarques)

 1.33 is supported for 30 days after 1.36.1 OKE Release Date (planned)
1.32 1.32.1 2024-12-11 2026-02-28 2025-03-18 1.32 is supported for 30 days after 1.35.1 OKE Release Date (planned)
1.31 1.31.10 2 024-8-13 2 025-10-28 2 025-7-30 1.31 est pris en charge pendant 30 jours après la date de version OKE 1.34.1 (prévue)
1.31 1.31.1 2024-08-13 2025-10-28 2024-11-25 2025-09-01
1.30 1.30.10 2024-04-17 2025-06-28 2025-04-09 2025-07-21
1.30 1.30.1 2024-04-17 2025-06-28 2024-07-23 2025-05-13

Avis de non-responsabilité juridique : le tableau est destiné à présenter notre orientation produit générale À titre d'information uniquement. Il ne peut être intégré à aucun contrat. Elles ne constituent pas un engagement de la part d'Oracle à fournir du matériel, du code ou des fonctions, et ne doivent étayer aucune prise de décisions d'achat. Le développement, la commercialisation, la mise à disposition, et les tarifs des fonctions ou fonctionnalités décrites pour les produits d'Oracle peuvent faire l'objet d'une modification et restent à la seule discrétion d'Oracle Corporation.

Remarques sur la prise en charge de Kubernetes Engine pour Kubernetes version 1.33.0

La prise en charge de Kubernetes Engine pour la version 1.33.0 de Kubernetes est une version d'aperçu de Kubernetes Engine. Cette version d'aperçu de Kubernetes Engine est uniquement destinée aux accès anticipés et aux tests avec la version 1.33.0 de Kubernetes.

En particulier, notez ce qui suit :

  • Cette version d'aperçu de Kubernetes Engine a une prise en charge limitée et n'est disponible que dans le domaine OC1.
  • Pour les environnements de production, nous vous recommandons de ne pas utiliser cette 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 Kubernetes version 1.33.1, que nous prévoyons de mettre à disposition en temps opportun après le lancement en amont de Kubernetes version 1.33.1.

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.30

Notez que la prise en charge de Kubernetes Engine pour Kubernetes version 1.30 introduit également des modifications du comportement par défaut du moteur Kubernetes en ce qui concerne la réservation de l'UC et de la mémoire. Sur les clusters exécutant les versions 1.30 et ultérieures de Kubernetes, les ressources d'UC et de mémoire pour les noeuds gérés sont réservées par défaut, à l'aide des indicateurs de kubelet --kube-reserved et --system-reserved respectivement (comme recommandé dans Meilleures pratiques : réservation de ressources pour les démons système de système d'exploitation et Kubernetes). Par conséquent, sur les clusters exécutant Kubernetes version 1.30 et versions ultérieures, il existe une différence entre le total des ressources d'un noeud et les ressources disponibles pour les charges globales à demander. Pour plus d'informations, reportez-vous à Meilleures pratiques : réservation de ressources pour les démons système de système d'exploitation et Kubernetes.

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.28

Dans la version 1.28 de Kubernetes, la stratégie d'écart de Kubernetes s'est étendue. Avant la version 1.28 de Kubernetes, la stratégie d'écart exigeait que les noeuds de plan de contrôle d'un cluster n'aient pas plus de deux versions d'avance sur les noeuds de processus actif. A partir de la version 1.28 de Kubernetes, la stratégie d'écart de Kubernetes permet aux noeuds de plan de contrôle d'avoir jusqu'à trois versions d'avance sur les noeuds de processus actif. Reportez-vous à Stratégie de prise en charge des écarts de version de Kubernetes.

Kubernetes Engine applique la stratégie d'écart étendue aux clusters exécutant Kubernetes version 1.28 et ultérieure.

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.27

Kubernetes version 1.27 a arrêté de servir l'API Kubernetes en phase d'abandon suivante :

  • CSIStorageCapacity (version d'API storage.k8s.io/v1beta1)

Pour plus d'informations sur la migration à partir des API en phase d'abandon, reportez-vous au Guide de migration des API en phase d'abandon de Kubernetes.

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.26

Notez que la version 1.26 de Kubernetes a arrêté de servir un certain nombre d'API Kubernetes en phase d'abandon, notamment :

  • FlowSchema (version d'API flowcontrol.apiserver.k8s.io/v1beta1)
  • HorizontalPodAutoscaler (redimensionnement automatique/version d'API v2beta2)
  • PriorityLevelConfiguration (version d'API flowcontrol.apiserver.k8s.io/v1beta1)

Pour plus d'informations sur la migration à partir des API en phase d'abandon, reportez-vous au Guide de migration des API en phase d'abandon de Kubernetes.

La prise en charge de Kubernetes version 1.26.7 a été publiée pour résoudre les problèmes en amont suivants avec Kubernetes version 1.26.2 :

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.25

La version 1.25 de Kubernetes a arrêté de servir un certain nombre d'API Kubernetes en phase d'abandon, notamment :

  • CronJob (version d'API batch/v1beta1)
  • EndpointSlice (version d'API discovery.k8s.io/v1beta1)
  • Evénement (version d'API events.k8s.io/v1beta1)
  • HorizontalPodAutoscaler (redimensionnement automatique/version d'API v2beta1)
  • PodDisruptionBudget (version d'API policy/v1beta1)
  • PodSecurityPolicy (version d'API policy/v1beta1)
  • RuntimeClass (version d'API node.k8s.io/v1beta1)

Pour plus d'informations sur la migration à partir des API en phase d'abandon, reportez-vous au Guide de migration des API en phase d'abandon de Kubernetes.

La prise en charge de Kubernetes version 1.25.12 a été publiée pour résoudre les problèmes en amont suivants avec Kubernetes version 1.25.4 :

Remarque

Le projet Kubernetes en amont a abandonné les stratégies de sécurité de pod dans Kubernetes version 1.21 et a enlevé la fonctionnalité dans la version 1.25 de Kubernetes. Par conséquent, Kubernetes Engine ne prend pas en charge les stratégies de sécurité de pod et le contrôleur d'admission PodSecurityPolicy dans les clusters exécutant Kubernetes versions 1.25 et ultérieures.

Si vous avez besoin de fonctionnalités similaires, envisagez plutôt d'utiliser les normes de sécurité de pod Kubernetes et le contrôleur d'admission PodSecurity (avec les stratégies privilégiées, de référence et restreintes). Par défaut, Kubernetes Engine active le contrôleur d'admission PodSecurity dans les clusters exécutant Kubernetes version 1.23 et ultérieure, afin de prendre en charge les normes de sécurité de pod. Pour plus d'informations sur les normes de sécurité de pod Kubernetes et le contrôleur d'admission PodSecurity, reportez-vous à Normes de sécurité de pod dans la documentation Kubernetes.

Vous pouvez également envisager d'utiliser d'autres alternatives développées dans l'écosystème Kubernetes pour appliquer les stratégies.

Si vous décidez de passer de l'utilisation des stratégies de sécurité de pod et du contrôleur d'admission PodSecurityPolicy à l'utilisation des normes de sécurité de pod et du contrôleur d'admission PodSecurity, reportez-vous à Migration de PodSecurityPolicy vers le contrôleur d'admission PodSecurity intégré dans la documentation Kubernetes. Il est important de terminer la migration avant de créer un cluster exécutant Kubernetes version 1.25 ou avant de mettre à niveau un cluster Kubernetes version 1.24 existant pour exécuter Kubernetes version 1.25. Notez également que la console offre un moyen pratique de désactiver l'utilisation du contrôleur d'admission PodSecurityPolicy dans les clusters Kubernetes existants créés et gérés par Kubernetes Engine (reportez-vous à Utilisation de la console pour désactiver le contrôleur d'admission PodSecurityPolicy).

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.22

Notez que la version 1.22 de Kubernetes a arrêté de servir un certain nombre d'API Kubernetes en phase d'abandon, notamment :

  • Ressources de webhook
  • CustomResourceDefinition
  • APIService
  • TokenReview
  • SubjectAccessReview ressources
  • CertificateSigningRequest
  • Location
  • Entrant
  • IngressClass
  • Ressources RBAC
  • PriorityClass
  • Ressources Storage

Pour plus d'informations sur la migration à partir des API en phase d'abandon, reportez-vous au Guide de migration des API en phase d'abandon de Kubernetes.

Prise en charge planifiée des futures versions de Kubernetes

La prise en charge de Kubernetes Engine est actuellement planifiée pour les versions suivantes de Kubernetes. Notez que les dates futures peuvent être modifiées sans préavis. En outre, prenez note de l'avis de limitation de responsabilité suivant le tableau.

Version secondaire Kubernetes Version de patch Kubernetes prise en charge par OKE Date de lancement de la version mineure en amont Date de fin de vie de la version mineure en amont OKE - Date de lancement
1.34 To Be Confirmed To Be Confirmed To Be Confirmed To Be Confirmed
1.35 To Be Confirmed To Be Confirmed To Be Confirmed To Be Confirmed
1.36 A confirmer A confirmer A confirmer À confirmer

Avis de non-responsabilité juridique : Le tableau est destiné à présenter notre orientation produit générale. Il est fourni à titre d'information exclusivement, et ne peut être intégré à aucun contrat. Elles ne constituent pas un engagement de la part d'Oracle à fournir du matériel, du code ou des fonctions, et ne doivent étayer aucune prise de décisions d'achat. Le développement, la publication, les dates et les tarifs des caractéristiques ou fonctionnalités décrites pour les produits Oracle sont susceptibles d'être modifiés et relèvent de la seule discrétion d'Oracle Corporation.

Versions de Kubernetes précédemment prises en charge

Auparavant, Kubernetes Engine prenait en charge les versions de Kubernetes suivantes :

Version de Kubernetes Fin de la prise en charge
1.29.10 17 avril 2025
1.29.1 21 février 2025
1.28.10 January 27, 2025
1.28.2 October 8, 2024
1.27.10 August 27, 2024
1.27.2 May 21, 2024
1.26.7 April 29, 2024
1.26.2 October 13, 2023
1.25.12 February 15, 2024
1.25.4 October 13, 2023
1.24.1 September 26, 2023
1.23.4 June 22, 2023
1.22.5 February 22, 2023
1.21.5 October 13, 2022
1.20.11 July 19, 2022
1.20.8 November 7, 2021
1.19.15 April 22, 2022
1.19.12 November 7, 2021
1.19.7 August 13, 2021
1.18.10 February 9, 2022
1.17.13 September 8, 2021
1.17.9 April 17, 2021
1.16.15 April 17, 2021
1.15.12 February 2, 2021
1.15.7 February 2, 2021
1.14.8 December 15, 2020
1.13.x March 21, 2020
1.12.7 January 29, 2020
1.12.6 April 15, 2019
1.11.9 September 9, 2019
1.11.8 April 15, 2019
1.11.x versions prior to 1.11.8 March 13, 2019
1.10.x April 12, 2019
1.9.x December 11, 2019
1.8.x September 7, 2018

Remarques sur la prise en charge par le moteur Kubernetes de Kubernetes version 1.20

Avec l'annonce de la prise en charge de Kubernetes version 1.20.8, l'exécution de conteneur utilisée par Kubernetes Engine passe de Docker à CRI-O. Toutefois, vous n'avez pas à modifier les images Docker existantes car elles sont compatibles avec OCI (Open Container Initiative). En ce qui concerne Kubernetes, toutes les images conformes à OCI sont identiques.

Tenez compte des éléments suivants :

  • CRI-O est une implémentation de l'interface d'exécution de conteneur (CRI) Kubernetes, qui permet l'utilisation d'exécutions compatibles OCI. Le CRI-O peut extraire vos images Docker existantes et les exécuter sur vos clusters Kubernetes version 1.20.8.
  • Lors de l'utilisation de l'exécution Docker, la configuration par défaut capture la sortie standard et les flux d'erreurs standard des conteneurs à l'aide du format JSON. En revanche, le CRI-O utilise le format Logrus. Si vous utilisez un outil de journalisation tel que Fluentd ou Fluent Bit, mettez à jour la configuration de l'outil pour utiliser un nouvel analyseur pour analyser les journaux CRI. Par exemple :
  • Vous pouvez disposer d'un workflow dans un cluster qui s'appuie sur le socket docker sous-jacent /var/run/docker.sock (un modèle souvent appelé Docker dans Docker). A partir de la version 1.20.8 de Kubernetes, un tel workflow ne fonctionne plus.
  • Si vous avez déjà utilisé l'interface de ligne de commande Docker pour exécuter des commandes sur un hôte, vous devez utiliser crictl (une interface de ligne de commande pour les exécutions de conteneur compatibles CRI) à la place.
  • Le projet Kubernetes en amont est en phase d'abandon de Docker en tant qu'exécution de conteneur après la version 1.20 de Kubernetes.

Pour en savoir plus :

  • Pour plus d'informations sur Kubernetes 1.20.8, reportez-vous au changelog Kubernetes 1.20.8.
  • Reportez-vous à la FAQ sur l'abandon de Dockershim pour plus d'informations sur l'abandon de l'adaptateur dockershim (qui permettait précédemment à la kubelet d'interagir avec Docker comme si Docker était une exécution compatible CRI)