Guida dell'utente per i pool di nodi del sistema operativo Windows Server

Con GKE su VMware, puoi creare un pool di nodi di nodi del sistema operativo Windows Server. Il cluster utente che esegue i pool di nodi del sistema operativo Windows Server può inoltre eseguire pool di nodi che contengono nodi utilizzando Ubuntu o Container-Optimized OS.

Requisiti per un pool di nodi del sistema operativo Windows Server

I nodi in un pool di nodi devono utilizzare tutti lo stesso sistema operativo, indicato dal parametro osImageType.

Prima di creare nel cluster utente un pool di nodi con nodi del sistema operativo Windows Server, assicurati di soddisfare i seguenti requisiti:

  • Per poter creare un pool di nodi Windows, è necessario che sia già presente un cluster di amministrazione, perché quest'ultimo è supportato solo nel cluster utente.
  • Il cluster utente deve eseguire almeno un pool di nodi Linux, poiché il pool di nodi Linux è necessario per creare un pool di nodi Windows.
  • Un cluster utente con pool di nodi Windows deve avere il campo enabledataplanev2 impostato su true nel file di configurazione del cluster utente. Ciò abilita Dataplane V2 sui nodi Linux in quel cluster.

  • Per impostazione predefinita, Windows Dataplane V2 è abilitato per i pool di nodi Windows per i nuovi cluster utente.

  • Hai scaricato un file ISO di Windows Server 2019 da Microsoft per creare un modello di VM specifico per i pool di nodi Windows. Il tag della lingua/regione per l'ISO deve essere en-US.

  • L'ambiente vSphere deve essere vSphere 6.7, Update 3 o successivo.

Crea un pool di nodi Windows in un cluster utente

Passaggio 1: crea il modello di VM Windows per GKE su VMware

Prima di iniziare, assicurati di aver già creato un cluster di amministrazione.

  1. Crea un modello di VM Windows di base dallo standard ISO di Windows Server 2019.

    • Il tipo di scheda di rete iniziale per la VM Windows per l'installazione ISO di Windows Server 2019 deve essere E1000E.
    • Segui questi passaggi: Creare un modello VMware vSphere per Windows Server 2019.
    • Prendi nota della password iniziale impostata quando esegui il programma di installazione ISO di Windows per utilizzarla in futuro.
    • Assicurati di utilizzare la versione più recente della patch qualificata per Windows Server 2019; consulta le nostre note di rilascio per scoprire la versione più recente dell'immagine qualificata del sistema operativo Windows per una determinata versione di release di Anthos. Vedi Processo di patch di sicurezza.
    • Non puoi collegare nessun dispositivo che utilizza il controller IDE al modello di VM di base.

  2. Installa VMware Tools sul modello di VM Windows di base, se non è già installato, utilizzando le istruzioni di VMware.

  3. Crea un modello di VM Windows:

    gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]

    Sostituisci quanto segue:

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

    • BASE_WINDOWS_VM_TEMPLATE: il percorso del modello di VM Windows di base

    • BUNDLE: il percorso del file bundle GKE su VMware

    Durante la creazione del modello di VM Windows di base, gkectl prepare windows esegue Windows sysprep. Questo generalizza il modello VM e pulisce le impostazioni di rete per la VM, aiutando così a evitare conflitti di indirizzi IP quando le VM vengono clonate dallo stesso modello. Tuttavia, Windows sysprep viene eseguito come scatola chiusa, pertanto è difficile gestire alcuni errori di sysprep.

    Se vuoi creare un modello di VM Windows di base senza eseguire Windows sysprep, includi --skip-sysprep nel comando gkectl prepare windows.

  4. Nell'ultima riga dell'output comando puoi trovare il nome del modello di VM Windows generato. Prendi nota del nome per utilizzarlo in futuro. Il nome ha il seguente formato:

    Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"

Passaggio 2: carica le immagini container Windows in un registro privato

Salta questo passaggio se non utilizzi un registro privato.

