API obsolètes de Kubernetes 1.29

Cette page explique comment préparer des clusters pour les mises à niveau vers la version 1.29 de GKE. Vous pouvez trouver les clients API effectuant des appels vers des API obsolètes supprimées dans la version 1.29 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.29

Les API obsolètes dans la version 1.29 de Kubernetes sont des API bêta qui sont passées en disponibilité générale (par exemple, v2) ou d'une version bêta à une autre (par exemple, de v1beta1 à v1beta2). 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.

Vous pouvez interagir avec tous les objets existants pour les API passées à de nouvelles versions à l'aide des API mises à jour.

Ressources de contrôle de flux

La version d'API flowcontrol.apiserver.k8s.io/v1beta2 de FlowSchema et PriorityLevelConfiguration n'est plus diffusée à partir de la version 1.29.

Migrez les fichiers manifestes et les clients API pour qu'ils utilisent la version d'API flowcontrol.apiserver.k8s.io/v1 disponible depuis la version 1.29, ou la version d'API flowcontrol.apiserver.k8s.io/v1beta3 disponible depuis la version 1.26.

Tous les objets persistants existants sont accessibles à l'aide de la nouvelle API.

La version de l'API flowcontrol.apiserver.k8s.io/v1 présente les modifications notables suivantes :

  • Le champ PriorityLevelConfiguration spec.limited.assuredConcurrencyShares est renommé spec.limited.nominalConcurrencyShares et n'est défini par défaut que sur 30 lorsqu'il n'est pas spécifié. Une valeur explicite de 0 n'est pas remplacée par 30.

La version de l'API flowcontrol.apiserver.k8s.io/v1beta3 présente les modifications notables suivantes :

  • Le champ PriorityLevelConfiguration spec.limited.assuredConcurrencyShares est renommé spec.limited.nominalConcurrencyShares.

Préparer la mise à niveau vers la version 1.29

Vous n'avez pas besoin de supprimer et de recréer les objets de votre 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 fichiers manifestes avant de passer à Kubernetes 1.29. 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.29. 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 obsolètes 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 :