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. Mettre à jour et configurer gcloud
  2. Choisir votre image de nœud Windows Server
  3. Créer un cluster et des pools de nœuds
  4. Obtenir les identifiants kubectl
  5. Attendre l'initialisation du cluster

Mettre à jour et configurer gcloud

Avant de commencer, effectuez les tâches suivantes :

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

  • Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
  • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

  1. Exécutez gcloud init et suivez les instructions :

    gcloud init

    Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

    gcloud init --console-only
  2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
  3. Créez ou sélectionnez une configuration.
  4. Choisissez un projet Google Cloud.
  5. Choisissez une zone Compute Engine par défaut pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Utiliser gcloud config

  • Définissez votre ID de projet par défaut :
    gcloud config set project PROJECT_ID
  • Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
    gcloud config set compute/zone COMPUTE_ZONE
  • Si vous utilisez des clusters Autopilot ou régionaux, définissez votre région de calcul par défaut :
    gcloud config set compute/region COMPUTE_REGION
  • Mettez à jour gcloud vers la dernière version :
    gcloud components update

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 sous Windows Server 2019 (LTSC) ou Windows Server 1909 (SAC). 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.

Pour choisir un type d'image, tenez compte des éléments suivants :

  • La durée de compatibilité d'une image de nœud Windows Server est soumise à la durée de compatibilité fournie par Microsoft, comme indiqué dans la section Cycle de vie et stratégie de compatibilité avec les systèmes d'exploitation. Nous vous recommandons d'utiliser LTSC en raison de son cycle de vie de compatibilité plus long. Optez pour SAC si vous dépendez de fonctionnalités qui ne sont pas encore disponibles dans la version LTSC.

  • Microsoft n'assure la compatibilité des versions SAC que pour une durée de 18 mois à compter de la publication initiale. Si vous choisissez SAC comme type d'image sans mettre à jour votre pool de nœuds vers des versions plus récentes de GKE qui acceptent les dernières versions SAC, vous ne pourrez pas créer de nœuds dans votre pool lorsque la période de compatibilité des versions SAC prendra fin. En savoir plus sur la compatibilité de Google avec le système d'exploitation Windows Server.

  • Choisissez SAC seulement si vous êtes en mesure de mettre à niveau votre pool de nœuds et les conteneurs qui y sont exécutés de façon régulière. GKE met régulièrement à jour la version de SAC utilisée pour les pools de nœuds Windows dans les nouvelles versions de GKE. Par conséquent, choisir SAC pour votre type d'image de pool de nœuds vous demande de recréer vos conteneurs plus souvent.

  • En règle générale, les nouvelles fonctionnalités Windows Server sont d'abord introduites dans les versions SAC. Par conséquent, les nouvelles fonctionnalités GKE pour Windows peuvent être d'abord introduites dans les pools de nœuds SAC.

  • Ne sélectionnez pas SAC si vous enregistrez votre cluster GKE dans le canal de publication stable. Comme les versions SAC ne sont prises en charge par Microsoft que pendant 18 mois, il existe un risque que l'image du pool de nœuds SAC ne soit plus prise en charge alors que la version stable de GKE est encore disponible.

Si vous ne savez pas quel type d'image Windows Server utiliser, nous vous recommandons de choisir Windows Server LTSC afin d'éviter les problèmes d'incompatibilité de version lors de la mise à niveau de votre pool de nœuds. Pour en savoir plus, consultez l'article Windows Server servicing channels: LTSC and SAC (Canaux de maintenance Windows Server : LTSC et SAC) dans la documentation de Microsoft.

Pour les images de nœud LTSC et SAC de Windows Server, l'environnement d'exécution du conteneur peut être Docker ou containerd. Pour les versions de nœud GKE 1.21.1-gke.2200 et ultérieures, nous vous recommandons d'utiliser l'environnement d'exécution containerd. Pour en savoir plus, consultez la page Images de nœuds.

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.