Puoi automatizzare il caricamento delle immagini dei container Windows in un registro privato utilizzando containerd su una workstation di amministrazione Linux. Tuttavia, containerd non può eseguire il push del livello di base dell'immagine container di Windows, il che significa che i livelli di base devono essere estratti dal registro Microsoft quando si esegue il pull dell'immagine. Per eseguire il push dei livelli di base, segui i passaggi per l'opzione 2.

Opzione 1: se non devi eseguire manualmente il push delle immagini del livello di base di Windows al registro privato:

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

Sostituisci ADMIN_CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione.

Il flag --upload-windows-images specifica che verrà eseguito il push delle immagini container di Windows. Verrà eseguito il push al registro privato solo delle immagini container Linux senza specificare questo flag.

Opzione 2: se devi eseguire manualmente il push delle immagini del livello di base di Windows al registro privato:

  • Utilizza una macchina Windows con Docker installato e con accesso a gcr.io prima di eseguire questi passaggi. Puoi eseguire il pull delle immagini container Windows solo su un computer Windows.
  • Esegui docker login per l'autenticazione nel registro privato.

  • Carica le immagini di Windows Container insieme ai relativi livelli di base nel registro privato, procedendo nel seguente modo:

    • Vai al file Docker daemon.json sul tuo computer Windows: 

      PS C:> cat C:\ProgramData\docker\config\daemon.json

    • Aggiungi le seguenti righe per configurare il file Docker daemon.json in modo da consentire il push di livelli esterni al registro privato:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Scarica le immagini container di Windows richieste sul tuo computer Windows locale, quindi taggale ed eseguine il push al registro privato. Le modifiche apportate al file di configurazione Docker di daemon.json indicano che è possibile eseguire il push del livello di base nel registro privato. Per completare queste attività, esegui questi comandi:
# 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

Passaggio 3: (obbligatorio se viene utilizzato il proxy) inserisci gli URL nella lista consentita per la creazione di pool di nodi Windows

Se il cluster si trova dietro un server proxy, aggiungi questi URL alla lista consentita dei server proxy oltre agli altri indirizzi richiesti da GKE su VMware.

# 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

Passaggio 4: aggiungi un pool di nodi Windows al file di configurazione del cluster utente

  1. Per utilizzare i pool di nodi Windows, devi abilitare Dataplane V2 nel cluster utente. Aggiungi la seguente riga al file di configurazione del cluster utente per abilitare Dataplane V2:

    enableDataplaneV2: true

  2. Aggiungi un pool di nodi Windows alla sezione nodePools nel file di configurazione del cluster utente. È richiesto almeno un pool di nodi Linux oltre ai pool di nodi Windows. Imposta i campi osImage e osImageType per creare pool di nodi Windows:

  • osImage: sostituisci WINDOWS_VM_TEMPLATE_NAME con il nome del tuo modello di VM Windows preparato nel passaggio 1, che deve trovarsi nello stesso datastore vCenter specificato nel file di configurazione del cluster utente.
  • osImageType: specifica windows come tipo di immagine del sistema operativo.
# user-cluster.yaml

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

Passaggio 5: crea pool di nodi Windows

Prima di creare pool di nodi Windows, esegui un elenco di convalidatori preflight per Windows. Ignora questo passaggio se hai già un cluster utente. - (Facoltativo) Esegui uno o entrambi i controlli preflight rapidi e lenti, che creano una VM di test per Windows e convalidano il modello di VM Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Questo comando è progettato per essere eseguito prima di creare un cluster utente. Se hai già un cluster utente, alcuni controlli potrebbero non riuscire. Ad esempio, gli indirizzi IP nel file hostconfig.yaml potrebbero essere già utilizzati da nodi esistenti nel cluster utente.
  • Anche se non è consigliato, puoi saltare i controlli preflight di Windows con il flag --skip-validation-windows.
  • La gestione dei pool di nodi Windows è la stessa che avviene per i pool di nodi Linux. Vedi Gestione dei pool di nodi. Anche i comandi per la creazione, l'aggiornamento e l'upgrade di cluster e pool di nodi rimangono gli stessi e sono elencati qui.
