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

Con Google Distributed Cloud puoi creare un pool di nodi del sistema operativo Windows Server. Il cluster utente che esegue i pool di nodi del sistema operativo Windows Server può anche 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 contenente nodi del sistema operativo Windows Server, assicurati di soddisfare i seguenti requisiti:

  • Per poter creare un pool di nodi Windows, è necessario che sia già attivo un cluster di amministrazione, poiché un pool di nodi Windows è 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. Abilita Dataplane V2 sui nodi Linux nel 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 VM Windows per Google Distributed Cloud

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

  1. Creare un modello di VM Windows di base dall'ISO di Windows Server 2019.

    • Il tipo di scheda di rete iniziale per la VM Windows per installare Windows Server 2019 ISO deve essere E1000E.
    • Segui questi passaggi: Crea un modello VMware vSphere per Windows Server 2019.
    • Prendi nota della password iniziale che viene 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. Controlla le nostre note di rilascio per scoprire la versione qualificata dell'immagine del sistema operativo Windows per una determinata versione di rilascio di Anthos. Vedi Procedura patch di sicurezza.
    • Non puoi collegare alcun dispositivo che utilizza il controller IDE al modello di VM di base.

  2. Installa VMware Tools sul modello di VM di base di Windows, 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 del bundle Google Distributed Cloud

    Nell'ambito della creazione del modello di VM Windows di base, gkectl prepare windows esegue Windows sysprep. Questo generalizza il modello di VM e pulisce le impostazioni di rete per la VM, evitando così conflitti di indirizzi IP quando le VM vengono clonate dallo stesso modello. Tuttavia, Windows sysprep viene eseguito come un riquadro chiuso, quindi è 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

Ometti questo passaggio se non stai utilizzando un registro privato.

Puoi automatizzare il caricamento delle immagini container Windows in un registro privato utilizzando containerd su una workstation di amministrazione Linux. Tuttavia, containerd non può eseguire il push del livello base dell'immagine container di Windows, il che significa che i livelli di base devono essere estratti dal registro Microsoft al momento del pull dell'immagine. Per spingere i 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 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 base di Windows al registro privato:

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

  • Carica le immagini container Windows insieme ai relativi livelli di base nel tuo registro privato seguendo questa procedura:

    • Vai al file daemon.json Docker sulla tua macchina Windows: 

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

    • Aggiungi le seguenti righe per configurare il file Docker daemon.json e consentire il push di livelli esterni al tuo 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 nel registro privato. Le modifiche apportate al file di configurazione Docker daemon.json significano che è possibile eseguire il push del livello di base al 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 utilizzi 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 del server proxy oltre agli altri indirizzi richiesti da 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

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 riga seguente 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 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 strumenti di convalida 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 è pensato 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 tuo cluster utente.
  • Sebbene non sia consigliabile, puoi saltare i controlli preflight di Windows con il flag --skip-validation-windows.
  • La gestione dei pool di nodi Windows è la stessa che per i pool di nodi Linux. Consulta Gestione dei pool di nodi. Anche i comandi per creare, aggiornare ed eseguire l'upgrade di cluster e pool di nodi rimangono invariati 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 che 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 Windows Server. Per pianificare i container di Windows Server sui nodi Windows Server, il file manifest deve includere questa sezione nodeSelector:

nodeSelector:
    kubernetes.io/os: windows

Con nodeSelector configurato, un webhook di ammissione in esecuzione nel cluster controlla i nuovi carichi di lavoro per verificare la presenza di questo selettore di nodi Windows e, se trovato, applica la seguente tolleranza al carico di lavoro, che ne consente l'esecuzione sui nodi Windows Server incompatibili:

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

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

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 esponilo 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 non indica che lo stato del pod è "In esecuzione".

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

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

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 di cluster utente solo Linux, tranne per il fatto che devi creare un modello di VM Windows da un modello di VM di base prima di eseguire l'upgrade.

Puoi aggiornare la versione di 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 Procedura 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 il comando seguente 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 è mediante nome utente e password, a differenza dei nodi Linux, ai quali si accede in genere tramite coppie di chiavi SSH per l'autenticazione.

Per i nodi Windows su 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. Dopodiché potrai trovare la password nella proprietà vApp password di quella VM.

Una volta ottenuti il nome utente e la password, puoi accedere alla VM Windows utilizzando uno dei seguenti approcci:

Utilizzo di Remote Desktop Protocol

Poiché l'RDP è stato abilitato durante la creazione del modello, puoi accedere alla 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 una VM Windows

Puoi trasferire file da e verso la 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 alle VM Windows.

Aggiornamento della configurazione di Windows Server

Containerd e Windows Dataplane V2 sono ora in disponibilità generale a partire dalla versione 1.11.

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

Impossibile utilizzare SSH/RDP per la VM Windows

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

Il risultato dovrebbe contenere PingSucceeded: true in caso di connessione di rete. Se la VM non dispone di una connessione di rete, controlla l'adattatore di rete utilizzato per la VM. Assicurati che la rete consenta le connessioni in entrata alla VM dalla workstation in cui vuoi eseguire SSH/RDP.

