Guide de l'utilisateur pour les pools de nœuds du système d'exploitation Windows Server

Avec Google Distributed Cloud, vous pouvez créer un pool de nœuds pour les nœuds du système d'exploitation Windows Server. Le cluster d'utilisateur qui exécute les pools de nœuds du système d'exploitation Windows Server peut également exécuter des pools de nœuds contenant des nœuds utilisant Ubuntu ou Container-Optimized OS.

Configuration requise pour un pool de nœuds du système d'exploitation Windows Server

Les nœuds d'un pool doivent tous utiliser le même système d'exploitation, indiqué par le paramètre osImageType.

Avant de créer un pool de nœuds comportant des nœuds du système d'exploitation Windows Server dans votre cluster d'utilisateur, assurez-vous de remplir les conditions suivantes :

Un cluster d'administrateur doit déjà être en place pour que vous puissiez créer un pool de nœuds Windows, car ce type de pool n'est accepté que dans le cluster d'utilisateur.
Le cluster d'utilisateur doit exécuter au moins un pool de nœuds Linux, car celui-ci est requis pour créer un pool de nœuds Windows.
Le champ enabledataplanev2 d'un cluster d'utilisateur avec des pools de nœuds Windows doit être défini sur true dans le fichier de configuration du cluster d'utilisateur. Cela permet d'activer Dataplane V2 sur les nœuds Linux de ce cluster.
Par défaut, Windows Dataplane V2 est activé pour les pools de nœuds Windows pour les nouveaux clusters d'utilisateur.
Vous avez téléchargé un fichier ISO Windows Server 2019 de Microsoft pour créer un modèle de VM spécifique aux pools de nœuds Windows. Le tag de langue/région pour l'ISO doit être en-US.
Votre environnement vSphere doit disposer de la mise à jour 3 de vSphere 6.7 ou d'une version ultérieure.

Créer un pool de nœuds Windows dans un cluster d'utilisateur

Étape 1 : Créer le modèle de VM Windows pour Google Distributed Cloud

Avant de commencer, vérifiez que vous avez déjà créé un cluster d'administrateur.