# 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

Passaggio 6: verifica che i nodi Windows siano in esecuzione

  1. Verifica che i nodi Windows siano stati creati e siano Ready.

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Esegui la diagnostica del cluster utente per verificare se è integro.

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

Esegui il deployment di un pod Windows

I nodi Windows Server sono incompatibili con questa coppia chiave-valore: node.kubernetes.io/os=windows:NoSchedule.

Questa incompatibilità garantisce che lo scheduler GKE non tenti di eseguire container Linux sui nodi di Windows Server. Per pianificare i container Windows Server sui nodi Windows Server, il file manifest deve includere questa sezione nodeSelector:

nodeSelector:
    kubernetes.io/os: windows

Se nodeSelector è configurato, un webhook di ammissione in esecuzione nel cluster controlla la presenza di questo selettore di nodi Windows nei nuovi carichi di lavoro e, quando viene trovato, applica la seguente tolleranza al carico di lavoro, che ne consente l'esecuzione sui nodi di Windows Server incompatibili:

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

Passaggio 1: crea un file di deployment di Internet Information Services (IIS)

Ecco una configurazione di esempio, che esegue il deployment dell'immagine IIS ufficiale di Microsoft in un singolo pod.

Crea un file IIS denominato iis.yaml con i seguenti contenuti:

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]

Passaggio 2: crea il deployment ed esponi tramite un servizio

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

Passaggio 3: convalida il pod

Controlla lo stato del pod utilizzando kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Attendi finché l'output restituito indica che lo stato del pod è "Running".

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

Ottieni lo stato del servizio e attendi che venga completato il campo dell'IP esterno.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Output previsto:

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

Puoi utilizzare il browser per aprire http://EXTERNAL_IP e visualizzare la pagina web di IIS.

Esegui l'upgrade del cluster utente con i pool di nodi Windows

Il processo di upgrade per un cluster utente con pool di nodi Windows è simile a quello per l'upgrade dei cluster utente solo Linux, con la differenza che devi creare un modello di VM Windows da un modello di VM di base prima di eseguire l'upgrade.

Puoi aggiornare la versione build della patch del modello di VM di base durante l'upgrade scaricando una versione patch più recente di Windows Server 2019 da Microsoft come patch di sicurezza. Vedi Processo di patch di sicurezza.

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

Aggiorna il campo osImage del pool di nodi nel file di configurazione con il nuovo nome del modello di VM. Esegui questo comando per eseguire l'upgrade del cluster utente:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

  • ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig dell'amministratore
  • ADMIN_CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione

Accesso ai nodi Windows

Il metodo standard per accedere ai nodi Windows consiste nell'utilizzare un nome utente e una password, diversi dai nodi Linux, che in genere sono accessibili tramite coppie di chiavi SSH per l'autenticazione.

Per i nodi Windows in vSphere, il nome utente è Administrator. La password viene generata da clusterapi-controller e archiviata nel secret windows-node-password nello spazio dei nomi utente del cluster di amministrazione. Il comando per ottenere la password da quel secret è:

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

Puoi anche ottenere la password utilizzando l'interfaccia utente di vCenter. Vai alla VM a cui vuoi accedere, quindi puoi trovare la password nella proprietà vApp password di quella VM.

Dopo aver recuperato il nome utente e la password, puoi accedere alla tua VM Windows utilizzando uno dei seguenti approcci:

Utilizzo di Remote Desktop Protocol

Poiché l'RDP è stato abilitato durante la build del modello, puoi accedere alla tua VM Windows utilizzando un client RDP.

Utilizzo di SSH

Per accedere tramite SSH a una VM Windows:

ssh Administrator@[VM_IP_ADDRESS]

Segui le istruzioni per digitare la password per connetterti alla VM.

Trasferimento di file da e verso la VM Windows

