Migrer votre cluster AKS

La version précédente des clusters associés à GKE est appelée "clusters associés à GKE (génération précédente)". La migration depuis la version antérieure des clusters associés à GKE vers la génération actuelle vous donne accès à cette fonctionnalité, y compris à la gestion du cycle de vie et à l'enregistrement du parc. La migration est une opération à sens unique : une fois que vous avez migré vers la génération actuelle des clusters associés à GKE, il n'est plus possible de revenir aux clusters associés à GKE (génération précédente).

Règle de numérotation de version

Dans ces documents, la version des clusters associés à GKE est nommée la "version de la plate-forme" pour la distinguer de la version de Kubernetes. Les clusters associés à GKE utilisent la même convention de numérotation de version que GKE (par exemple, 1.21.5-gke.1). Lorsque vous associez ou mettez à jour votre cluster, vous devez choisir une version de plate-forme dont la version mineure est identique ou inférieure d'un niveau à la version Kubernetes de votre cluster. Par exemple, vous pouvez associer un cluster exécutant Kubernetes v1.22.* à la version de plate-forme v1.21.* ou v1.22.* des clusters associés à GKE.

Cela vous permet de passer à la version mineure suivante avant de mettre à niveau les clusters associés à GKE.

Vérifier que Workload Identity est activé

Workload Identity doit être activé sur les clusters existants des clusters associés à GKE (génération précédente) avant leur migration vers la génération actuelle des clusters associés à GKE.

Pour déterminer si WI est activé, exécutez la commande suivante et vérifiez le résultat de n'importe quel champ Workload Identity :

gcloud container hub memberships describe MEMBERSHIP_NAME

Si Workload Identity n'est pas activé, l'appartenance doit être mise à jour pour l'activer.

La commande permettant de mettre à jour l'appartenance de votre cluster varie légèrement selon que vous avez configuré votre cluster avec l'émetteur OIDC privé par défaut ou l'émetteur public expérimental. Choisissez l'onglet qui s'applique à votre cluster :

Émetteur OIDC privé (par défaut)

gcloud container hub memberships register MEMBERSHIP_NAME \
--context=KUBECONFIG_CONTEXT \
--kubeconfig=KUBECONFIG_PATH \
--enable-workload-identity \
--has-private-issuer

Remplacez :

  • MEMBERSHIP_NAME : nom d'appartenance de votre cluster
  • KUBECONFIG_CONTEXT : contexte dans le fichier kubeconfig pour accéder au cluster AKS
  • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig

Émetteur OIDC public

  • Récupérez l'URL d'émetteur OIDC de votre cluster à l'aide de la commande suivante :
  az aks show -n CLUSTER_NAME \
    -g RESOURCE_GROUP \
    --query "oidcIssuerProfile.issuerUrl" -otsv

Cette commande génère l'URL de votre émetteur OIDC. Enregistrez cette valeur pour une utilisation ultérieure.

  • Mettez à jour l'appartenance :
gcloud container fleet memberships register MEMBERSHIP_NAME \
--context=KUBECONFIG_CONTEXT \
--kubeconfig=KUBECONFIG_PATH \
--enable-workload-identity \
--public-issuer-url=OIDC_URL

Remplacez :

  • MEMBERSHIP_NAME : nom d'appartenance de votre cluster
  • KUBECONFIG_CONTEXT : contexte dans le fichier kubeconfig pour accéder au cluster AKS
  • KUBECONFIG_PATH : chemin d'accès à votre fichier kubeconfig
  • OIDC_URL : URL OIDC récupérée précédemment

Migrer votre cluster

Pour migrer votre cluster des clusters associés à GKE (génération précédente) vers les clusters associés à GKE :

  1. Extrayez le contexte kubeconfig de votre cluster et stockez-le dans la variable d'environnement KUBECONFIG_CONTEXT :

    KUBECONFIG_CONTEXT=$(kubectl config current-context)
    
  2. Exécutez la commande suivante pour migrer votre cluster vers la génération actuelle des clusters associés à GKE. Cette commande extrait les informations pertinentes de la configuration de votre cluster, enregistre votre cluster auprès du service de gestion des parcs de Google, et installe ou met à niveau les logiciels nécessaires, tels que l'agent de cycle de vie, sur votre cluster.

    gcloud container attached clusters import \
      --location=GOOGLE_CLOUD_REGION \
      --fleet-membership=FLEET_MEMBERSHIP \
      --platform-version=PLATFORM_VERSION \
      --distribution=CLUSTER_DISTRIBUTION \
      --context=KUBECONFIG_CONTEXT \
      [--kubeconfig=KUBECONFIG_PATH]
    

    Remplacez :

    • GOOGLE_CLOUD_REGION : emplacement Google Cloud à partir duquel votre cluster est administré.
    • FLEET_MEMBERSHIP : indicateur d'appartenance complet de votre cluster enregistré (voir ci-dessous).
    • PLATFORM_VERSION : version des clusters associés à GKE que vous souhaitez migrer (par exemple, v1.22.0-gke.1).
    • CLUSTER_DISTRIBUTION : type de cluster (eks pour AWS Elastic Kubernetes Service, aks pour Azure Kubernetes Service ou generic pour toute autre distribution).
    • KUBECONFIG_CONTEXT : nom du contexte dans votre fichier kubeconfig avec lequel se connecter au cluster.
    • KUBECONFIG_PATH : emplacement de votre fichier kubeconfig. Si aucune valeur n'est spécifiée, la valeur par défaut est ~/.kube/config.

    L'indicateur d'appartenance est une chaîne qui identifie de manière unique votre cluster associé et se présente sous la forme projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP_ID, où

    • PROJECT_NUMBER est le numéro de votre projet hôte de parc. Vous devez spécifier le même numéro de projet que celui auquel votre cluster appartient actuellement.

    • MEMBERSHIP_ID : doit correspondre à l'ID d'appartenance au parc de votre cluster existant. Les clusters associés à GKE utiliseront cette valeur comme nom du cluster.

Compatibilité de Workload Identity avec Azure

Azure propose la compatibilité avec WI en version Preview publique. L'activation de cette fonctionnalité modifie l'URL de l'émetteur OIDC de votre cluster. Si vous avez déjà enregistré votre cluster avec une URL OIDC, vous ne pouvez pas effectuer la mise à jour vers la nouvelle URL, car ce champ ne peut pas être mis à jour pour le moment.

Pour remédier à ce problème, procédez comme suit :

  1. Recréez votre cluster avec Workload Identity activé.
  2. Associer votre cluster AKS
  3. Migrez vos charges de travail vers le nouveau cluster.
  4. Supprimez l'ancien cluster.