API obsolètes de Kubernetes 1.25

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 un policy/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 ou events.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 et Warning.
    involvedObject Renommé en regarding.
    action, reason, reportingController et reportingInstance 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ôt eventTime.
    lastTimestamp Renommé en deprecatedLastTimestamp et désormais non autorisé dans les nouveaux événements. Utilisez plutôt series.lastObservedTime.
    count Renommé en deprecatedCount et désormais non autorisé dans les nouveaux événements. Utilisez plutôt series.count.
    source.component Renommé en deprecatedSource.component et désormais non autorisé dans les nouveaux événements. Utilisez plutôt reportingController.
    source.host Renommé en deprecatedSource.host et désormais non autorisé dans les nouveaux événements. Utilisez plutôt reportingInstance.

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 :

  1. Contactez votre fournisseur de logiciels tiers pour obtenir une version mise à jour.
  2. 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 :

  1. Vérifiez dans les journaux quels sont les user-agents qui utilisent les API obsolètes.
  2. Mettez à jour les user-agents qui utilisent les API obsolètes pour utiliser les versions d'API compatibles.
  3. Mettez à jour tout logiciel tiers qui appelle les API obsolètes vers les dernières versions.
  4. 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.
  5. 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.
  6. 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 :