Puoi trasferire file da e alla tua VM Windows con il comando scp:

Carica i file sulla VM Windows:

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

Scarica i file dalla VM Windows:

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

Digita la password quando richiesto.

In alternativa, puoi anche trasferire i file utilizzando Cloud Storage o RDP, come descritto in Trasferimento di file su VM Windows.

Aggiornamento della configurazione di Windows Server

Containerd e Windows Dataplane V2 sono ora disponibili pubblicamente a partire dalla versione 1.11.

Docker e Flannel per i nodi Windows verranno deprecati in una release successiva. Ti consigliamo di aggiornare ora la configurazione, se applicabile, in modo da utilizzare invece containerd e Windows Dataplane V2. Vedi Aggiornare la configurazione di Windows Server.

Risoluzione dei problemi

Rimuovi Docker e Flannel dalla configurazione del cluster

Se utilizzi nodi Windows, a partire dalla versione 1.11 verrà visualizzato un avviso che ti informa che Docker e Flannel verranno rimossi in una versione successiva. Devi aggiornare la configurazione del cluster per rimuovere Docker e Flannel per i nodi Windows.

Nel file di configurazione del cluster utente, imposta il campo enableWindowsDataplaneV2 su true ed esegui gkectl update cluster.

Impossibile utilizzare SSH/RDP per la VM Windows

Verifica se la VM ha una connessione di rete eseguendo Test-NetConnection sulla console web vCenter.

Il risultato dovrebbe contenere PingSucceeded: true se è presente una connessione di rete. Se la VM non ha una connessione di rete, controlla la scheda di rete utilizzata per questa VM. Assicurati che la rete consenta le connessioni in entrata alla VM dalla workstation in cui vuoi eseguire SSH/RDP.

Verifica che il servizio kubelet, kube-proxy e CNI siano in esecuzione sulla VM Windows

Connettiti alla VM seguendo i passaggi qui ed esegui i comandi seguenti, a seconda della tua configurazione:

  1. Per tutte le configurazioni, esegui questi comandi:

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

  2. Se nel cluster è configurato windowsDataplaneV2 impostato su true, verifica che i servizi antrea-agent, ovsdb-server e ovs-vswitchd siano "In esecuzione".

    # Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd

  3. Altrimenti, controlla che il processo di riempimento sia "In esecuzione":

    # Check that the flanneld process exists
Get-Process flanneld

Utilizzo dello strumento per le istantanee

Utilizza lo strumento Istantanea per acquisire il tarball delle istantanee. Questo tarball contiene i file di log sui nodi e gli output per la risoluzione dei problemi relativi ai comandi in esecuzione sul nodo.

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

La creazione della VM Windows non riesce

Controlla i log del container vSphere-controller-manager nel pod clusterapi-controllers nello spazio dei nomi utente del cluster di amministrazione.

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

Assicurati che il tuo modello di VM si trovi nello stesso data center e nello stesso datastore specificato nel file di configurazione del cluster utente.

La VM Windows viene creata, ma il nodo non si avvia correttamente o non viene visualizzato

  • Controlla i log di avvio sul nodo situato in C:\var\log\startup.log per verificare se si è verificato un errore durante l'avvio.

    • Se flanneld non è in esecuzione, prova a eseguire di nuovo lo script di avvio che si trova all'indirizzo C:\etc\startup\startup-script.ps1
    • Se kubelet non è in esecuzione, controlla i log di kubelet in "C:\var\log".
    • Se kube-proxy non è in esecuzione, controlla i log di kube-proxy in C:\var\log.

Logging e Monitoring

GKE su VMware supporta il logging e il monitoraggio per i nodi e i pod di Windows, così come per i nodi e i pod Linux.

Quando il logging e il monitoraggio sono configurati, viene eseguito il deployment degli agenti sui nodi Windows. Questi agenti raccolgono, elaborano ed esportano i log e le metriche del nodo.

Agente di logging Windows

