Créer un cluster à l'aide de pools de nœuds Windows Server

Dans cette page, vous allez apprendre à créer un cluster Google Kubernetes Engine (GKE) avec des pools de nœuds s'exécutant sous Microsoft Windows Server. Avec ce cluster, vous pouvez utiliser des conteneurs Windows Server. En revanche, les conteneurs Microsoft Hyper-V ne sont actuellement pas compatibles. À l'instar des conteneurs Linux, les conteneurs Windows Server assurent l'isolation du processus et de l'espace de noms.

Un nœud Windows Server nécessite plus de ressources qu'un nœud Linux classique pour exécuter le système d'exploitation Windows et les composants Windows Server ne pouvant pas s'exécuter dans des conteneurs. Étant donné que les nœuds Windows Server nécessitent plus de ressources, les ressources pouvant être allouées sont inférieures à celles des nœuds Linux.

Créer un cluster à l'aide de pools de nœuds Windows Server

Dans cette section, vous allez créer un cluster qui utilise un conteneur Windows Server.

Pour créer ce cluster, vous devez effectuer les tâches suivantes :

  1. Choisir votre image de nœud Windows Server
  2. Mettre à jour et configurer gcloud
  3. Créer un cluster et des pools de nœuds
  4. Obtenir des identifiants kubectl
  5. Attendre l'initialisation du cluster

Configurer des comptes de service IAM pour GKE

GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Au minimum, ces comptes de service de nœud doivent disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, en tant que compte de service de nœud.

Pour attribuer le rôle roles/container.defaultNodeServiceAccount au compte de service Compute Engine par défaut, procédez comme suit :

Console

  1. Accédez à la page d'accueil :

    Accéder à la page d'accueil

  2. Dans le champ Numéro du projet, cliquez sur Copier dans le presse-papiers.
  3. Accédez à la page IAM :

    Accéder à la page "IAM"

  4. Cliquez sur  Accorder l'accès.
  5. Dans le champ Nouveaux comptes principaux, spécifiez la valeur suivante : 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
    Remplacez PROJECT_NUMBER par le numéro de projet que vous avez copié.
  6. Dans le menu Sélectionner un rôle, choisissez le rôle Compte de service de nœud par défaut Kubernetes Engine.
  7. Cliquez sur Enregistrer.

gcloud

  1. Recherchez le numéro de votre projet Google Cloud : 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Remplacez PROJECT_ID par l'ID du projet.

    Le résultat ressemble à ce qui suit :

    12345678901
  2. Attribuez le rôle roles/container.defaultNodeServiceAccount au compte de service Compute Engine par défaut : 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Remplacez PROJECT_NUMBER par le numéro de projet de l'étape précédente.

Choisir votre image de nœud Windows Server

Pour s'exécuter sur GKE, les images de nœud de conteneur Windows Server doivent être créées sur la version recommandée de Windows Server 2022 (LTSC) ou sur Windows Server 2019 (LTSC), qui est obsolète dans GKE et ne peut pas être utilisée pour les pools de nœuds exécutant GKE version 1.37 ou ultérieure. Un cluster peut comporter plusieurs pools de nœuds Windows Server utilisant différentes versions de Windows Server. En revanche, chaque pool de nœuds ne peut utiliser qu'une seule version de Windows Server.

Prenez en compte les éléments suivants lorsque vous choisissez votre image de nœud :

  • Mises à jour : utilisez LTSC2022, car LTSC2019 est obsolète dans GKE. Voici ce que vous devez savoir sur LTSC2019 :
    • Aucune mise à jour des images de nœud : GKE ne fournit pas de mises à jour des images de nœud pour LTSC2019 en raison de problèmes de stabilité liés aux mises à jour de l'image sous-jacente depuis que Microsoft a mis fin au support Mainstream pour l'image. Les images de nœuds GKE sont épinglées à la version de décembre 2025 de l'image sous-jacente. Pour en savoir plus, consultez Windows Server 2019.
    • Compatibilité avec la version 1.37 : vous ne pouvez pas utiliser LTSC2019 avec la version 1.37 de GKE ni les versions ultérieures. Vous ne pouvez pas créer de pools de nœuds avec LTSC2019 et la version 1.37, ni mettre à niveau les pools de nœuds LTSC2019 existants vers la version 1.37.
  • Durée de compatibilité :
    • La durée de compatibilité d'une image de nœud Windows Server est soumise à la durée de compatibilité fournie par Microsoft, comme décrit dans la section Règles de compatibilité des images d'OS. Pour connaître la date de fin de compatibilité des images de nœuds Windows GKE, utilisez la commande gcloud container get-server-config décrite dans la section Mapper les versions GKE et Windows.
  • Complexité et compatibilité des versions :
    • Les systèmes Windows Server Core et Nano Server peuvent tous deux être utilisés comme image de base pour vos conteneurs.
    • La création d'images de conteneurs Windows Server de type multi-arch pouvant accepter plusieurs versions de Windows Server peut vous aider à gérer la complexité inhérente à la gestion des versions.