Verifica che i servizi kubelet, kube-proxy e CNI siano in esecuzione sulla VM Windows

Connettiti alla VM seguendo questi passaggi ed esegui questi comandi, a seconda della 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 il cluster è configurato con 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 esclusione sia "In esecuzione":

    # Check that the flanneld process exists
Get-Process flanneld

Utilizzo dello strumento Snapshot

Utilizza lo strumento Snapshot per acquisire il tarball dello snapshot. Questo tarball contiene i file di log sui nodi e gli output per la risoluzione dei problemi dei comandi eseguiti sul nodo.

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

Creazione della VM Windows non riuscita

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 modello di VM si trovi nello stesso data center e nello stesso datastore specificato nel file di configurazione del cluster utente.

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

  • Controlla i log di avvio sul nodo che si trova all'indirizzo C:\var\log\startup.log per verificare se si è verificato un errore di avvio.

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

  • Controlla se cloudbase-init ha già eseguito UserDataPlugin prima di eseguire lo script di avvio.

Per verificarlo, crea una connessione SSH alla VM Windows ed esegui questo comando:

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

Se trovi UserDataPlugin: 1 nell'output, significa che cloudbase-init ha già eseguito il plug-in, con la conseguenza che l'esecuzione dello script di avvio verrà saltata e il nodo di Windows non verrà avviato.

Questo è causato di solito dalla conversione del modello di VM generato da gkectl prepare windows in una VM e dall'accensione.

Per risolvere il problema, crea un nuovo modello di VM eseguendo di nuovo gkectl prepare windows e utilizzalo per creare/eseguire l'upgrade/aggiornamento del pool di nodi di Windows.

Logging e Monitoring

Google Distributed Cloud supporta il logging e il monitoraggio per nodi e pod Windows, così come per nodi e pod Linux.

Durante la configurazione del logging e del monitoraggio, 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 di Windows

L'agente di logging di Windows raccoglie i seguenti log:

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

    Tieni presente che i log dei carichi di lavoro delle applicazioni utente 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 del nodo: log eventi kubelet, kube-proxy e Windows

Puoi accedere ai log utilizzando Esplora log nella console. Per ulteriori informazioni, consulta Accedere ai log.

Agente di monitoraggio di Windows

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 dei nodi e dei pod di Windows, utilizza le dashboard preparate. Dalla console, seleziona Monitoraggio > Dashboard, quindi seleziona "Stato del nodo Windows di GKE on-prem" e "Stato dei pod Windows di 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 utilizzi 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 di 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 per Windows a tua scelta, ad esempio il driver CSI SMB.

Rilevatore dei problemi dei nodi sui nodi Windows

Il daemon Rilevatore problemi dei nodi è disponibile sui nodi Windows. Se hai eseguito l'upgrade alla versione 1.9, il rilevatore dei problemi dei nodi viene abilitato automaticamente. Il rilevatore dei problemi del nodo consente di rilevare rapidamente alcuni problemi comuni relativi ai nodi. Il rilevatore di problemi del nodo continua a controllare eventuali problemi e li segnala come eventi e condizioni sul nodo. Quando un nodo non funziona correttamente, 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 monitoraggi del rilevatore di problemi dei nodi, cerca il nome del monitoraggio nel campo reason di una regola specificata nella sezione rules.

I monitor di rilevamento dei problemi del nodo 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, impedendo 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 rilevamento dei problemi dei nodi si trovano nella cartella C:\var\log\node-problem-detector del nodo. Se sono abilitati logging e il monitoraggio, il log viene esportato in Cloud Logging e puoi visualizzarlo in Esplora log.

Utilizza questo filtro per ottenere i log del 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 alle normali patch per le versioni di Anthos supportate, il team Anthos qualifica continuamente gli aggiornamenti delle patch di Windows più recenti durante i periodi di tempo non di rilascio e pubblica i risultati come riferimento. Se è necessario un aggiornamento urgente della patch di sicurezza tra le release delle patch di Anthos, puoi creare un nuovo modello di VM utilizzando l'ultima versione, quindi eseguire un aggiornamento in sequenza per i pool di nodi Windows esistenti in modo da utilizzare il nuovo modello.

Il processo delle patch di sicurezza include questi 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 dell'idoneità.
  • Se sono qualificati, gli utenti:
    • Scarica l'ultima versione della patch da Microsoft
    • Crea un nuovo modello di VM Windows utilizzando questa versione di patch seguendo i passaggi riportati 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 prossimo rilascio mensile della patch di Anthos ed eseguire l'upgrade dei cluster.

  • Se la nuova versione Windows non è del tutto compatibile con Anthos, il team Anthos la ignorerà e attenderà il successivo aggiornamento della sicurezza da Microsoft.

Aggiunta al dominio Active Directory

L'unione al 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 a 15 caratteri. Queste istruzioni sono basate sulle istruzioni per la creazione di pool di nodi Windows, con il passaggio aggiuntivo relativo alla fornitura di uno script personalizzato durante la creazione dei modelli di VM Windows.