L'agente Logging di Windows raccoglie i seguenti log:

  • Tipo di risorsa pod: carichi di lavoro delle applicazioni utente e di sistema.

    Tieni presente che i log dei carichi di lavoro delle applicazioni utente di Windows vengono raccolti per impostazione predefinita. Per disabilitare i log delle applicazioni:

    • Modifica la configmap fluent-bit-windows-config e commenta l'elemento [Input] che raccoglie i log dell'applicazione (il primo elemento [Input]): 
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      Assicurati di commentare tutti i campi di questo elemento. Ad esempio: 
      #    [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
    • Esegui il comando rollout restart per riavviare il daemonset fluent-bit-windows: 
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

  • Tipo di risorsa nodo: kubelet, kube-proxy e log eventi di Windows

Puoi accedere ai log utilizzando Esplora log nella console. Per ulteriori informazioni, consulta Log degli accessi.

Agente Windows Monitoring

L'agente di monitoraggio di Windows raccoglie un set di metriche di utilizzo di CPU e memoria diverso rispetto all'agente di monitoraggio di Linux. Per monitorare lo stato di nodi e pod di Windows, utilizza le dashboard preparate. Dalla console, seleziona Monitoraggio > Dashboard, quindi seleziona "Stato del nodo Windows su GKE on-prem" e "Stato pod Windows GKE on-prem" dall'elenco Tutte le dashboard.

Queste dashboard vengono create automaticamente durante l'installazione del cluster di amministrazione, se Cloud Monitoring è abilitato. Se hai già un cluster di amministrazione in esecuzione, segui queste istruzioni per creare queste dashboard, utilizzando i seguenti file JSON:

Consulta l'elenco completo delle metriche raccolte dagli agenti Windows.

Archiviazione permanente Windows

Quando lavori con container Windows Server con archiviazione permanente, devi creare un oggetto StorageClass e specificare il nome dell'oggetto nel campo storageClassName dell'oggetto PersistentVolumeClaim, perché il valore predefinito StorageClass nel cluster utente on-prem utilizza ext4 come tipo di file system, che funziona solo per i container Linux. Per Windows, dobbiamo impostare il tipo di file system su ntfs.

Esempio di classe di archiviazione 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

Il deployment del proxy CSI viene eseguito automaticamente sui nodi Windows. Puoi installare e utilizzare un driver CSI di Windows a tua scelta, ad esempio il driver CSI SMB.

Rilevamento problemi dei nodi sui nodi Windows

Il daemon di Node Problem Detector è disponibile sui nodi Windows. Se hai eseguito l'upgrade alla versione 1.9, il rilevatore di problemi relativi ai nodi viene abilitato automaticamente. Il rilevatore di problemi dei nodi consente di rilevare rapidamente alcuni problemi comuni dei nodi. Il rilevatore di problemi dei nodi continua a controllare i possibili problemi e li segnala come eventi e condizioni sul nodo. Quando un nodo ha un comportamento anomalo, puoi utilizzare il comando kubectl per trovare gli eventi e le condizioni corrispondenti.

Le seguenti configurazioni di monitoraggio sono abilitate per il rilevatore di problemi dei nodi:

Per ottenere eventi e condizioni su un nodo:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Sostituisci:

  • KUBECONFIG con il percorso del file kubeconfig per il cluster che contiene il nodo.
  • NODE_NAME con il nome del nodo.

Per identificare gli eventi generati dai monitor di Rilevatore di problemi dei nodi, cerca il nome del monitoraggio nel campo reason di una regola specificata nella sezione rules.

I monitor di Rilevatore di problemi dei nodi generano anche le seguenti condizioni sul nodo. Ognuna di queste opzioni è impostata su true se il rilevatore di problemi del nodo rileva lo scenario di errore corrispondente sul nodo.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Ogni volta che una delle condizioni è impostata su true, la condizione Pronto del nodo diventa false, il che impedisce la pianificazione di nuovi pod sul nodo.