Mettre à jour et configurer gcloud

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Créer un cluster et des pools de nœuds

Pour exécuter des conteneurs Windows Server, votre cluster doit comporter au moins un pool de nœuds Windows et un pool de nœuds Linux. Vous ne pouvez pas créer de cluster avec seulement un pool de nœuds Windows Server. Le pool de nœuds Linux est obligatoire pour exécuter des modules complémentaires de cluster essentiels.

Avant de créer un cluster à l'aide de pools de nœuds Windows Server, consultez la section Mettre à niveau les pools de nœuds Windows Server.

En raison de son importance, nous vous recommandons d'activer l'autoscaling pour vous assurer que votre pool de nœuds Linux dispose d'une capacité suffisante pour exécuter des modules complémentaires de cluster.

gcloud

Créez un cluster en définissant les champs suivants :

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

Remplacez l'élément suivant :

  • CLUSTER_NAME correspond au nom que vous avez choisi pour votre cluster.
  • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.
  • --enable-ip-alias active les adresses IP d'alias. L'adresse IP d'alias est obligatoire pour les nœuds Windows Server. Pour en savoir plus sur ses avantages, consultez la page Understanding native container routing with Alias IPs (Comprendre le routage natif de conteneurs avec des adresses IP d'alias).
  • NUMBER_OF_NODES : nombre de nœuds Linux que vous créez. Vous devez fournir suffisamment de ressources de calcul pour exécuter les modules complémentaires du cluster. Ce champ est facultatif. Si vous l'omettez, la valeur par défaut est utilisée (3).
  • VERSION_NUMBER : version du cluster spécifique que vous souhaitez utiliser. Si vous ne spécifiez pas de version disponible, GKE enregistre votre cluster dans le version disponible le plus mature lorsque cette version est disponible.
  • CHANNEL : canal de publication dans lequel le cluster doit être enregistré, à savoir rapid, regular, stable ou None (obsolète). Par défaut, le cluster est enregistré dans la version disponible regular.

Nous vous recommandons vivement de spécifier un compte de service IAM associé à des privilèges minimaux que vos nœuds pourront utiliser à la place du compte de service Compute Engine par défaut. Pour savoir comment créer un compte de service doté de privilèges minimaux, consultez Utiliser un compte de service moindre privilège minimaux.

Pour spécifier un compte de service personnalisé dans la gcloud CLI, ajoutez l'indicateur suivant à votre commande :

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Remplacez SERVICE_ACCOUNT_NAME par le nom de votre compte de service à accès minimal.

Créez le pool de nœuds Windows Server en définissant les champs ci-dessous :

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

Remplacez l'élément suivant :

  • NODE_POOL_NAME : nom que vous avez choisi pour votre pool de nœuds Windows Server.
  • CLUSTER_NAME : nom du cluster que vous avez créé précédemment.
  • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.
  • MACHINE_TYPE_NAME : définit le type de machine. n1-standard-2 correspond au type de machine minimal recommandé, étant donné que les nœuds Windows Server nécessitent des ressources supplémentaires. Les types de machines f1-micro et g1-small ne sont pas compatibles. Chaque type de machine est facturé différemment. Pour en savoir plus, consultez la grille tarifaire par type de machine.
  • WINDOWS_OS_VERSION : option facultative qui définit la version de l'OS Windows à utiliser pour le type d'image WINDOWS_LTSC_CONTAINERD. Pour GKE version 1.37 et ultérieure, vous ne pouvez utiliser que LTSC2022 (ltsc2022). Pour la version 1.36 ou antérieure, nous vous recommandons de définir explicitement la valeur sur ltsc2022. Sinon, GKE utilise LTSC2019 (ltsc2019), ce qui n'est pas recommandé, car GKE l'a abandonné.

L'exemple suivant montre comment créer un pool de nœuds Windows Server 2022 :

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

L'exemple suivant montre comment mettre à jour un pool de nœuds Windows existant pour utiliser l'image du système d'exploitation Windows Server 2022 :

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --windows-os-version=ltsc2022

