Cette page explique comment préparer des clusters pour les mises à niveau vers la version 1.25 de GKE. Vous pouvez trouver les clients API effectuant des appels vers des API obsolètes supprimées dans la version 1.25 et les mettre à jour pour qu'ils utilisent les API en disponibilité générale. Pour en savoir plus, consultez le guide de migration des API obsolètes de Kubernetes.
API supprimées dans la version 1.25
La plupart des API obsolètes dans la version 1.25 de Kubernetes sont d'anciennes API bêta qui sont passées depuis de la version bêta (par exemple, v1beta1
) à la version DG (par exemple, v1
). Les API en disponibilité générale offrent des garanties de compatibilité à long terme et doivent être utilisées à la place des API bêta obsolètes.
Tous les objets existants des API passées en DG restent accessibles dans les API en disponibilité générale.
EndpointSlice
La version d'API bêta (discovery.k8s.io/v1beta1
) de EndpointSlice
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.21.
- Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version
discovery.k8s.io/v1
de l'API. Reportez-vous au tableau suivant qui décrit les modifications notables apportées à la version de l'API en disponibilité générale :
Champ Modifier endpoints[*].topology["kubernetes.io/hostname"]
Utilisez endpoints[*].nodeName
.endpoints[*].topology["topology.kubernetes.io/zone"]
Utilisez endpoints[*].zone
.endpoints[*].topology
Remplacé par endpoints[*].deprecatedTopology
, qui n'est pas accessible en écriture dans la version v1.
PodDisruptionBudget
La version d'API bêta (policy/v1beta1
) de PodDisruptionBudget
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.21.
- Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version
policy/v1
de l'API. Reportez-vous au tableau suivant qui décrit les modifications notables apportées à la version de l'API en disponibilité générale :
Champ Modifier spec.selector
Une valeur vide ( {}
) écrite dans unpolicy/v1 PodDisruptionBudget
sélectionne tous les pods de l'espace de noms. Une valeur non définie permet toujours de ne sélectionner aucun pod.
CronJob
La version d'API bêta (batch/v1beta1
) de CronJob
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.21. Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version batch/v1
de l'API.
PodSecurityPolicy
La version d'API bêta (policy/v1beta1
) de PodSecurityPolicy
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.21.
Pour en savoir plus, consultez la page Abandon de PodSecurityPolicy.
RuntimeClass
La version d'API bêta (node.k8s.io/v1beta1
) de RuntimeClass
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.20. Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version node.k8s.io/v1
de l'API.
Événements
La version d'API bêta (events.k8s.io/v1beta1
) de Events
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.19.
- Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version
v1
ouevents.k8s.io/v1
de l'API. Reportez-vous au tableau suivant qui décrit les modifications notables apportées à la version de l'API en disponibilité générale :
Champ Modifier type
Limité à Normal
etWarning
.involvedObject
Renommé en regarding
.action
,reason
,reportingController
etreportingInstance
Ces champs sont désormais obligatoires lors de la création d'événements. firstTimestamp
Renommé en deprecatedFirstTimestamp
et désormais non autorisé dans les nouveaux événements. Utilisez plutôteventTime
.lastTimestamp
Renommé en deprecatedLastTimestamp
et désormais non autorisé dans les nouveaux événements. Utilisez plutôtseries.lastObservedTime
.count
Renommé en deprecatedCount
et désormais non autorisé dans les nouveaux événements. Utilisez plutôtseries.count
.source.component
Renommé en deprecatedSource.component
et désormais non autorisé dans les nouveaux événements. Utilisez plutôtreportingController
.source.host
Renommé en deprecatedSource.host
et désormais non autorisé dans les nouveaux événements. Utilisez plutôtreportingInstance
.
HorizontalPodAutoscaler
La version d'API bêta (autoscaling/v2beta1
) de HorizontalPodAutoscaler
n'est plus diffusée à partir de la version 1.25. Cette API a été rendue obsolète dans la version 1.23.
Effectuez une migration des fichiers manifestes et des clients API de sorte qu'ils utilisent la version autoscaling/v2 HorizontalPodAutoscaler
de l'API.
Préparer la mise à niveau vers la version 1.25
Vous n'avez pas besoin de supprimer, ni de recréer les objets API. Tous les objets API persistants existants pour les API migrées vers la version DG peuvent déjà être lus et mis à jour à l'aide des nouvelles versions d'API.
Toutefois, nous vous recommandons de migrer vos clients et vos fichiers manifestes avant de passer à Kubernetes 1.25. Pour en savoir plus, consultez le Guide de migration des API obsolètes de Kubernetes.
Vous pouvez afficher les insights et les recommandations d'obsolescence pour déterminer si votre cluster utilise des API obsolètes de Kubernetes 1.25. GKE génère des insights d'obsolescence lorsque les user-agents appellent des API obsolètes, et non à partir de la configuration de vos objets Kubernetes.
Rechercher les clusters utilisant des API obsolètes
Vous pouvez identifier les clusters qui utilisent des API obsolètes à partir des insights d'obsolescence. Les insights d'obsolescence fournissent également des informations telles que l'identification des clients API qui appellent les API obsolètes dans votre cluster.
Vous pouvez également utiliser les journaux d'audit pour identifier les clients qui appellent des API obsolètes.
Localiser les clients API effectuant des appels en écriture auprès d'API obsolètes
Pour les clusters sur lesquels l'observabilité Google Cloud est activée, vous pouvez utiliser la requête suivante sur les journaux d'audit des activités d'administration pour afficher les cas d'utilisation d'API obsolètes par des user-agents non gérés par Google :
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="DEPRECATED_API_MINOR_VERSION"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
Remplacez DEPRECATED_API_MINOR_VERSION
par la version mineure dans laquelle l'API obsolète a été supprimée, par exemple 1.22
.
Les journaux d'audit pour les activités d'administration sont automatiquement activés pour les clusters GKE. Avec cette requête, les journaux affichent les user-agents effectuant des appels en écriture vers les API obsolètes.
Localiser les clients API effectuant des appels en lecture auprès d'API obsolètes
Par défaut, les journaux d'audit n'affichent que les appels en écriture auprès d'API obsolètes. Pour afficher également les appels en lecture auprès d'API obsolètes, configurez les journaux d'audit pour l'accès aux données.
Suivez les instructions pour configurer les journaux d'audit pour l'accès aux données avec la console Google Cloud. Dans la console Google Cloud, sélectionnez l'API Kubernetes Engine. Dans l'onglet "Types de journaux" du panneau d'informations, sélectionnez Admin Read
et Data Read
.
Lorsque ces journaux sont activés, vous pouvez utiliser la requête d'origine pour afficher à la fois les appels en lecture et les appels en écriture auprès d'API obsolètes.
Mettre à niveau des composants tiers
Les insights d'obsolescence peuvent afficher les résultats des agents tiers qui appellent des API obsolètes dans votre cluster.
Pour résoudre les problèmes liés aux agents tiers qui appellent des API obsolètes, nous vous recommandons de respecter les bonnes pratiques suivantes :
- Contactez votre fournisseur de logiciels tiers pour obtenir une version mise à jour.
- Mettez à niveau le logiciel tiers vers la dernière version. Si vous ne pouvez pas mettre à niveau le logiciel, vous devez vérifier si la mise à niveau de GKE vers la version avec les API supprimées entraîne l'interruption du service.
Nous vous recommandons de mettre à niveau cette version et la version de GKE sur un cluster de préproduction pour surveiller les interruptions avant de mettre à niveau vos clusters de production.
Mettre à jour les clusters affectés par les obsolescences
Pour mettre à niveau les clusters concernés par ces abandons, procédez comme suit :
- Vérifiez dans les journaux quels sont les user-agents qui utilisent les API obsolètes.
- Mettez à jour les user-agents qui utilisent les API obsolètes pour utiliser les versions d'API compatibles.
- Mettez à jour tout logiciel tiers qui appelle les API obsolètes vers les dernières versions.
- Mettez à niveau un cluster de test et testez votre application dans un environnement de test avant de mettre à niveau votre cluster de production afin de réduire le risque d'interruption lorsque les API obsolètes ne sont plus disponibles.
- Si vous ne pouvez pas mettre à jour un user-agent concerné, mettez à niveau un cluster de test distinct pour vérifier si la mise à niveau entraîne des perturbations. Si la mise à niveau n'entraîne pas de perturbations, vous pouvez mettre à niveau votre cluster manuellement.
- Après avoir mis à jour tous les user-agents, GKE attend qu'il n'ait plus observé d'utilisation d'API obsolètes pendant 30 jours, puis débloque les mises à niveau automatiques. Les mises à niveau automatiques se déroulent selon le calendrier des lancements.
Ressources
Pour plus d'informations, consultez la documentation Open Source de Kubernetes :
- Blog sur Kubernetes : processus de suppressions dans Kubernetes et changements majeurs dans la version 1.25
- Notes de version de Kubernetes 1.25
- Guide de migration des API obsolètes de Kubernetes