Quando viene rilevata una condizione non integro, il rilevatore di problemi del nodo tenta di riparare automaticamente il nodo riavviando il servizio di sistema pertinente.

I log di Rilevatore di problemi relativi ai nodi si trovano nella cartella C:\var\log\node-problem-detector del nodo. Se le opzioni logging e monitoraggio sono abilitate, il log viene esportato in Cloud Logging e puoi visualizzarlo in Esplora log.

Utilizza questo filtro per ottenere i log di Rilevatore di problemi dei nodi in Esplora log:

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

Sostituisci PROJECT_NAME con il nome del progetto.

Processo patch di sicurezza

Oltre ai normali rilasci di patch per le versioni di Anthos supportate, il team Anthos qualifica continuamente gli aggiornamenti patch di Windows più recenti durante periodi di tempo non di rilascio e pubblica i risultati come riferimento. Se è necessario un aggiornamento urgente della patch di sicurezza tra le release della patch di Anthos, puoi creare un nuovo modello di VM utilizzando la versione più recente, quindi eseguire un aggiornamento in sequenza per i pool di nodi Windows esistenti in modo che utilizzino il nuovo modello.

Il processo delle patch di sicurezza prevede i seguenti passaggi:

  • Microsoft rilascia una nuova patch di sicurezza per Windows Server 2019.
  • Anthos qualifica la versione più recente della patch di sicurezza e annuncia il risultato della qualificazione.
  • Se qualificati, gli utenti:
    • Scarica l'ultima versione della patch da Microsoft
    • Crea un nuovo modello di VM Windows utilizzando questa versione della patch seguendo la procedura descritta qui.
    • Aggiorna i pool di nodi Windows per utilizzare il nuovo modello eseguendo:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • Se la nuova versione richiede modifiche da parte di Anthos, devi attendere il rilascio della patch mensile successiva per Anthos ed eseguire l'upgrade dei cluster.

  • Se la nuova versione di Windows non è compatibile con Anthos, il team di Anthos la ignorerà e attenderà il prossimo aggiornamento della sicurezza di Microsoft.

Aggiunta al dominio Active Directory

L'unione del dominio Active Directory richiede che la lunghezza del nome host della VM sia <= 15 caratteri. Per la modalità IPAM, poiché il nome host della VM è impostato nel file di configurazione del cluster utente, devi assicurarti che la lunghezza sia inferiore o pari a 15 caratteri. Queste istruzioni si basano su quelle per la creazione di pool di nodi Windows, con il passaggio aggiuntivo che prevede la fornitura di uno script personalizzato durante la creazione del modello VM Windows.

Verifica che il server DNS del dominio attivo sia raggiungibile

Active Directory Domain Services (AD DS) utilizza i servizi di risoluzione dei nomi DNS (Domain Name System) per consentire ai client di individuare i controller di dominio e ai controller di dominio che ospitano il servizio di directory di comunicare tra loro.

Il server DNS è stato creato quando il ruolo AD DS ha installato la foresta principale. Affinché una VM Windows possa aggiungere il dominio AD, deve poter raggiungere il server DNS. Configura le configurazioni DNS e del firewall seguendo le indicazioni del provider di servizi DNS che utilizzi. Puoi verificare se le VM Windows nella rete attuale possono contattare il server DNS del dominio AD eseguendo questo comando:

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

Passaggio 1: crea un modello di VM Windows con uno script personalizzato

  1. Esegui uno script personalizzato prima che il nodo Windows si unisca al cluster utente per l'unione al dominio Active Directory. Archivia questo script in un percorso locale sulla workstation di amministrazione. Ricorda:

    • Puoi sostituire lo script con il tuo script per eseguire l'unione al dominio Active Directory.
    • Ti consigliamo di utilizzare un account utente con le autorizzazioni minime richieste per aggiungere un dominio Active Directory invece di un utente amministratore.
    • (Facoltativo) Per evitare di memorizzare la password come testo in chiaro in questo script, inseriscila in un file sul modello di VM, consenti allo script di leggere il file delle password, quindi elimina il file dopo l'unione al dominio.
    $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

  2. Crea un modello di VM Windows con uno script personalizzato:

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

