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

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), Windows Server 20H2 (SAC) ou Windows Server 2022 (LTSC). 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 :

  • 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.
    • 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. Nous vous recommandons d'utiliser LTSC en raison de son cycle de vie de compatibilité plus long.
    • Ne sélectionnez pas SAC si vous enregistrez votre cluster GKE dans le canal de publication stable. Comme les versions SAC ne sont acceptées par Microsoft que pendant 18 mois, il existe un risque que l'image du pool de nœuds SAC ne soit plus acceptée alors que la version stable de GKE est encore disponible.
  • Complexité et compatibilité des versions :
    • Ne choisissez SAC que 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.
    • 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.
    • 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.
  • Nouvelles fonctionnalités :
    • 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.
    • Optez pour SAC si vous dépendez de fonctionnalités qui ne sont pas encore disponibles dans la version LTSC.

  • Environnement d'exécution du conteneur :

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

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
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

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. Si vous ne spécifiez pas de version disponible, GKE enregistre votre cluster dans la version disponible la plus mature lorsque cette version est disponible.
  • 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 le canal de publication regular, sauf si au moins l'une des options suivantes est spécifiée : --cluster-version, --release-channel, --no-enable-autoupgrade ou --no-enable-autorepair. Vous devez spécifier None si vous choisissez une version de cluster et ne souhaitez pas que votre cluster soit enregistré dans une version disponible.

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

  • IMAGE_NAME : vous pouvez spécifier l'une des valeurs suivantes :

    • WINDOWS_LTSC_CONTAINERD : option 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.
    • WINDOWS_SAC_CONTAINERD : SAC Windows Server avec containerd (non compatible après le 9 août 2022)
    • WINDOWS_LTSC : Option LTSC Windows Server avec Docker
    • WINDOWS_SAC : SAC Windows Server avec Docker (non compatible après le 9 août 2022)

    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.

  • WINDOWS_OS_VERSION : définit la version du système d'exploitation Windows à utiliser pour le type d'image WINDOWS_LTSC_CONTAINERD. Cette option est facultative. Si cette option n'est pas spécifiée, la version du système d'exploitation par défaut utilisée est LTSC2019. Définissez la valeur sur ltsc2022 pour créer un pool de nœuds Windows Server 2022. Définissez la valeur sur ltsc2019 pour créer un pool de nœuds Windows Server 2019.

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 \
    --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 \
    --windows-os-version=ltsc2022

Console

  1. Accédez à la page Google Kubernetes Engine dans Google 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 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.
    • WINDOWS_SAC_CONTAINERD : SAC Windows Server avec containerd (non compatible après le 9 août 2022)
    • WINDOWS_LTSC : Option LTSC Windows Server avec Docker
    • WINDOWS_SAC : SAC Windows Server avec Docker (non compatible après le 9 août 2022)

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

Mapper les versions de GKE et Windows

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

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

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 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 la console Google Cloud, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Google 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 :

La règle de trafic externe local sur le pool de nœuds Windows n'est compatible qu'avec GKE version v1.23.4-gke.400 ou ultérieure.

Les autres produits Google Cloud que vous souhaitez utiliser avec les clusters GKE peuvent être incompatibles avec les pools de nœuds Windows Server. Pour connaître les limites spécifiques, consultez la documentation de ce produit.

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

Famille d'images en fin de vie

Lorsque vous créez un pool de nœuds avec une image Windows, vous recevez une erreur semblable à celle-ci :

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer versions are still available.

Pour résoudre cette erreur, choisissez une image Windows disponible et compatible. 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.

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 la MTU de l'interface réseau dans le conteneur et les interfaces réseau du nœud Windows Server lui-même sont définies sur la même valeur (c'est-à-dire 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.

Services inaccessibles de façon intermittente dans les nœuds Windows avec des clusters exécutant la version 1.24 ou une version antérieure

Lorsque vous démarrez des nœuds Windows dans des clusters Kubernetes avec un grand nombre de règles d'équilibreur de charge de service réseau hôte, il y a un délai dans le traitement des règles. Les services sont inaccessibles par intermittence pendant le délai (environ 30 secondes par règle), qui peut être important si les règles sont suffisament nombreuses. Pour en savoir plus, consultez le problème original dans GitHub.

Pour les clusters GKE exécutant la version 1.24 ou une version antérieure, avec tous les nœuds Windows dont l'événement a redémarré kube-proxy (par exemple, le démarrage d'un nœud, la mise à niveau d'un nœud ou le redémarrage manuel), tous les services accessibles par un pod exécuté sur ce nœud seront inaccessibles jusqu'à ce que toutes les règles soient synchronisées par le composant.

Pour les clusters GKE exécutant la version 1.25 ou ultérieure, ce comportement est considérablement amélioré. Pour en savoir plus sur cette amélioration, consultez la demande d'extraction dans GitHub. Si vous rencontrez ce problème, nous vous recommandons de mettre à niveau le plan de contrôle de votre cluster vers la version 1.25 ou ultérieure.

Étapes suivantes