Console

  1. Dans la console Google Cloud , accédez à la page Créer un cluster Kubernetes.

    Accéder à la page "Créer un cluster Kubernetes"

  2. Dans la section Paramètres de base du cluster, procédez comme suit :
    1. Saisissez le nom de votre cluster.
    2. Pour le type d'emplacement, sélectionnez une région ou une zone pour votre cluster.
    3. Sous Versions disponibles, sélectionnez une version disponible et, éventuellement, une version cible.
  3. Dans le volet de navigation, sous pools de nœuds, cliquez sur default-pool pour créer votre pool de nœuds Linux. Lors de la configuration de ce pool de nœuds, veillez à fournir suffisamment de ressources de calcul pour exécuter les modules complémentaires du cluster. Vous devez également disposer d'un quota de ressources disponible pour les nœuds et les ressources associées (telles que les routes de pare-feu).
  4. En haut de la page, cliquez sur Ajouter un pool de nœuds pour créer votre pool de nœuds Windows Server.
  5. Dans la section Détails du pool de nœuds, procédez comme suit :
    1. Saisissez un nom pour le pool de nœuds.
    2. Saisissez le nombre de nœuds à créer dans le pool de nœuds.

  6. Dans le volet de navigation, cliquez sur Nœuds sous Pools de nœuds.

    1. Dans la liste déroulante Type d'image, sélectionnez l'image de nœud suivante :

      • Canal de maintenance à long terme de Windows avec containerd

      Pour en savoir plus, consultez la section Choisir votre image de nœud Windows.

    2. Sélectionnez la configuration de la machine à utiliser par défaut pour les instances. n1-standard-2 correspond à la taille minimale recommandée, étant donné que les nœuds Windows Server nécessitent des ressources supplémentaires. Les types de machines f1-micro et g1-small ne sont pas compatibles. Chaque type de machine est facturé différemment. Pour en savoir plus, consultez la grille tarifaire par type de machine.

  7. Dans le volet de navigation, sélectionnez Réseau sous Cluster.

    1. Sous Options de mise en réseau avancées, assurez-vous que l'option Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias) est sélectionnée. L'adresse IP d'alias est obligatoire pour les nœuds Windows Server. Pour en savoir plus sur ses avantages, consultez la page Understanding native container routing with Alias IPs (Comprendre le routage natif de conteneurs avec des adresses IP d'alias).

  8. Cliquez sur Créer.

Terraform

Pour créer un cluster GKE Standard et un pool de nœuds Windows Server à l'aide de Terraform, reportez-vous à l'exemple suivant :

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

Cet exemple utilise le mode LTSC Windows Server avec containerd. Il s'agit du type d'image pour l'image de l'OS Windows Server 2022 et Windows Server 2019 (obsolète dans GKE). Pour en savoir plus sur les images de nœud, consultez Choisir votre image de nœud Windows.

Pour en savoir plus sur l'utilisation de Terraform, consultez la page Compatibilité de Terraform avec GKE.

Une fois que vous avez créé un pool de nœuds Windows Server, le cluster passe à l'état RECONCILE pendant plusieurs minutes, le temps que le plan de contrôle soit mis à jour.

Obtenir les identifiants kubectl

Utilisez la commande get-credentials pour activer kubectl afin de pouvoir l'utiliser avec le cluster que vous venez de créer.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

Pour en savoir plus sur la commande get-credentials, consultez la documentation get-credentials du SDK.

Attendre l'initialisation du cluster

Avant d'utiliser le cluster, attendez quelques secondes jusqu'à ce que windows.config.common-webhooks.networking.gke.io soit créé. Ce webhook ajoute des tolérances de planification aux pods créés avec le sélecteur de nœud kubernetes.io/os: windows afin de les autoriser à s'exécuter sur des nœuds Windows Server. Il vérifie également que le pod n'utilise que des fonctionnalités compatibles avec Windows.

Pour vous assurer que le webhook a été créé, exécutez la commande suivante :

kubectl get mutatingwebhookconfigurations

Le résultat devrait afficher le webhook en cours d'exécution :

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

Maintenant que vous disposez d'un cluster avec deux pools de nœuds (un Linux et un Windows), vous pouvez déployer une application Windows.

Mapper les versions de GKE et Windows

Microsoft publie de nouvelles versions LTSC tous les deux à trois ans. En règle générale, ces nouvelles versions sont intégrées aux nouvelles versions mineures de GKE. Dans une version mineure de GKE, les versions LTSC demeurent fixes.