Les conteneurs Windows Server ont des exigences importantes en termes de compatibilité des versions :

  • Les conteneurs Windows Server créés pour une version LTSC ne s'exécutent pas sur les nœuds SAC, et inversement.
  • Les conteneurs Windows Server créés pour une version LTSC ou SAC spécifique ne peuvent pas être exécutés sur d'autres versions LTSC ou SAC sans avoir été recréés pour cibler spécifiquement ces nouvelles versions.

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.

Mappage des versions

Microsoft publie de nouvelles versions SAC environ tous les six mois, et 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 et SAC demeurent fixes.

Pour afficher le mappage des versions entre les versions de GKE et de Windows Server, vous pouvez utiliser l'outil de ligne de commande gcloud ou vous référer à la table de mappage des versions dans ce document.

Utiliser l'outil gcloud pour obtenir le mappage des versions

Pour afficher le mappage des versions entre les versions de GKE et de Windows Server Core pour toutes les versions de GKE disponibles, exécutez la commande suivante :

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
    ZONE=COMPUTE_ZONE
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • NODE_POOL_NAME : nom du pool de nœuds Windows Server
    • COMPUTE_ZONE : zone de calcul du cluster
  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 --zone $ZONE --format="value(version)"`
    
  3. Obtenez les versions de Windows Server pour NODE_POOL_VERSION :

    gcloud beta container get-server-config \
        --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_SAC :

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

    Le résultat ressemble à ce qui suit :

    10.0.18363.1198
    

Table de mappage des versions

Le tableau suivant indique la correspondance des versions de GKE avec les versions de Windows Server Core :

1.16

Version de GKE Version SAC Version LTSC
1.16.8-gke.8 à 1.16.13-gke.401 10.0.18363.720 (Windows Server version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.13-gke.402 à 1.16.13-gke.404 10.0.18363.1082 (Windows Server version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.16.15-gke.500 10.0.18363.720 (Windows Server version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.15-gke.1600 à 1.16.15-gke.3500 10.0.18363.1082 (Windows Server version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.16.15-gke.4300 à 1.16.15-gke.7400 10.0.18363.1016 (Windows Server version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.16.15-gke.7800 - 1.16.15-gke.11800 (excludes 1.16.15-gke.7801) 10.0.18363.1198 (Windows Server version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.16.15-gke.7801+ (exclut 1.16.15-gke.10600 et 1.16.15-gke.11800) 10.0.18363.1379 (Windows Server version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.17

Version de GKE Version SAC Version LTSC
1.17.9-gke.1504 à 1.17.12-gke.500 10.0.18363.900 (Windows Server version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.12-gke.1501 10.0.18363.1082 (Windows Server version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.17.12-gke.1504 à 1.17.13-gke.600 10.0.18363.900 (Windows Server version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.13-gke.1400 à 1.17.14-gke.1600 10.0.18363.1016 (Windows Server version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.17.15-gke.300 - 1.17.17-gke.1500 (exclut 1.17.17-gke.1101) 10.0.18363.1198 (Windows Server version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.17.17-gke.1101+ (exclut 1.17.17-gke.1500) 10.0.18363.1379 (Windows Server version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.18

Version de GKE Version SAC Version LTSC
1.18.6-gke.3503 à 1.18.9-gke.801 10.0.18363.900 (Windows Server version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.9-gke.1501 10.0.18363.1082 (Windows Server version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.18.9-gke.2501 à 1.18.10-gke.601 10.0.18363.900 (Windows Server version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.10-gke.1500 à 1.18.12-gke.1700 (exclut 1.18.12-gke.1201) 10.0.18363.1016 (Windows Server version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.18.12-gke.1201 10.0.18363.1198 (Windows Server version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.18.14-gke.1200 - 1.18.15-gke.1500 (exclut 1.18.15-gke.1102) 10.0.18363.1198 (Windows Server version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.18.15-gke.1102+ (exclut 1.18.1.15-gke.1500) 10.0.18363.1379 (Windows Server version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.19

Version de GKE Version SAC Version LTSC
1.19.6-gke.600 - 1.19.7-gke.1500 10.0.18363.658 (Windows Server version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.19.8-gke.1600+ 10.0.19042.804 (Windows Server version 20H2 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.20

Version de GKE Version SAC Version LTSC
1.20.2-gke.1500 10.0.18363.658 (Windows Server version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)
1.20.4-gke.500+ 10.0.19042.804 (Windows Server version 20H2 Core) 10.0.17763.1757 (Windows Server 2019 Core)

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.

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 \
    --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.
  • --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. Il doit s'agir de la version 1.16.8-gke.9 ou d'une version ultérieure. Vous pouvez également choisir d'utiliser l'option --release-channel pour sélectionner un canal de publication.
  • CHANNEL : canal de publication dans lequel le cluster doit être enregistré, à savoir rapid, regular stable ou None. Par défaut, le cluster est enregistré dans la version disponible regular si les options suivantes ne sont pas spécifiées : --cluster-version, --release-channel, --no-enable-autoupgrade et --no-enable-autorepair.

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 \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME

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.
  • IMAGE_NAME : vous pouvez spécifier l'une des valeurs suivantes :

    • WINDOWS_LTSC_CONTAINERD : option LTSC Windows Server avec containerd
    • WINDOWS_SAC_CONTAINERD : option SAC Windows Server avec containerd
    • WINDOWS_LTSC : option LTSC Windows Server avec Docker
    • WINDOWS_SAC: Option SAC Windows Server avec Docker

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

  • --no-enable-autoupgrade désactive la mise à niveau automatique des nœuds. Avant d'activer cette fonction, consultez la section Mettre à niveau les pools de nœuds Windows Server.

  • 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.

Console

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

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Paramètres de base du cluster, procédez comme suit :

    1. Saisissez le nom de votre cluster.
    2. Dans le champ Type d'emplacement, sélectionnez la région ou la zone souhaitée pour votre cluster.
    3. Sous Version du plan de contrôle, sélectionnez une version disponible ou choisissez de spécifier une version statique. Vous devez disposer de la version statique 1.16.8-gke.9 ou ultérieure.
  4. 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).

  5. En haut de la page, cliquez sur Ajouter un pool de nœuds pour créer votre pool de nœuds Windows Server.

  6. 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. Pour les nœuds de version statique, choisissez la Version du nœud.
    3. Saisissez le nombre de nœuds à créer dans le pool de nœuds.
  7. 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'une des images de nœud suivantes :

      • Canal de maintenance à long terme de Windows avec Docker
      • Canal de maintenance à long terme de Windows avec containerd
      • Canal semi-annuel de Windows avec Docker
      • Canal semi-annuel 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.

  8. Dans le volet de navigation, sélectionnez le nom de votre pool de nœuds Windows Server. La page Détails du pool de nœuds s'affiche.

    1. Sous Automatisation, décochez la case Activer la mise à niveau automatique des nœuds. Consultez la section Mettre à niveau les pools de nœuds Windows Server avant d'activer la mise à niveau automatique.
  9. 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).
  10. Cliquez sur Créer.

Terraform

Vous pouvez utiliser le fournisseur Terraform pour Google afin de créer un cluster GKE avec un pool de nœuds Windows Server.

Ajoutez le bloc suivant à votre configuration Terraform :

resource "google_container_cluster" "cluster" {
  project  = "PROJECT_ID"
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  min_master_version = "VERSION_NUMBER"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name       = "linux-pool"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name       = "NODE_POOL_NAME"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type   = "IMAGE_NAME"
    machine_type = "MACHINE_TYPE_NAME"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

Remplacez l'élément suivant :

  • PROJECT_ID : ID du projet dans lequel le cluster est créé.
  • CLUSTER_NAME : nom du cluster GKE.
  • LOCATION : emplacement (région ou zone) dans lequel le cluster est créé.
  • VERSION_NUMBER : doit être 1.16.8-gke.9 ou une version ultérieure.
  • NODE_POOL_NAME : nom que vous avez choisi pour votre pool de nœuds Windows Server.
  • IMAGE_NAME : vous pouvez spécifier l'une des valeurs suivantes :

    • WINDOWS_LTSC_CONTAINERD : option SAC Windows Server avec containerd
    • WINDOWS_SAC_CONTAINERD : option LTSC Windows Server avec containerd
    • WINDOWS_LTSC : option LTSC Windows Server avec Docker
    • WINDOWS_SAC: Option SAC Windows Server avec Docker

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

  • 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.

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 (maître) 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

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.

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.

Pour garantir la compatibilité continue de vos images de conteneur avec vos nœuds, nous vous recommandons de vérifier la table de mappage des versions et de créer des images de conteneur Windows Server de type multi-arch pouvant accepter 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. Il est important d'effectuer 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.

Nous vous recommandons de vous abonner aux notifications de mise à niveau à l'aide de Pub/Sub afin de recevoir de manière proactive des mises à jour sur les nouvelles versions de GKE et les versions du système d'exploitation Windows qu'elles utilisent.

Nous vous recommandons d'activer 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, en particulier si vous choisissez Windows Server SAC comme type d'image de nœud. Si la mise à niveau automatique des nœuds est moins 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.

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 la page Configurer des nœuds Windows Server afin qu'ils rejoignent automatiquement un domaine AD.

  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 Google Cloud Console.

gcloud

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

Console

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

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

    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

Certaines fonctionnalités de Kubernetes ne sont pas encore compatibles avec les conteneurs Windows Server. D'autres sont spécifiques à Linux et ne fonctionnent pas sous Windows. Pour obtenir la liste complète des fonctionnalités Kubernetes compatibles et non compatibles, consultez la documentation de Kubernetes.

En plus des fonctionnalités Kubernetes non compatibles, certaines fonctionnalités de GKE ne sont pas compatibles.

Pour les clusters GKE, les fonctionnalités suivantes ne sont pas compatibles avec les pools de nœuds Windows Server :

Pour les pools de nœuds Windows Server, la fonctionnalité suivante n'est pas compatible :

  • GPU (--accelerator)

Dépannage

Consultez la documentation de Kubernetes pour obtenir des instructions générales sur le débogage des pods et des services.

Problèmes de nœud containerd

Pour les problèmes connus liés à une image de nœud Containerd, consultez la section Problèmes connus.

Les pods Windows ne démarrent pas

Une erreur de correspondance entre les versions du conteneur Windows Server et du nœud Windows qui tente d'exécuter le conteneur peut entraîner l'échec du démarrage de vos pods Windows.

Si la version de votre pool de nœuds Windows est 1.16.8-gke.8 ou ultérieure, consultez la documentation de Microsoft sur les problèmes d'incompatibilité des conteneurs Windows Server (février 2020), puis créez vos images de conteneur avec des images Windows de base intégrant les mises à jour Windows publiées à partir de mars 2020. Les images de conteneurs créées à partir d'images Windows de base antérieures peuvent ne pas s'exécuter sur les nœuds Windows et entraîner une défaillance du nœud avec l'état NotReady.

Erreurs d'extraction d'image

Les images de conteneur Windows Server et les couches dont elles sont composées peuvent être assez volumineuses. Leur taille peut entraîner le dépassement du délai avant expiration de Kubelet lors du téléchargement et de l'extraction des couches du conteneur.

Vous avez peut-être rencontré ce problème si les messages d'erreur "Failed to pull image" (Échec d'extraction de l'image) ou "Image pull context cancelled" (Contexte d'extraction de l'image annulé) s'affichent pour vos pods ou indiquent un état ErrImagePull.

Si vous extrayez régulièrement des images, vous devez utiliser des pools de nœuds ayant une spécification de processeur plus élevée. L'extraction de conteneurs est exécutée en parallèle sur plusieurs cœurs. Par conséquent, les types de machines comportant davantage de cœurs réduisent le temps d'extraction global.

Essayez d'extraire vos conteneurs Windows Server à l'aide des options suivantes :

  • Divisez les couches d'application de l'image du conteneur Windows Server en plusieurs couches plus petites, qui pourront être extraites plus rapidement. Cela peut améliorer l'efficacité de la mise en cache des couches de Docker et augmenter les chances de réussite de vos tentatives d'extraction d'images. Pour en savoir plus sur les couches, consultez l'article Docker À propos des images, des conteneurs et des pilotes de stockage.

  • Connectez-vous à vos nœuds Windows Server et utilisez manuellement la commande docker pull sur vos images de conteneur avant de créer vos pods.

  • Définissez l'option image-pull-progress-deadline pour le service kubelet afin d'augmenter le délai avant expiration de l'extraction des images de conteneur.

    Vous pouvez définir cette option en vous connectant à vos nœuds Windows et en exécutant les commandes PowerShell suivantes.

    1. Obtenez la ligne de commande existante pour le service Kubelet à partir du registre Windows.

      PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
      
      PS C:\> $name = "ImagePath"
      
      PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
      "(?s)${name}.*(C:.*kubelet\.exe.*)"
      
      PS C:\> $kubelet_cmd = $Matches[1] -replace `
      "--image-pull-progress-deadline=.* ","" -replace "\r\n"," "
      
    2. Paramétrez une nouvelle ligne de commande pour le service Kubelet, avec une option supplémentaire pour augmenter le délai avant expiration.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
      --image-pull-progress-deadline=40m "
      
    3. Vérifiez que la modification a bien été effectuée.

      PS C:\> reg query ${regkey} /v ${name}
      
    4. Redémarrez le service kubelet pour que la nouvelle option soit prise en compte.

      PS C:\> Restart-Service kubelet
      
    5. Vérifiez que le service kubelet a bien redémarré.

      PS C:\> Get-Service kubelet # ensure state is Running
      