Sostituisci BUNDLE_PATH con il percorso del pacchetto.

Passaggio 2: crea un pool di nodi Windows

Procedi con le istruzioni standard nei passaggi 2-6 per creare un pool di nodi Windows utilizzando il modello di VM Windows personalizzato.

Passaggio 3: verifica l'unione del dominio attivo per i nodi Windows

Nella VM del controller di dominio AD, esegui questo comando:

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

Passaggio 4: configura gli account di servizio gestiti dai gruppi (facoltativo)

Segui queste istruzioni per configurare GMSA per pod e container Windows. Puoi configurare GMSA per pod e container Windows dopo l'aggiunta dei nodi al dominio.

Risoluzione dei problemi

I log per l'esecuzione personalizzata degli script di cloudbase-init si trovano all'indirizzo C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Cerca LocalScriptPlugin nel file di log e controlla i log correlati. - Creare un nuovo modello di VM Windows. - Aggiorna i pool di nodi Windows in modo che utilizzino il nuovo modello eseguendo:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Configura il supporto Containerd per i pool di nodi Windows

Il runtime containerd è ora disponibile come funzionalità per i pool di nodi Windows. Il supporto per i runtime Docker è stato rimosso in GKE su VMware versione 1.13.

Per abilitare containerd, assicurati di aver impostato enableWindowsDataplaneV2 su true in ogni file di configurazione del cluster utente applicabile.

Se esegui l'upgrade di un cluster utente creato prima della versione 1.10 e hai impostato enableWindowsDataplaneV2 su true nel file di configurazione del cluster utente, verrà utilizzato un runtime containerd.

Considerazioni sui container Windows

Di seguito sono riportate alcune differenze significative tra i container Windows e Linux:

  • Compatibilità della versione delle immagini container Windows e delle immagini host/sistema operativo nodo.
    • La tupla della versione del sistema operativo Windows Server è composta da quattro parti: principale, secondaria, build e revisione.
    • L'immagine di base del container Windows Server deve corrispondere alle prime tre parti della tupla di versione dell'immagine del sistema operativo host. La revisione non deve necessariamente corrispondere, anche se è consigliabile aggiornare le immagini di base dell'host e del container.
    • Gli utenti devono ricreare le immagini container ogni volta che cambia la versione dell'immagine del sistema operativo.
  • I container con privilegi e gli spazi dei nomi host non sono supportati.
    • Gli utenti non possono configurare/modificare i nodi eseguendo il deployment di container, ad esempio i daemonset.

Limitazioni per GKE su VMware su vSphere Windows

  • I cluster utente devono contenere almeno un pool di nodi Linux.

    • Non puoi creare un cluster solo con un pool di nodi Windows
    • I pool di nodi Linux sono necessari per eseguire componenti aggiuntivi critici.

  • Poiché per i nodi Windows sono riservate un numero di risorse 1,5 volte superiore rispetto a quelle per i nodi Linux, il numero di risorse allocabili per Windows è inferiore.

  • L'uso dei nodi Windows potrebbe richiedere una dimensione minima della macchina maggiore rispetto alla dimensione minima della macchina per GKE su VMware Linux. I nodi Windows richiedono in genere più risorse a causa del maggiore overhead associato all'esecuzione dei componenti/servizi dei nodi.

Problemi noti

Questa sezione elenca i problemi noti relativi ai nodi Windows utilizzati con GKE su VMware, insieme alle soluzioni alternative per evitarli o risolverli.

I pod Windows non possono comunicare con indirizzi IP esterni

Questo problema è descritto nella documentazione di Microsoft, in cui viene indicato "Devi escludere l'IP esterno su cui stai tentando di eseguire query dall'elenco delle eccezioni".

Contatta l'assistenza Google Cloud per procedere con una soluzione alternativa.