Créez un modèle de VM Windows de base à partir du fichier ISO Windows Server 2019.
- Pour que la VM Windows puisse installer le fichier ISO Windows Server 2019, le type de carte réseau initial doit être E1000E.
- Suivez la procédure suivante : Créer un modèle VMware vSphere pour Windows Server 2019.
- Notez le mot de passe initial défini lors de l'exécution du programme d'installation du fichier ISO Windows afin de l'utiliser ultérieurement.
- Assurez-vous que vous utilisez la dernière version de correctif qualifiée pour Windows Server 2019. Consultez les notes de version pour connaître la dernière version d'image Windows OS qualifiée pour une version d'Anthos donnée. Consultez la section Processus d'application des correctifs de sécurité.
- Vous ne pouvez pas associer d'appareil utilisant le contrôleur IDE au modèle de VM de base.
Si ce n'est pas déjà fait, installez VMware Tools sur le modèle de VM Windows de base en suivant les instructions VMWare.
Créez un modèle de VM Windows :
```
gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- BASE_WINDOWS_VM_TEMPLATE : chemin d'accès au modèle de VM Windows de base
- BUNDLE : chemin d'accès au fichier de bundle Google Distributed Cloud
Lors de la création du modèle de VM Windows de base, gkectl prepare windows exécute Windows sysprep. Cela permet de généraliser le modèle de VM et de nettoyer les paramètres réseau de la VM, ce qui permet d'éviter les conflits d'adresses IP lorsque des VM sont clonées à partir du même modèle. Toutefois, Windows sysprep s'exécute en tant que boîte fermée. Il est donc difficile de gérer certains échecs sysprep.

Si vous souhaitez créer un modèle de VM Windows de base sans exécuter Windows sysprep, incluez --skip-sysprep dans la commande gkectl prepare windows.
Sur la dernière ligne du résultat de la commande, vous pouvez trouver le nom du modèle de VM Windows généré. Notez ce nom pour l'utiliser ultérieurement. Le nom est au format suivant :
```
Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"
```

Étape 2 : Importer les images de conteneurs Windows dans un registre privé

Passez cette étape si vous n'utilisez pas de registre privé.

Vous pouvez automatiser l'importation d'images de conteneurs Windows dans un registre privé à l'aide de containerd sur une station de travail d'administrateur Linux. Cependant, containerd ne peut pas transférer la couche de base de l'image de conteneur Windows, ce qui signifie que les couches de base doivent être extraites du registre Microsoft lors de l'extraction de l'image. Pour transférer les couches de base, suivez les étapes de l'option 2.

Option 1 : Si vous n'avez pas besoin de transférer manuellement les images de la couche de base Windows vers le registre privé :

gkectl prepare --config <var class="edit">ADMIN_CLUSTER_CONFIG</var> --upload-windows-images

Remplacez ADMIN_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration du cluster d'administrateur.

L'option --upload-windows-images indique que les images de conteneur Windows seront transférées. Sans cette option, seules les images de conteneurs Linux seront transférées vers le registre privé.

Option 2 : Si vous devez transférer manuellement les images de la couche de base Windows vers le registre privé :

Utilisez une machine Windows sur laquelle Docker est installé et disposant d'un accès à gcr.io avant d'effectuer cette procédure. Vous pouvez extraire des images de conteneur Windows vers une machine Windows.
Exécutez docker login pour vous authentifier auprès de votre registre privé.
Importez les images de conteneurs Windows et leurs couches de base dans votre registre privé en procédant comme suit :
- Accédez au fichier Docker daemon.json sur votre machine Windows :
```
PS C:> cat C:\ProgramData\docker\config\daemon.json
```
- Ajoutez les lignes suivantes pour configurer votre fichier Docker daemon.json de sorte qu'il autorise le transfert de couches étrangères vers votre registre privé :
```
{
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
```
- Téléchargez les images de conteneurs Windows requises sur votre machine Windows locale, puis marquez-les et transférez-les dans votre registre privé. Les modifications apportées au fichier de configuration Docker daemon.json permettent de transférer la couche de base vers le registre privé. Pour effectuer ces tâches, exécutez les commandes suivantes :

# Pull the Windows container images
docker pull gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Tag the images to use private registry
docker tag gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019 $PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker tag gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019 $PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker tag gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019 $PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

Étape 3 : (Obligatoire si vous utilisez un proxy) Ajouter des URL à la liste d'autorisation pour créer des pools de nœuds Windows

Si votre cluster est situé derrière un serveur proxy, ajoutez ces URL à la liste d'autorisation du serveur proxy en plus des autres adresses requises par Google Distributed Cloud.

# Microsoft registry URLs, needed by every Windows node if using GCR
mcr.microsoft.com
.data.mcr.microsoft.com
go.microsoft.com
winlayers.cdn.mscr.io

# Microsoft WSUS server URLs, needed by `gkectl prepare windows` on the Windows VM
windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.update.microsoft.com
.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com

# Cloudbase-Init URL, needed by `gkectl prepare windows` on the Windows VM
https://cloudbase.it

# Powershell Gallery URLs, needed by `gkectl prepare windows` on the Windows VM
psg-prod-eastus.azureedge.net
az818661.vo.msecnd.net
devopsgallerystorage.blob.core.windows.net
.powershellgallery.com

# Windows Update Service, needed by `gkectl prepare windows` on the Windows VM
onegetcdn.azureedge.net
sws.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
fe3.delivery.mp.microsoft.com
.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
adl.windows.com
activation-v2.sls.microsoft.com
crl.microsoft.com
ocsp.digicert.com
ctldl.windowsupdate.com
login.live.com
licensing.mp.microsoft.com
www.msftconnecttest.com
settings-win.data.microsoft.com
wdcp.microsoft.com
smartscreen-prod.microsoft.com
checkappexec.microsoft.com
arc.msn.com
ris.api.iris.microsoft.com
.tlu.dl.delivery.mp.microsoft.com
.au.windowsupdate.com
www.microsoft.com
fe3.delivery.dsp.mp.microsoft.com.nsatc.net
cs9.wac.phicdn.net
geo-prod.do.dsp.mp.microsoft.com
slscr.update.microsoft.com
v10.events.data.microsoft.com

# Access for Installing docker, needed by `gkectl prepare windows` on the Windows VM
dockermsft.azureedge.net

Étape 4 : Ajouter un pool de nœuds Windows au fichier de configuration du cluster d'utilisateur

Vous devez activer Dataplane V2 dans votre cluster d'utilisateur pour pouvoir utiliser des pools de nœuds Windows. Ajoutez la ligne suivante au fichier de configuration du cluster d'utilisateur pour activer Dataplane V2 :
```
enableDataplaneV2: true
```
Ajoutez un pool de nœuds Windows à la section nodePools du fichier de configuration du cluster d'utilisateur. Vous devez au moins ajouter un pool de nœuds Linux en plus des pools de nœuds Windows. Définissez les champs osImage et osImageType pour créer des pools de nœuds Windows :

osImage : remplacez WINDOWS_VM_TEMPLATE_NAME par le nom du modèle de VM Windows préparé à l'étape 1, qui doit se trouver dans le même datastore vCenter que celui spécifié dans le fichier de configuration du cluster d'utilisateur.
osImageType : définissez le type d'image de l'OS sur windows.

# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 8
  memoryMB: 16384
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

Étape 5 : Créer des pools de nœuds Windows

Pour pouvoir créer des pools de nœuds Windows, exécutez une liste de programmes de validation préliminaires pour Windows. Ignorez cette étape si vous disposez déjà d'un cluster d'utilisateur. (Facultatif) Exécutez l'une ou l'autre des vérifications préliminaires rapides et lentes (ou les deux), qui permettent de créer une VM de test pour Windows et de valider le modèle de VM Windows :

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Cette commande est conçue pour être exécutée avant la création d'un cluster d'utilisateur. Si vous disposez déjà d'un cluster d'utilisateur, certaines vérifications peuvent échouer. Par exemple, les adresses IP du fichier hostconfig.yaml sont peut-être déjà utilisées par des nœuds existants dans votre cluster d'utilisateur.
Bien que cette option ne soit pas recommandée, vous pouvez ignorer les vérifications préliminaires Windows avec l'option --skip-validation-windows.
La gestion des pools de nœuds Windows est identique à celle des pools de nœuds Linux. Consultez la section Gérer des pools de nœuds. Les commandes de création, de mise à jour et de mise à niveau des clusters et des pools de nœuds restent identiques et sont répertoriées ici.

# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Update an existing cluster with the new Windows node pool
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Étape 6 : Valider les nœuds Windows en cours d'exécution

Vérifiez que vos nœuds Windows ont été créés et qu'ils sont à l'état Ready.
```
kubectl --kubeconfig USER_KUBECONFIG get nodes 
```

Analysez le cluster d'utilisateur afin de vérifier qu'il est opérationnel.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG  --cluster-name CLUSTER_NAME

Déployer un pod Windows

Les nœuds Windows Server sont rejetés par la paire clé-valeur suivante : node.kubernetes.io/os=windows:NoSchedule.

Ce rejet garantit que le programmeur GKE ne tente pas d'exécuter des conteneurs Linux sur des nœuds Windows Server. Pour programmer des conteneurs Windows Server sur des nœuds Windows Server, votre fichier manifeste doit inclure la section nodeSelector suivante :

nodeSelector:
    kubernetes.io/os: windows

Si vous configurez nodeSelector, un webhook d'admission s'exécutant dans le cluster vérifie la présence de ce sélecteur de nœuds Windows dans les nouvelles charges de travail et applique la tolérance suivante à la charge de travail, afin qu'elle puisse s'exécuter sur les nœuds Windows Server rejetés :

tolerations:
- key: "node.kubernetes.io/os"
  operator: "Equal"
  value: "windows"
  effect: "NoSchedule"

Étape 1 : Créer un fichier de déploiement Internet Information Services (IIS)

Voici un exemple de configuration qui déploie l'image IIS officielle de Microsoft sur un seul pod.

Créez un fichier IIS nommé iis.yaml avec le contenu suivant :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: iis
  name: iis
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: iis
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: [Fill in with an available IP address]

Étape 2 : Créer le déploiement et l'exposer via un service

# Create the deployment
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG create -f iis.yaml

Étape 3 : Valider le pod

Vérifiez l'état du pod avec kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Attendez que le résultat renvoyé indique que l'état du pod est "Running" (En cours d'exécution).

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

Obtenez l'état du service et attendez que le champ "External IP" (Adresse IP externe) soit renseigné.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Résultat attendu :

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   35.x.x.x     80:32233/TCP   17s

Vous pouvez utiliser votre navigateur pour ouvrir http://EXTERNAL_IP et afficher la page Web IIS.

Mettre à jour le cluster d'utilisateur avec les pools de nœuds Windows

Le processus de mise à jour d'un cluster d'utilisateur avec des pools de nœuds Windows est semblable à celui des clusters d'utilisateur Linux, sauf que vous devez créer un modèle de VM Windows à partir d'un modèle de VM de base avant la mise à jour.

Pour mettre à jour la version de création de correctifs du modèle de VM de base lors de la mise à jour, vous pouvez télécharger une version de correctif plus récente de Windows Server 2019 depuis Microsoft en tant que correctif de sécurité. Consultez la section Processus d'application des correctifs de sécurité.

gkectl prepare windows --base-vm-template $BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Remplacez le champ osImage du pool de nœuds dans le fichier de configuration par le nouveau nom du modèle de VM. Exécutez la commande ci-dessous pour mettre à jour le cluster d'utilisateur :

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès de votre fichier kubeconfig d'administrateur ;
ADMIN_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration du cluster d'administrateur.

Accéder aux nœuds Windows

La méthode standard d'accès aux nœuds Windows consiste à utiliser un nom d'utilisateur et un mot de passe, contrairement aux nœuds Linux, auxquels il est généralement possible d'accéder avec des clés d'authentification SSH.

Pour les nœuds Windows sur vSphere, le nom d'utilisateur est Administrator. Le mot de passe est généré par clusterapi-controller et stocké dans le secret windows-node-password, dans l'espace de noms d'utilisateur du cluster d'administrateur. La commande permettant d'obtenir le mot de passe à partir de ce secret est la suivante :

kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d

Vous pouvez également obtenir le mot de passe à l'aide de l'interface utilisateur de vCenter. Accédez à la VM à laquelle vous souhaitez vous connecter. Vous trouverez ensuite le mot de passe dans la propriété vApp password de cette VM.

Une fois que vous avez le nom d'utilisateur et le mot de passe, vous pouvez accéder à votre VM Windows en utilisant l'une des approches suivantes :

Utiliser le protocole RDP

Comme le protocole RDP a été activé lors de la création du modèle, vous pouvez accéder à votre VM Windows à l'aide d'un client RDP.

Utiliser SSH

Pour vous connecter en SSH à une VM Windows, procédez comme suit :

ssh Administrator@[VM_IP_ADDRESS]

Suivez l'invite pour saisir le mot de passe permettant de vous connecter à votre VM.

Transférer des fichiers depuis et vers votre VM Windows

Vous pouvez transférer des fichiers depuis et vers votre VM Windows à l'aide de la commande scp :

Importez les fichiers dans une VM Windows :

scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]

Téléchargez des fichiers à partir de la VM Windows :

scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]

Saisissez le mot de passe lorsque vous y êtes invité.

Vous pouvez également transférer des fichiers à l'aide de Cloud Storage ou du protocole RDP, comme décrit dans la section Transférer des fichiers vers des VM Windows.

Mettre à jour la configuration de Windows Server

Containerd et Windows Dataplane V2 sont désormais en disponibilité générale à partir de la version 1.11.

Docker et Flannel pour les nœuds Windows sont appelées à devenir obsolètes dans une prochaine version. Nous vous recommandons de mettre à jour votre configuration dès maintenant, le cas échéant, afin d'utiliser containerd et Windows Dataplane V2 à la place. Consultez la section Mettre à jour la configuration de Windows Server.

Impossible de se connecter en SSH/RDP à la VM Windows

Vérifiez si la VM dispose d'une connexion réseau en exécutant Test-NetConnection dans votre console Web vCenter.

Le résultat doit contenir la valeur PingSucceeded: true si une connexion réseau est établie. Si la VM ne dispose pas d'une connexion réseau, vérifiez la carte réseau utilisée pour cette VM. Assurez-vous que le réseau autorise les connexions entrantes vers la VM depuis la station de travail dans laquelle vous souhaitez exécuter le protocole SSH/RDP.

Vérifier que les services kubelet, kube-proxy et CNI s'exécutent sur la VM Windows

Connectez-vous à votre VM en suivant ces étapes, puis exécutez les commandes suivantes en fonction de votre configuration :

Pour toutes les configurations, exécutez les commandes suivantes :

# Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy

Si votre cluster est configuré avec windowsDataplaneV2 défini sur true, vérifiez que les services antrea-agent, ovsdb-server et ovs-vswitchd sont en cours d'exécution ("Running").
```
# Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd
```
Sinon, vérifiez que le processus flanneld est en cours d'exécution ("Running") :
```
# Check that the flanneld process exists
Get-Process flanneld
```

Utiliser l'outil de capture d'instantanés

Utilisez l'outil de capture d'instantanés pour récupérer le fichier tarball de l'instantané. Ce fichier tarball contient les fichiers journaux des nœuds, ainsi que les résultats des commandes de dépannage exécutées sur le nœud.

gkectl diagnose snapshot --scenario system-with-logs --cluster-name [USER_CLUSTER_NAME] --kubeconfig [PATH_TO_KUBECONFIG]

Échec de la création de la VM Windows

Vérifiez les journaux du conteneur vsphere-controller-manager dans le pod clusterapi-controllers de l'espace de noms utilisateur du cluster d'administrateur.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME logs clusterapi-controllers-POD_NAME_SUFFIX vsphere-controller-manager

Vérifiez que votre modèle de VM se trouve dans le même centre de données et le même datastore que ceux spécifiés dans le fichier de configuration de votre cluster d'utilisateur.

La VM Windows est créée, mais le nœud ne démarre pas correctement ou ne s'affiche pas

Consultez les journaux de démarrage du nœud situés à l'adresse C:\var\log\startup.log pour vérifier si une opération a échoué lors du démarrage.
- Si flanneld n'est pas en cours d'exécution, essayez d'exécuter à nouveau le script de démarrage situé à l'adresse C:\etc\startup\startup-script.ps1.
- Si kubelet n'est pas en cours d'exécution, vérifiez les journaux kubelet sous C:\var\log.
- Si kube-proxy n'est pas en cours d'exécution, consultez les journaux kube-proxy sous C:\var\log.
Vérifiez si cloudbase-init a déjà exécuté UserDataPlugin avant d'exécuter le script de démarrage.

Pour vérifier cela, établissez une connexion SSH à la VM Windows et exécutez la commande suivante :

ls "HKLM:\\Software\Cloudbase Solutions\Cloudbase-Init\id-ovf\"

Si vous trouvez UserDataPlugin: 1 dans la sortie, cela signifie que cloudbase-init a déjà exécuté ce plug-in, ce qui entraînera l'omission de l'exécution du script de démarrage et que le nœud Windows ne sera pas du tout amorcé.

Cela est généralement dû à la conversion du modèle de VM généré par gkectl prepare windows en VM et à son allumage.

Pour résoudre ce problème, créez un modèle de VM en exécutant à nouveau gkectl prepare windows et utilisez-le pour créer/mettre à niveau/mettre à jour le pool de nœuds Windows.

Journaux et surveillance

Google Distributed Cloud est compatible avec la journalisation et la surveillance des nœuds et des pods Windows, comme c'est le cas pour les nœuds et les pods Linux.

Lorsque la journalisation et la surveillance sont configurées, les agents sont déployés sur des nœuds Windows. Ces agents collectent, traitent et exportent les journaux et les métriques du nœud.

Agent de journalisation Windows

L'agent de journalisation Windows collecte les journaux suivants :

Type de ressource du pod : charges de travail des applications système et utilisateur

Notez que les journaux des charges de travail des applications utilisateur Windows sont collectés par défaut. Pour désactiver les journaux d'application, procédez comme suit :

Modifiez le fichier ConfigMap fluent-bit-windows-config et mettez en commentaire l'élément [Input] qui collecte les journaux d'application (le premier élément [Input]) :

kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system

Mettez en commentaire tous les champs de cet élément. Exemple :

#    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?a-z0-9?(?:.a-z0-9?))_(?[^]+)(?.+)-(?[a-z0-9]{64}).log$
#      Tag                k8s_container...
#      Path               C:\var\log\containers\.log
#      Exclude_Path       kube-system.log,gke-connect.log,knative-serving.log,gke-system.log,istio-system.log,monitoring-system.log,config-management-system.log,gatekeeper-system.log,cnrm-system.log
#      DB                 C:\var\log\fluent-bit-k8s-container-application.db
#      Mem_Buf_Limit      30MB
#      Skip_Long_Lines    On
#      Refresh_Interval   10
#      # storage.type       filesystem
#      Buffer_Chunk_Size  512KB
#      Buffer_Max_Size    5M
#      Rotate_Wait        30
#      Ignore_Older       4h

Exécutez la commande rollout restart pour redémarrer le daemonset fluent-bit-windows :

kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

Type de ressource du nœud : journaux d'événements kubelet, kube-proxy et Windows

Vous pouvez accéder aux journaux à l'aide de l'explorateur de journaux de la console. Pour en savoir plus, consultez la section Accéder aux journaux.

Agent de surveillance Windows

L'agent de surveillance Windows collecte un ensemble de métriques d'utilisation de la mémoire et du processeur différent de celui de l'agent de surveillance Linux. Pour surveiller l'état des nœuds et des pods Windows, utilisez les tableaux de bord préparés. Dans la console, cliquez sur Surveillance > Tableaux de bord, puis sélectionnez "GKE on-prem Windows node status" (État du nœud Windows GKE On-Prem) et "GKE on-prem Windows pod status" (État du pod Windows GKE On-Prem) dans la liste Tous les tableaux de bord.

Ces tableaux de bord sont automatiquement créés lors de l'installation du cluster d'administrateur si Cloud Monitoring est activé. Si vous disposez déjà d'un cluster d'administrateur en cours d'exécution, suivez ces instructions pour créer ces tableaux de bord à l'aide des fichiers JSON suivants :

Consultez la liste complète des métriques collectées par les agents Windows.

Stockage persistant Windows

Lorsque vous utilisez des conteneurs Windows Server avec un espace de stockage persistant, vous devez créer un objet StorageClass et spécifier son nom dans le champ storageClassName de l'objet PersistentVolumeClaim, car la classe StorageClass par défaut dans le cluster d'utilisateur sur site utilise ext4 comme type de système de fichiers, qui n'est compatible qu'avec les conteneurs Linux. Pour Windows, nous devons définir le type de système de fichiers sur ntfs.

Exemple de classe de stockage Windows :

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-storage-class
provisioner: kubernetes.io/vsphere-volume
parameters:
  datastore: my-datastore
  diskformat: thin
  fstype: ntfs

Le proxy CSI est déployé automatiquement sur les nœuds Windows. Vous pouvez installer et utiliser un pilote CSI Windows de votre choix, tel que le pilote CSI SMB.

Détecteur de problèmes de nœuds sur les nœuds Windows

Le daemon du détecteur de problèmes de nœuds est disponible sur les nœuds Windows. Si vous êtes passé à la version 1.9, le détecteur de problèmes de nœuds est activé automatiquement. Le détecteur de problèmes de nœuds permet de détecter rapidement certains problèmes courants. Le détecteur de problèmes de nœuds vérifie les problèmes éventuels et les signale en tant qu'événements et conditions sur le nœud. Lorsqu'un nœud échoue, vous pouvez utiliser la commande kubectl pour rechercher les événements et les conditions correspondants.

Les configurations de surveillance suivantes sont activées pour le détecteur de problèmes de nœuds :

Pour obtenir des événements et des conditions sur un nœud :

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Remplacez :

KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster contenant le nœud ;
NODE_NAME par le nom du nœud.

Pour identifier les événements générés par les moniteurs du détecteur de problèmes de nœuds, recherchez le nom du moniteur dans le champ reason d'une règle spécifiée dans la section rules.

Les moniteurs du détecteur de problèmes de nœuds génèrent également les conditions suivantes sur le nœud. Chacune de ces configurations est définie sur true si le détecteur de problèmes de nœuds détecte le scénario d'échec correspondant sur le nœud.

KubeletUnhealthy
KubeProxyUnhealthy
ContainerRuntimeUnhealthy

Chaque fois que l'une des conditions est définie sur true, la condition "Ready" du nœud devient false, ce qui empêche la planification de nouveaux pods sur le nœud.

Lorsqu'une condition non opérationnelle est détectée, le détecteur de problèmes de nœuds tente de réparer automatiquement le nœud en redémarrant le service système approprié.

Les journaux du détecteur de problèmes de nœuds se trouvent dans le dossier C:\var\log\node-problem-detector du nœud. Si la journalisation et la surveillance sont activées, le journal est exporté vers Cloud Logging et vous pouvez l'afficher dans l'explorateur de journaux.

Utilisez ce filtre pour obtenir les journaux du détecteur de problèmes de nœuds dans l'explorateur de journaux :

resource.type="k8s_node"
log_name="projects/PROJECT_NAME/logs/node-problem-detector"

Remplacez PROJECT_NAME par le nom du projet.

Processus d'application des correctifs de sécurité

En plus des versions de correctif standards pour les versions d'Anthos acceptées, l'équipe Anthos reçoit continuellement les mises à jour de correctif Windows les plus récentes lors des périodes de non publication et publie les résultats pour référence. Si une mise à jour urgente d'un correctif de sécurité est nécessaire entre les versions de correctif Anthos, vous pouvez créer un modèle de VM à l'aide de la dernière version, puis effectuer une mise à jour progressive pour que les pools de nœuds Windows existants utilisent le nouveau modèle.

Le processus d'application de correctifs de sécurité comprend les étapes suivantes :

Microsoft publie un nouveau correctif de sécurité pour Windows Server 2019.
Anthos reçoit la dernière version du correctif de sécurité et annonce le résultat de l'éligibilité.
En cas d'éligibilité, procédez comme suit :
- Téléchargez la dernière version du correctif de Microsoft.
- Créez un modèle de VM Windows à l'aide de cette version de correctif en suivant ces instructions.
- Mettez à jour les pools de nœuds Windows afin qu'ils utilisent le nouveau modèle en exécutant la commande suivante :

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Si la nouvelle version nécessite des modifications du côté d'Anthos, vous devez attendre la prochaine version mensuelle du correctif Anthos et mettre à jour les clusters.
Si la nouvelle version Windows n'est pas du tout compatible avec Anthos, l'équipe Anthos ignore cette version et attend la prochaine mise à jour de sécurité de Microsoft.

Joindre un domaine Active Directory

L'association de domaine Active Directory requiert que la longueur du nom d'hôte de la VM soit inférieure ou égale à 15 caractères. Étant donné que le nom d'hôte de la VM est défini dans le fichier de configuration du cluster d'utilisateur en mode IPAM, vous devez vous assurer que la longueur est inférieure ou égale à 15 caractères. Ces instructions sont basées sur celles permettant de créer des pools de nœuds Windows, avec une étape supplémentaire permettant de fournir un script personnalisé lors de la création du modèle de VM Windows.

Vérifier que le serveur DNS Active Domain est accessible

Les services de domaine Active Directory (AD DS) utilisent des services de résolution de noms DNS pour permettre aux clients de localiser les contrôleurs de domaine et aux contrôleurs de domaine qui hébergent le service d'annuaire de communiquer entre eux.

Le serveur DNS a été créé lorsque le rôle AD DS a installé la forêt racine. Pour qu'une VM Windows puisse joindre le domaine AD, elle doit pouvoir atteindre le serveur DNS. Définissez les configurations DNS et de pare-feu en suivant les instructions de votre fournisseur de services DNS. Pour vérifier si les VM Windows du réseau actuel peuvent contacter le serveur DNS du domaine AD, exécutez la commande suivante :

PS C:\> nslookup DOMAIN_NAME DOMAIN_SERVER_IP
Server:  example-1-2-3-4.anthos
Address:  1.2.3.4
Name:    example.org
Address:  1.2.3.4

Étape 1 : Créer un modèle de VM Windows avec un script personnalisé

Exécutez un script personnalisé avant de joindre le nœud Windows au cluster d'utilisateur pour l'association de domaine Active Directory. Stockez ce script dans un chemin d'accès local sur votre station de travail administrateur. Remarques :
- Vous pouvez remplacer le script par votre propre script pour joindre le domaine Active Directory.
- Il est recommandé d'utiliser un compte utilisateur avec les autorisations minimales requises pour joindre un domaine Active Directory, plutôt qu'un compte administrateur.
- (Facultatif) Pour éviter de stocker le mot de passe en texte clair dans ce script, placez le mot de passe dans un fichier du modèle de VM, laissez le script lire dans le fichier de ce mot de passe, puis supprimez le fichier après avoir joint le domaine.
```
$domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force
```

Créez un modèle de VM Windows avec un script personnalisé :

gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG --customized-script CUSTOMIZED_SCRIPT_PATH

Remplacez BUNDLE_PATH par le chemin d'accès au groupe.

Étape 2 : Créer un pool de nœuds Windows

Suivez les instructions standards des étapes 2 à 6 pour créer un pool de nœuds Windows à l'aide du modèle de VM Windows personnalisé.

Étape 3 : Vérifier l'association de domaine Active Directory des nœuds Windows

Sur la VM du contrôleur de domaine AD, exécutez la commande suivante :

PS C:\> Get-ADComputer -Filter 'Name -like "user-host-prefix*"'

DistinguishedName : CN=AD-VM-1,CN=Computers,DC=example,DC=org
DNSHostName       : ad-vm-1.example.org
Enabled           : True
Name              : AD-VM-1
ObjectClass       : computer
ObjectGUID        : b3609717-d24b-4df6-bccb-26ca8e8b9eb0
SamAccountName    : AD-VM-1$
SID               : S-1-5-21-3236879623-1561052741-2808297733-1103

Étape 4 : Configurer les comptes de service gérés de groupes (facultatif)

Suivez les instructions suivantes : Configurer un compte de service géré de groupe pour les pods et les conteneurs Windows. Vous pouvez configurer un compte de service géré de groupe pour les pods et les conteneurs Windows une fois les nœuds associés à un domaine.

Dépannage

Les journaux de l'exécution du script personnalisé de cloudbase-init se trouvent à l'emplacement C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Recherchez LocalScriptPlugin dans le fichier journal et vérifiez les journaux associés. - Créez un modèle de VM Windows. - Mettez à jour les pools de nœuds Windows afin qu'ils utilisent le nouveau modèle en exécutant la commande suivante :

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Remarques sur les conteneurs Windows

Voici quelques différences notables entre les conteneurs Windows et Linux :

Compatibilité des versions des images de conteneurs Windows et des images de l'OS hôte/du nœud.
- Le tuple de version du système d'exploitation Windows Server comporte quatre parties : majeur, mineur, build et correctif.
- L'image de base du conteneur Windows Server doit correspondre aux trois premières parties du tuple de version de l'image de l'OS hôte. Le correctif ne doit pas nécessairement être mis en correspondance, bien qu'il soit recommandé de mettre à jour à la fois les images de base de l'hôte et du conteneur.
- Les utilisateurs doivent créer à nouveau leurs images de conteneurs chaque fois que la version de l'image de l'OS change.
Les conteneurs privilégiés et les espaces de noms d'hôtes ne sont pas acceptés.
- Les utilisateurs ne peuvent pas configurer ni modifier les nœuds en déployant des conteneurs, tels que Daemonsets.

Limites de Google Distributed Cloud sur vSphere Windows

Les clusters d'utilisateur doivent contenir au moins un pool de nœuds Linux.
- Vous ne pouvez pas créer de cluster avec un seul pool de nœuds Windows.
- Les pools de nœuds Linux sont nécessaires pour exécuter des modules complémentaires critiques.
Étant donné que 1,5 fois plus de ressources sont réservées aux nœuds Windows qu'aux nœuds Linux, les ressources pouvant être allouées pour Windows sont moins nombreuses.
L'utilisation de nœuds Windows peut nécessiter une taille de machine minimale supérieure à celle des machines Google Distributed Cloud Linux. Les nœuds Windows nécessitent généralement plus de ressources en raison de la surcharge liée à l'exécution des composants/services du nœud.

Problèmes connus

Cette section répertorie les problèmes connus liés aux nœuds Windows utilisés avec Google Distributed Cloud, ainsi que les solutions pour éviter ou résoudre ces problèmes.

Les pods Windows ne peuvent pas communiquer avec les adresses IP externes

Ce problème est décrit dans la documentation Microsoft, qui stipule : "Vous devez exclure l'adresse IP externe que vous essayez d'interroger de ExceptionList".

Contactez l'assistance Google Cloud pour trouver une solution de contournement.

Les conteneurs Windows ne sont pas nettoyés après la suppression des pods Windows

Il s'agit d'un problème connu, dans lequel le fichier Docker RemoveContainer tente également d'appeler CreateFile sous Windows. Pour contourner ce problème, connectez-vous au nœud Windows qui présente le problème, exécutez Restart-Service docker et le problème devrait être résolu. À partir de Google Distributed Cloud 1.9, la version des images de conteneurs "fluent-bit-win" et la version de Docker ont été mises à jour pour détecter les correctifs en amont de ce problème. Cela ne devrait plus se reproduire. Si vous rencontrez ce problème, contactez l'assistance Google Cloud.

Nœuds Windows ayant des conflits d'adresses IP

Il s'agit d'un problème connu qui se produit très rarement. Si vous rencontrez ce problème lors de la création du pool de nœuds Windows, vous pouvez l'atténuer en procédant comme suit :

Si vous utilisez le mode IPAM, vous pouvez supprimer manuellement de vCenter les VM présentant un conflit d'adresses IP. Les nouvelles VM seront créées automatiquement et devraient récupérer des adresses IP correctes. Une autre possibilité consiste simplement à attendre que le processus de réparation automatique de nœud détecte le problème et recrée les nœuds Windows.
Si vous utilisez le mode DHCP, les VM nouvellement créées sont susceptibles d'être encore affectées par des conflits d'adresse IP, car le serveur DHCP rencontre des problèmes d'allocation d'adresses IP. Dans ce cas, vous pouvez supprimer le pool de nœuds Windows en attente en exécutant la commande gkectl update cluster, l'ajouter à nouveau dans user-cluster.yaml, puis exécuter gkectl update cluster afin de recréer le pool de nœuds, qui devrait alors bénéficier d'allocations d'adresses IP correctes.

Le nœud Windows passe à l'état "NotReady" (Non prêt) après le redémarrage de la VM.

Actuellement, le script de démarrage du nœud ne s'exécute que la première fois que la VM est mise sous tension. Par conséquent, si vous redémarrez la VM, le script de démarrage ne s'exécute pas à nouveau. Ainsi, certains services Windows cessent de fonctionner, y compris le service kubelet, les services kube-proxy, etc. Le nœud passe à l'état NotReady. Si vous utilisez Windows Dataplane V2, le réseau obsolète doit également être nettoyé pour que les services Dataplane V2 puissent redémarrer, et cela nécessite l'exécution d'un script pour le nettoyage, ce qui peut causer des difficultés. Par conséquent, recréez le nœud. Pour contourner ce problème, vous pouvez supprimer le nœud en exécutant la commande ci-dessous et en attendant que le contrôleur le recrée automatiquement.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Échec de la commande de diagnostic lorsque les versions de matériel de la VM Windows sont inférieures à la version attendue

Lorsque le modèle de VM Windows utilise une ancienne version de matériel, la commande gkectl diagnose cluster échoue et le message suivant s'affiche :

Checking storage...FAILURE
    Reason: 1 storage error(s).
    Unhealthy Resources:
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue. Use --detailed=true for the list of VMs.
    Debug Information:
    {
      "NODE_NAME": "vmx-XX",
    }

Pour résoudre ce problème, procédez comme suit :

Renommez le modèle de VM actuellement utilisé.

Cette étape est nécessaire pour pouvoir créer un modèle de VM lors des étapes suivantes.
Convertissez le modèle de VM de base Windows en VM.
Suivez la procédure décrite dans Mettre à niveau une machine virtuelle vers la dernière version matérielle pour mettre à niveau la version matérielle de la VM.
Convertissez la VM en modèle de VM.
Exécutez la commande suivante pour préparer un nouveau modèle de VM, en utilisant le modèle de VM mis à niveau des étapes précédentes comme modèle de VM de base.
```
gkectl prepare windows
```
Le nom du nouveau modèle de VM généré doit correspondre à la valeur du champ osImage du pool de nœuds Windows dans le fichier de configuration du cluster d'utilisateurs. Si les valeurs correspondent, passez à l'étape suivante pour recréer le nœud Windows.

Si le nom du modèle ne correspond pas à la valeur du champ osImage, mettez à jour la valeur osImage pour qu'elle corresponde au nouveau nom du modèle de VM généré, puis exécutez la commande suivante :
```
gkectl update cluster
```
Recréez le nœud Windows en exécutant la commande suivante :
```
kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
```
Attendez que le contrôleur recrée automatiquement le nœud.