Pour afficher le mappage de version entre les versions de GKE et Windows Server, utilisez la commande gcloud beta container get-server-config :

gcloud beta container get-server-config

Le mappage des versions est renvoyé dans le champ windowsVersionMaps de la réponse. Pour filtrer la réponse et afficher le mappage des versions pour des versions GKE spécifiques de votre cluster, procédez comme suit dans une interface système Linux ou dans Cloud Shell.

  1. Définissez ces variables :

    CLUSTER_NAME=CLUSTER_NAME \
NODE_POOL_NAME=NODE_POOL_NAME \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • NODE_POOL_NAME : nom du pool de nœuds Windows Server
    • CONTROL_PLANE_LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

  2. Obtenez la version du pool de nœuds et stockez-la dans la variable NODE_POOL_VERSION :

    NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster=$CLUSTER_NAME \
--location=$CONTROL_PLANE_LOCATION \
--format="value(version)"`

  3. Obtenez les versions de Windows Server pour NODE_POOL_VERSION :

    gcloud beta container get-server-config \
    --location=$CONTROL_PLANE_LOCATION \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

    Le résultat ressemble à ce qui suit :

    windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

  4. Obtenez la version de Windows Server pour le type d'image WINDOWS_LTSC :

    gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_LTSC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

    Le résultat ressemble à ce qui suit :

    10.0.17763.1577

Mettre à niveau les pools de nœuds Windows Server

Les exigences de compatibilité de versions des conteneurs Windows Server impliquent que vous devrez peut-être recréer vos images de conteneurs de sorte qu'elles correspondent à la version de Windows Server compatible avec une nouvelle version de GKE avant de mettre à niveau vos pools de nœuds. Consultez les recommandations suivantes concernant la mise à niveau de ce type de pool de nœuds :

  • Si nécessaire, empêchez les mises à niveau automatiques des nœuds à l'aide des exclusions de maintenance.
  • Pour vous assurer que vos images de conteneur restent compatibles avec vos nœuds, vérifiez le mappage des versions et créez vos images de conteneur Windows Server en tant qu'images multi-architecture pouvant cibler plusieurs versions de Windows Server. Vous pourrez ensuite mettre à jour vos déploiements de conteneurs de sorte qu'ils acceptent des images de type multi-arch fonctionnant à la fois sur la version actuelle de GKE et sur la version suivante, avant d'appeler manuellement une mise à niveau du pool de nœuds GKE.
  • Si vous empêchez les mises à niveau automatiques des nœuds, effectuez régulièrement des mises à niveau manuelles du pool de nœuds, car la version des nœuds ne peut pas être antérieure de plus de deux versions mineures à la version du plan de contrôle.
  • Pour recevoir de manière proactive des notifications sur les nouvelles versions de GKE et les versions du système d'exploitation Windows qu'elles utilisent, abonnez-vous aux notifications de mise à niveau.
  • Laissez GKE effectuer la mise à niveau automatique des nœuds uniquement si vous créez en continu des images de conteneurs Windows Server de type multi-arch qui ciblent les dernières versions de Windows Server. Si la mise à niveau automatique des nœuds est peu susceptible de poser des problèmes avec le type d'image de nœud LTSC de Windows Server, il existe toujours un risque d'incompatibilité de version.

Mises à jour Windows

Les mises à jour Windows sont désactivées pour les nœuds Windows Server. En effet, les mises à jour automatiques peuvent entraîner un redémarrage intempestif des nœuds. Or, toutes les mises à jour Windows installées après le démarrage d'un nœud sont perdues lorsque le nœud est recréé par GKE. Pour que vous puissiez bénéficier des mises à jour Windows, les images de nœuds Windows Server utilisées dans les nouvelles versions de GKE sont régulièrement mises à jour. Il peut s'écouler un certain temps entre la publication des mises à jour Windows par Microsoft et leur disponibilité dans GKE. Lorsque des mises à jour de sécurité critiques sont publiées, GKE met à jour les images de nœud Windows Server aussi rapidement que possible.

Contrôler la communication des pods et services Windows

Vous pouvez contrôler la manière dont les pods et les services Windows communiquent à l'aide de règles de réseau.

Vous pouvez disposer d'un conteneur Windows Server sur des clusters dont la règle de réseau est activée dans GKE 1.22.2 et versions ultérieures. Cette fonctionnalité est disponible pour les clusters qui utilisent les types d'images de nœuds WINDOWS_LTSC ou WINDOWS_LTSC_CONTAINERD.

Si vos plans de contrôle ou vos nœuds exécutent des versions antérieures, vous pouvez migrer vos pools de nœuds vers une version compatible avec la règle de réseau en mettant à niveau vos pools de nœuds et votre plan de contrôle vers GKE 1.22.2 ou une version ultérieure. Cette option n'est disponible que si vous avez créé votre cluster avec l'option --enable-dataplane-v2.

Une fois que vous avez activé les règles de réseau, toutes les règles précédemment configurées, y compris celles qui ne fonctionnaient pas sur les conteneurs Windows Server avant l'activation de cette fonctionnalité, deviennent actives.

Certains clusters ne peuvent pas être utilisés avec des conteneurs Windows Server sur des clusters avec la règle de réseau activée. Pour en savoir plus, consultez la section Limites.

Afficher et interroger les journaux

La journalisation est activée automatiquement dans les clusters GKE. Vous pouvez afficher les journaux des conteneurs et d'autres services sur les nœuds Windows Server à l'aide de la fonctionnalité de surveillance de Kubernetes Engine.

Voici un exemple de filtre permettant d'obtenir le journal d'un conteneur :

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

Accéder à un nœud Windows Server à l'aide du protocole RDP (Remote Desktop Protocol)

Vous pouvez vous connecter à un nœud Windows Server de votre cluster à l'aide du protocole RDP. Pour savoir comment vous connecter, consultez la section Se connecter à des instances Windows dans la documentation Compute Engine.

Créer des images multi-arch

Vous pouvez créer les images multi-arch manuellement ou utiliser un compilateur Cloud Build. Pour obtenir des instructions, consultez la section Créer des images multi-arch Windows.

Utiliser gMSA

La procédure suivante vous montre comment utiliser un compte de service géré de groupe (gMSA, Group Managed Service Account) avec vos pools de nœuds Windows Server.

  1. Configurez les nœuds Windows Server de votre cluster de sorte qu'ils rejoignent automatiquement votre domaine AD. Pour savoir comment procéder, consultez Configurer des nœuds Windows Server afin qu'ils rejoignent automatiquement un domaine Active Directory.

  2. Créez et accordez un accès gMSA au groupe de sécurité créé automatiquement par le service de jointure de domaine. Cette étape doit être effectuée sur une machine disposant d'un accès administrateur à votre domaine AD.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName

    Remplacez l'élément suivant :

    • NODE_POOL_NAME : nom de votre pool de nœuds Windows Server. Le groupe de sécurité créé automatiquement porte le même nom que votre pool de nœuds Windows Server.
    • CLUSTER_NAME : nom du cluster
    • GMSA_NAME : nom que vous avez choisi pour le nouveau gMSA.
    • DNS_HOST_NAME : nom de domaine complet (FQDN, Fully Qualified Domain Name) du compte de service que vous avez créé. Par exemple, si GMSA_NAME est défini sur webapp01 et que le domaine est example.com, DNS_HOST_NAME est défini sur webapp01.example.com.

  3. Configurez votre gMSA en suivant les instructions du tutoriel Configurer un compte de service GMSA pour les pods et les conteneurs Windows.

Supprimer des pools de nœuds Windows Server

Vous pouvez supprimer un pool de nœuds Windows Server à l'aide de l'outil gcloud ou de la console Google Cloud .

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION

Console

Pour supprimer un pool de nœuds Windows Server à l'aide de la console Google Cloud , procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud .

    Accéder à Google Kubernetes Engine

  2. À côté du cluster que vous souhaitez modifier, cliquez sur Actions, puis sur Modifier.

  3. Sélectionnez l'onglet Nœuds.

  4. Dans la section Pools de nœuds, cliquez sur Supprimer à côté du pool de nœuds que vous souhaitez supprimer.

  5. Lorsque vous êtes invité à confirmer votre choix, cliquez à nouveau sur Supprimer.

Limites

Les fonctionnalités suivantes ne sont pas compatibles avec les pools de nœuds Windows Server :

Pour connaître les limites spécifiques des autres produits Google Cloud que vous pouvez utiliser avec les clusters GKE, consultez la documentation correspondante.

Dépannage

Pour obtenir des conseils de dépannage spécifiques aux pools de nœuds Windows Server, consultez Résoudre les problèmes liés aux pools de nœuds Windows Server.

Pour obtenir des instructions générales, consultez la documentation Kubernetes sur le débogage des pods et des services.

Étapes suivantes