I container Windows non vengono puliti dopo la rimozione dei pod Windows

Si tratta di un problema noto per cui il docker RemoveContainer prova anche a chiamare CreateFile su Windows. Per risolvere il problema, accedi al nodo di Windows che presenta il problema, esegui Restart-Service docker per limitare il problema. In GKE su VMware 1.9, la versione dell'immagine container fluent-bit-win e la versione Docker sono state aggiornate per individuare le correzioni upstream per questo problema, che non dovrebbe essere più riprodotto. Se riscontri questo problema, contatta l'assistenza Google Cloud.

Nodi Windows con conflitti di indirizzi IP

Si tratta di un problema noto che si verifica molto raramente. Se lo si verifica durante la creazione del pool di nodi Windows, puoi mitigare il problema seguendo questi passaggi:

  • Se utilizzi la modalità IPAM, puoi rimuovere manualmente da vCenter le VM con conflitti IP. In questo modo, verranno create automaticamente nuove VM che dovrebbero avere le allocazioni IP corrette. Oppure puoi semplicemente attendere che la riparazione automatica dei nodi rilevi il problema e ricreare i nodi di Windows.

  • Se utilizzi la modalità DHCP, è probabile che le VM appena create abbiano di nuovo IP duplicati poiché il server DHCP sta riscontrando problemi di allocazione degli IP. Puoi eliminare il pool di nodi Windows in attesa eseguendo gkectl update cluster e aggiungerlo di nuovo in user-cluster.yaml, eseguire di nuovo gkectl update cluster per crearlo. Il pool di nodi appena creato deve avere allocazioni IP corrette.

Il nodo Windows diventa NotReady dopo il riavvio della VM

Attualmente, lo script di avvio del nodo viene eseguito solo alla prima accensione della VM. Quindi, se riavvii la VM, lo script di avvio non viene eseguito di nuovo. Ciò causerà l'interruzione dell'esecuzione di alcuni servizi Windows, tra cui i servizi kubelet, kube-proxy e così via. Questo fa sì che lo stato del nodo sia NotReady. Se utilizzi Windows Dataplane V2, anche la rete inattiva deve essere pulita prima che i servizi Dataplane V2 possano essere riavviati e sarà necessario eseguire uno script per la pulizia, il che potrebbe causare complicazioni. Di conseguenza, ricrea il nodo. Per risolvere il problema, puoi eliminare il nodo eseguendo il comando seguente e attendere che il controller lo ricrea automaticamente.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Il comando di diagnostica non va a buon fine quando le versioni hardware delle VM Windows sono inferiori al previsto

Quando il modello di VM Windows utilizza una versione hardware precedente, il comando gkectl diagnose cluster non riesce e viene visualizzato il seguente messaggio:

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",
    }

Per risolvere il problema:

  1. Rinomina il modello di VM attualmente in uso.

    Questa operazione è necessaria per poter creare un nuovo modello di VM nei passaggi successivi.

  2. Converti il modello di base VM di Windows in una VM.

  3. Segui la procedura descritta in Upgrade di una macchina virtuale alla versione hardware più recente per eseguire l'upgrade della versione hardware della VM.

  4. Converti la VM in un modello VM.

  5. Esegui questo comando per preparare un nuovo modello di VM, utilizzando il modello di VM aggiornato dai passaggi precedenti come modello di VM di base.

    gkectl prepare windows

    Il nuovo nome del modello di VM generato deve corrispondere al valore del campo osImage del pool di nodi di Windows nel file di configurazione del cluster utente. Se i valori corrispondono, vai al passaggio successivo per ricreare il nodo di Windows.

    Se il nome del modello non corrisponde al valore del campo osImage, aggiorna il valore osImage in modo che corrisponda al nuovo nome del modello di VM generato ed esegui questo comando:

    gkectl update cluster

  6. Ricrea il nodo Windows eseguendo questo comando:

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    Attendi che il controller ricrei automaticamente il nodo.