Verifica che il server DNS di Active Domain 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 di comunicare tra i controller di dominio che ospitano il servizio di directory.

Il server DNS è stato creato quando il ruolo AD DS ha installato la foresta principale. Per poter aggiungere al dominio AD, qualsiasi VM Windows deve poter raggiungere il server DNS. Configura le configurazioni DNS e firewall seguendo le indicazioni del fornitore di servizi DNS che utilizzi. Per 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'aggiunta 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.
    • È consigliabile utilizzare un account utente con le autorizzazioni minime richieste per l'unione di un dominio Active Directory, anziché utilizzare un utente amministratore.
    • (Facoltativo) Per evitare di archiviare la password come testo in chiaro in questo script, inserisci la password in un file sul modello di VM, lascia che lo script legga dal file della password, quindi elimina il file dopo l'unione del 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 bundle.

Passaggio 2: crea un pool di nodi Windows

Segui le istruzioni standard nei passaggi da 2 a 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

Sulla 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

(Facoltativo) Passaggio 4: configura gli account di servizio gestiti dal gruppo

Segui queste istruzioni: 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 dello script personalizzato di cloudbase-init si trovano in 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. - Aggiornare i pool di nodi Windows per utilizzare il nuovo modello eseguendo:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Considerazioni sui container Windows

Ecco alcune differenze significative tra i container Windows e Linux:

  • Compatibilità delle versioni delle immagini container Windows e delle immagini del sistema operativo host/nodo.
    • La tupla della versione del sistema operativo Windows Server è composta da quattro parti: maggiore, 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 corrispondere, anche se è consigliabile aggiornare sia le immagini di base dell'host che 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, come i daemonset.

Limitazioni per Google Distributed Cloud su vSphere Windows

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

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

  • Poiché per i nodi Windows sono riservate 1,5 volte più risorse rispetto ai nodi Linux, il numero di risorse allocabili per Windows è inferiore.

  • L'uso di nodi Windows potrebbe richiedere una dimensione minima della macchina maggiore di quella di Google Distributed Cloud Linux. I nodi Windows in genere richiedono più risorse a causa del maggiore overhead associato all'esecuzione dei componenti/dei servizi dei nodi.

Problemi noti

In questa sezione sono elencati i problemi noti relativi ai nodi Windows utilizzati con Google Distributed Cloud, insieme alle soluzioni alternative per evitare o risolvere i problemi.

I pod Windows non possono comunicare con indirizzi IP esterni

Questo problema è descritto nella documentazione Microsoft in cui si legge: "Devi escludere l'IP esterno su cui stai tentando di eseguire una query dall'elenco delle eccezioni".

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

La pulizia dei container Windows non viene eseguita dopo la rimozione dei pod Windows.

Si tratta di un problema noto in cui il Docker RemoveContainer tenta anche di chiamare CreateFile su Windows. Come soluzione alternativa, accedi al nodo Windows che presenta il problema, esegui Restart-Service docker e il problema dovrebbe essere ridotto. In Google Distributed Cloud 1.9, la versione dell'immagine container fluent-bit-win e la versione Docker sono state aggiornate in modo da rilevare le correzioni upstream per questo problema, il che non dovrebbe più essere riprodotto. Se riscontri questo problema, contatta l'assistenza Google Cloud.

Nodi Windows con conflitti di indirizzi IP

Questo è un problema noto che si verifica molto raramente. Se lo riscontri durante la creazione del pool di nodi Windows, puoi mitigarlo seguendo questi passaggi:

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

  • Se utilizzi la modalità DHCP, è probabile che le VM appena create abbiano di nuovo IP duplicati poiché il server DHCP riscontra 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 le allocazioni IP corrette.

Il nodo Windows diventa NotReady dopo il riavvio della VM

Attualmente, lo script di avvio del nodo viene eseguito solo la prima volta che la VM viene accesa, 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 il nodo sia nello stato NotReady. Se utilizzi Windows Dataplane V2, anche la rete inattiva deve essere ripulita prima che i servizi Dataplane V2 possano riavviarsi e sarà necessario eseguire uno script per la pulizia, il che potrebbe causare complicazioni. Di conseguenza, ricrea il nodo. Come soluzione alternativa, puoi eliminare il nodo eseguendo il comando in basso e attendere che il controller lo ricrea automaticamente.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Il comando di diagnostica non riesce quando le versioni dell'hardware delle VM Windows sono inferiori al previsto

Quando il modello di VM Windows utilizza una versione hardware obsoleta, 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 VM di base di Windows in una VM.

  3. Segui i passaggi descritti in Upgrade di una macchina virtuale alla versione hardware più recente per eseguire l'upgrade della versione hardware della VM.

  4. Riconverti la VM in un modello di VM.

  5. Esegui questo comando per preparare un nuovo modello di VM, utilizzando il modello di VM aggiornato dei 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 Windows nel file di configurazione del cluster utente. Se i valori corrispondono, vai al passaggio successivo per ricreare il nodo 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.