Cette page explique comment les abandons de fonctionnalités et d'API causés par Kubernetes et d'autres dépendances fonctionnent avec Google Kubernetes Engine (GKE). Cette page inclut également des tableaux avec des informations concernant les abandons en amont spécifiques. Pour savoir comment visualiser votre niveau d'exposition aux prochains abandons, consultez la section Afficher les insights et les recommandations d'abandons.
Que sont les abandons de Kubernetes ?
Les clusters GKE sont basés sur le système de gestion de clusters Open Source Kubernetes. L'ensemble des fonctionnalités de Kubernetes évolue avec le temps et, tout comme des nouvelles fonctionnalités sont introduites au fil du temps, il est parfois nécessaire de supprimer une fonctionnalité. Une fonctionnalité peut également passer de la phase bêta à la phase de disponibilité générale. Le règlement relatif aux abandons de Kubernetes garantit que les utilisateurs disposent d'un processus prévisible afin de pouvoir migrer depuis une API ou une fonctionnalité obsolète avant sa suppression.
Une fois la période d'abandon terminée, lorsqu'une fonctionnalité ou une API est supprimée, vous ne pouvez plus l'utiliser à partir de la version mineure GKE correspondante. Si un cluster dépendait d'une fonctionnalité ou d'une API obsolète, le fonctionnement peut être altéré.
Abandons causés par d'autres dépendances en amont
Outre les fonctionnalités et les API de Kubernetes, GKE fournit également des fonctionnalités reposant sur d'autres fournisseurs, telles que des images de nœuds Windows sauvegardées par Microsoft, et des images de nœuds Ubuntu sauvegardées par Canonical. Lorsque ces fournisseurs en amont abandonnent ou arrêtent la prise en charge d'une fonctionnalité, GKE peut être amené à supprimer la fonctionnalité correspondante. Les tableaux de cette page fournissent également des informations concernant les abandons et suppressions à venir liés à des dépendances en amont, en plus de Kubernetes.
Impact des abandons de Kubernetes sur GKE
L'exécution d'applications sur GKE implique une responsabilité partagée entre vous et GKE.
En tant qu'utilisateur, vous devez évaluer et limiter les risques d'exposition aux fonctionnalités et aux API obsolètes qui seront supprimées dans les versions mineures à venir de Kubernetes. Dans les sections suivantes, vous découvrirez comment GKE facilite ce processus en détectant l'utilisation de fonctionnalités et d'API Kubernetes obsolètes, en partageant des insights sur cette utilisation et en fournissant des recommandations sur la migration vers des fonctionnalités et des API compatibles avec les versions mineures à venir.
Si GKE détecte qu'un cluster utilise une fonctionnalité qui sera supprimée dans une version mineure à venir de Kubernetes, les mises à niveau automatiques du cluster vers la version mineure suivante sont suspendues, et GKE partage un insight et une recommandation d'abandon.
Que se passe-t-il lorsque GKE met en pause les mises à niveau automatiques ?
Si GKE détecte l'utilisation d'une fonctionnalité ou d'une API obsolète, il met en veille les mises à niveau automatiques afin d'empêcher la mise à niveau de votre cluster dans un état défectueux. Les mises à niveau vers la version mineure de Kubernetes suivante sont suspendues, mais GKE continue de fournir des mises à niveau de correctifs au cluster sur la version mineure actuelle. Par exemple, si un cluster est à la version 1.21.11-gke.1100 et comporte des appels à des API obsolètes qui seront supprimées dans la version 1.22, GKE interrompt la mise à niveau automatique vers la version 1.22. Toutefois, GKE ne met pas en veille la mise à niveau automatique vers une nouvelle version de correctif, 1.21.11-gke.1900.
Étant donné que GKE ne peut pas garantir que toute l'utilisation est détectée, il ne peut pas garantir que les mises à niveau seront toujours mises en pause lorsqu'une fonctionnalité ou une API obsolète est utilisée. Pour vous assurer qu'un cluster n'est pas mis à niveau, vous devez utiliser des exclusions de maintenance.
Quand GKE reprend-il les mises à niveau automatiques ?
Une fois que GKE n'a pas détecté d'utilisation de la fonctionnalité obsolète ou des appels d'API obsolètes depuis 30 jours, le cluster est automatiquement mis à niveau si la version mineure suivante est la version par défaut de la version disponible du cluster. Pour savoir quand la version mineure devient la version disponible par défaut de votre cluster, consultez le calendrier des lancements.
Si GKE continue de détecter l'utilisation de la fonctionnalité obsolète sur le cluster, il laisse le cluster utiliser sa version mineure actuelle jusqu'à la date de fin de la période de compatibilité.
Les dates de fin de la période d'assistance des versions mineures sont disponibles dans le calendrier de publication. Étant donné que la date de fin de l'assistance pour une version mineure dépend de l'inscription au canal de publication, assurez-vous de vous référer à la date correcte qui reflète le canal de publication de votre cluster :
- Canaux de publication autres que Extended : si votre cluster est inscrit dans les canaux Rapid, Standard ou Stable, ou s'il n'est inscrit dans aucun canal de publication, cette date correspond à la fin de la période de compatibilité standard de la version mineure.
- Canal Extended : si votre cluster est inscrit au canal Extended, GKE ne met pas à niveau automatiquement votre cluster à partir de la version mineure avant la fin de l'assistance Extended.
Une fois cette date atteinte, le cluster est automatiquement mis à niveau vers la version mineure suivante. L'environnement du cluster peut être altéré, car la fonctionnalité supprimée est encore utilisée. Pour en savoir plus, consultez la section Mises à niveau automatiques à la fin de la période d'assistance.
Que sont les insights et les recommandations d'abandon ?
Si GKE détecte qu'un cluster utilise une fonctionnalité qui sera supprimée dans une version mineure à venir de Kubernetes, GKE partage un insight et une recommandation d'abandon qui vous avertissent de l'utilisation d'une fonctionnalité obsolète par votre cluster. Cet insight fournit des informations sur la dernière utilisation détectée ainsi que des informations supplémentaires en fonction du type d'abandon. Pour en savoir plus sur l'affichage de ces informations, consultez la page Afficher les insights et recommandations d'abandon.
Évaluer et limiter l'exposition aux futurs abandons de Kubernetes
GKE fournit des guides de migration qui vous indiquent comment migrer des fonctionnalités et API obsolètes vers les versions compatibles avec la version mineure à venir. Pour obtenir la liste des abandons à venir et des guides de migration, consultez la page Informations sur les abandons de Kubernetes.
Bien que GKE partage les insights sur les clusters qu'il a détectés comme étant exposés à un abandon, il n'est pas garanti que tous les clusters exposés à un abandon seront bien détectés. Par exemple, si une fonctionnalité obsolète n'a pas été utilisée au cours des 30 derniers jours, GKE ne détecte pas d'utilisation et ne génère aucun insight ni aucune recommandation.
Vous devez évaluer indépendamment l'exposition de votre environnement de cluster aux futurs abandons avant de passer à la version mineure suivante. Vous pouvez exercer un contrôle sur le processus de mise à niveau en choisissant un Canal de publication, en utilisant des Intervalles de maintenance et exclusions, ou avec une Mise à jour manuelle de vos clusters si vous avez déterminé qu'ils ne sont pas exposés à des abandons sur la version mineure suivante.
Résoudre l'exposition aux abandons Kubernetes
Vous pouvez intervenir en examinant les abandons à venir. Utilisez Afficher les insights et recommandations d'abandon pour déterminer si votre cluster est exposé et utilisez des guides de migration pour limiter l'exposition avant que la dernière version mineure compatible n'atteigne la fin de la période de compatibilité.
Une fois que vous avez apporté des modifications pour cesser d'utiliser des API ou des fonctionnalités obsolètes dans votre cluster, GKE attend qu'il n'ait plus observé d'utilisation de ces API ou fonctionnalités pendant 30 jours, puis libère les mises à niveau automatiques. Les mises à niveau automatiques se déroulent selon le calendrier des lancements.
Vous pouvez également mettre à niveau votre cluster manuellement si vous avez vérifié que la mise à niveau n'entraîne pas de perturbations dans votre environnement de cluster. Pour ce faire, commencez par créer un cluster de test et vérifiez si la mise à niveau entraîne des interruptions. Si ce n'est pas le cas, vous pouvez procéder à la mise à niveau manuelle de votre cluster.
Lorsque vous ignorez une recommandation, vous ne faites que la masquer pour tous les utilisateurs. Les mises à niveau automatiques restent en pause jusqu'à ce que vous migriez hors des fonctionnalités obsolètes et qu'aucune utilisation de ces fonctionnalités ne soit détectée par GKE pendant 30 jours consécutifs.
Informations sur les abandons Kubernetes
Les sections suivantes fournissent des informations sur les abandons permanents, y compris des guides expliquant comment migrer vers des fonctionnalités ou des API compatibles avec les versions mineures de Kubernetes actuellement disponibles. Vous pouvez consulter ces tableaux pour vérifier si GKE détecte et signale l'utilisation avec des insights et recommandations.
Ces tableaux ne fournissent des informations que sur les abandons en cours et omettent celles précédemment incluses pour les fonctionnalités ou les API obsolètes dont les versions ont largement dépassé leur date de fin de compatibilité.
Abandons de fonctionnalités Kubernetes
Le tableau suivant décrit les fonctionnalités GKE en cours d'abandon, ainsi que la version dans laquelle ces fonctionnalités ne sont plus disponibles :
| Nom | Obsolète | Supprimé | En savoir plus | GKE détecte-t-il et signale-t-il l'utilisation ? |
|---|---|---|---|---|
| Mode cgroupv1 de Linux | Version 1.31 de GKE | À déterminer | Migrer des nœuds vers Linux cgroupv2 | Non |
| Suppression de l'analyse des failles de sécurité de l'édition Standard de GKE | 23 juillet 2024 | 31 juillet 2024 | Suppression de l'analyse des vulnérabilités de l'édition GKE Standard | Non |
| Certificats TLS signés avec l'algorithme SHA-1 | Version de GKE 1.24 | Version de GKE 1.29 | Suppression de la compatibilité des certificats TLS SHA-1 | Oui |
| Plug-in d'authentification intégré pour les clients Kubernetes | Version de GKE 1.22 | Version de GKE 1.25 | Plug-in d'authentification obsolète pour les clients Kubernetes | Non |
| PodSecurityPolicy | Version de GKE 1.21 | Version de GKE 1.25 | Abandon de PodSecurityPolicy | Oui |
| Images de nœud basées sur Docker | Version de GKE 1.20 | Version de GKE 1.24 | Abandon des images de nœuds Docker | Oui |
| Champ Nom courant X.509 dans les certificats webhook | Version de GKE 1.19 | Version de GKE 1.23 | Abandon du champ CN des certificats de webhook | Oui |
Abandons d'API Kubernetes
Le tableau suivant présente les API Kubernetes obsolètes qui ne sont plus diffusées, triées par version de Kubernetes :
| Version de Kubernetes | En savoir plus | GKE détecte-t-il et signale-t-il l'utilisation ? |
|---|---|---|
| 1,29 | API obsolètes de Kubernetes 1.29 | Oui |
| 1.27 | API obsolètes de Kubernetes 1.27 | Oui |
| 1.26 | API obsolètes de Kubernetes 1.26 | Oui |
| 1.25 | API obsolètes de Kubernetes 1.25 | Oui |
| 1.22 | API obsolètes de Kubernetes 1.22, API bêta d'entrée Kubernetes supprimées dans GKE 1.23 |
Oui |
Autres abandons de fonctionnalités
Le tableau suivant fournit des informations sur les abandons et les suppressions causés par d'autres fournisseurs en amont qui ne font pas partie du projet Open Source Kubernetes.
| Nom | Obsolète | Supprimé | En savoir plus | GKE détecte-t-il et signale-t-il l'utilisation ? |
|---|---|---|---|---|
| Images de nœud du canal semi-annuel (SAC) Windows Server | Non disponible | 9 août 2022 | Fin de la maintenance du canal semi-annuel Windows Server | Non |