Expiration du délai d'inactivité lors de la création du pool de nœuds

Le délai de création d'un pool de nœuds peut expirer si vous créez un grand nombre de nœuds (par exemple, 500) et qu'il s'agit du premier pool de nœuds du cluster utilisant une image Windows Server.

Pour résoudre ce problème, réduisez le nombre de nœuds que vous créez. Vous pourrez l'augmenter ultérieurement.

Les nœuds Windows passent à l'état NotReady et renvoient l'erreur "PLEG is not healthy" (PLEG n'est pas opérationnel)

Il s'agit d'un problème Kubernetes connu qui survient lorsque plusieurs pods démarrent très rapidement sur un seul nœud Windows. Pour résoudre ce problème, redémarrez le nœud Windows Server. Une solution recommandée pour éviter ce problème consiste à limiter la fréquence de création des pods Windows à un pod toutes les 30 secondes.

Délai de grâce pour la résiliation incohérent

Le délai avant expiration du système Windows pour le conteneur peut être différent de celui que vous avez configuré. Cette différence peut obliger Windows à forcer l'arrêt du conteneur avant la fin du délai de grâce transmis à l'environnement d'exécution.

Vous pouvez modifier le délai avant expiration du système Windows en modifiant les clés de registre locales du conteneur au moment de la création de l'image. Si vous modifiez le délai avant expiration du système Windows, vous devrez peut-être également ajuster la valeur du paramètre TerminationGracePeriodSeconds pour qu'ils correspondent.

Problèmes de connectivité réseau

Si vous rencontrez des problèmes de connexion réseau à partir de vos conteneurs Windows Server, c'est peut-être parce que la mise en réseau de conteneurs Windows Server suppose souvent une MTU réseau de 1500, qui est incompatible avec la MTU de 1460de Google Cloud.

Vérifiez que les MTU de l'interface réseau dans le conteneur et des interfaces réseau du nœud Windows Server lui-même sont toutes de 1460 ou moins. Pour plus d'informations sur le paramétrage de la MTU, consultez la section Problèmes connus pour les conteneurs Windows.

Problèmes de démarrage des nœuds

Si les nœuds ne parviennent pas à démarrer dans le cluster ou ne parviennent pas à se joindre au cluster, consultez les informations de diagnostic fournies dans la sortie du port série du nœud.

Exécutez la commande suivante pour afficher la sortie du port série :

gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE

Remplacez l'élément suivant :

  • NODE_NAME : nom du nœud.
  • COMPUTE_ZONE : zone de calcul du nœud spécifique.

Étape suivante