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

10

Con i cluster Anthos su VMware (GKE On-Prem), puoi creare un pool di nodi di nodi di 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 con nodi di 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é un pool di nodi Windows è supportato solo nel cluster utente.
  • Il cluster utente deve eseguire almeno un pool di nodi Linux, poiché è necessario creare un pool di nodi Linux per creare un pool di nodi Windows.
  • Per un cluster utente con pool di nodi Windows, il campo enabledataplanev2 deve essere impostato su true nel file di configurazione del cluster utente. Ciò consente Dataplane V2 sui nodi Linux in quel cluster.

  • Se vuoi che Windows Dataplane V2 sia abilitato per i pool di nodi Windows nel cluster utente, nel campo enableWindowsDataplaneV2 del file di configurazione del cluster deve essere impostato true. Se abiliti questa funzionalità, il vSwitch (specificato con network.vCenter.networkName nel file di configurazione del cluster utente) deve avere l'apprendimento MAC attivato.

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

  • Il tuo ambiente vSphere deve essere vSphere 6.7, aggiornamento 3 o successivo.

Crea un pool di nodi Windows in un cluster utente

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

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

  1. Creare un modello di VM Windows di base dagli 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 impostata quando esegui il programma di installazione ISO di Windows per utilizzarla in futuro.
    • Assicurati di utilizzare la versione più recente delle patch idonee per Windows Server 2019, 10.0.17763.2803. Vedi Processo di applicazione patch di sicurezza.
    • Non puoi collegare al dispositivo VM di base un dispositivo che utilizza il controller IDE.

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

  3. Crea un modello di VM Windows: 

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

  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 di Windows in un registro privato

Ometti questo passaggio se non utilizzi un registro privato.

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

Opzione 1: se non è necessario eseguire il push manuale delle immagini del livello base di Windows nel 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 di Windows Container. il push delle immagini container solo per Linux viene eseguito nel registro privato senza specificare questo flag.

Opzione 2: se devi inviare manualmente le immagini del livello base di Windows al registro privato:

  • Utilizza una macchina Windows su cui è installato Docker e con accesso a gcr.io, prima di provare a seguire questi passaggi. È possibile eseguire solo il pull di immagini container Windows su una macchina Windows.
  • Esegui docker login per eseguire l'autenticazione nel registro privato.

  • Carica le immagini container di Windows con i relativi livelli di base nel registro privato seguendo questa procedura:

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

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

    • Aggiungi le seguenti righe per configurare il tuo file daemon.json di Docker per consentire il push dei livelli stranieri nel registro privato:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Scarica le immagini container di Windows richieste nella tua macchina Windows locale, quindi taggale ed eseguine il push nel registro privato. A causa delle modifiche apportate al file di configurazione Docker daemon.json, è possibile eseguire il push del livello 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 un proxy) gli URL della lista consentita per la creazione dei pool di nodi Windows

Se il cluster è protetto da un server proxy, aggiungi questi URL alla lista consentita del server proxy oltre ad altri indirizzi richiesti da Cluster Anthos 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. Dataplane V2 deve essere abilitato nel cluster utente per utilizzare i pool di nodi Windows. 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. Oltre ai pool di nodi Windows, è richiesto almeno un pool di nodi Linux. 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 il tipo di immagine del sistema operativo windows.
# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 4
  memoryMB: 8192
  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 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 delle VM Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Questo comando è destinato a 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à in uso da parte di nodi esistenti nel 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 dei pool di nodi Linux. Vedi Gestione dei pool di nodi. Anche i comandi per creare, aggiornare ed eseguire 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: convalida i nodi Windows in esecuzione

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

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Diagnostica il cluster utente per verificare se è integro.

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

Eseguire il deployment di un pod Windows

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

Questa incompatibilità garantisce che lo scheduler di GKE non tenti di eseguire container Linux sui nodi di Windows Server. Per pianificare i container Windows Server sui nodi Windows Server, il tuo 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 rilevare la presenza di questo selettore di nodi Windows e, quando lo trova, applica la seguente tolleranza al carico di lavoro, consentendone 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 Internet Information Services (IIS)

Ecco un esempio di configurazione che esegue il deployment dell'immagine IIS ufficiale di Microsoft in un unico 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 mostra lo stato "In esecuzione" del pod.

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

Verifica lo stato del servizio e attendi che venga completato il campo 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 vedere 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 per Linux, con la differenza che devi creare un modello VM Windows da un modello VM VM prima di eseguire l'upgrade.

Puoi aggiornare la versione della build della patch del modello 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 applicazione patch di sicurezza.

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

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 di amministrazione
  • ADMIN_CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione

Accesso ai nodi Windows

Il modo standard per accedere ai nodi Windows è il nome utente e la password, che differiscono dai nodi Linux, che in genere sono accessibili 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 dell'utente del cluster di amministrazione. Il comando per recuperare la password dal secret è il seguente:

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. Passa alla VM a cui vuoi accedere, dove potrai trovare la password nella proprietà vApp password di quella VM.

Una volta che disponi del nome utente e della password, puoi accedere alla tua VM Windows utilizzando uno dei seguenti approcci:

Utilizzo del protocollo Remote Desktop Protocol

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

Utilizzo di SSH

Per aggiungere tramite SSH una VM Windows:

ssh Administrator@[VM_IP_ADDRESS]

Segui il prompt per digitare la password per connetterti alla VM.

Trasferimento di file da e verso la VM Windows

Puoi trasferire file da e verso la VM Windows tramite 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 trasferire file utilizzando Cloud Storage o RDP, come descritto in Trasferire file su VM Windows.

Risolvere i problemi

Impossibile usare SSH/RDP nella VM Windows

Per verificare se la VM ha una connessione di rete, esegui Test-NetConnection sulla console web di vCenter.

Il risultato deve 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 con la VM dalla tua workstation in cui vuoi eseguire SSH/RDP.

Verifica che kubelet, kube-proxy e flanneld siano in esecuzione sulla VM Windows.

Connettiti alla VM seguendo i passaggi riportati qui ed esegui i comandi seguenti:

# Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy
# Check that the flanneld process exists
Get-Process flanneld

Utilizzo dello strumento Snapshot

Usa lo strumento Snapshot per acquisire il tarball snapshot. Questo tarball contiene i file di log sui nodi, nonché gli output per la risoluzione dei problemi in esecuzione sui nodi.

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

La VM Windows è stata creata, ma il nodo non riesce ad avviarsi correttamente o a non essere visualizzato

  • Controlla i log di avvio sul nodo in C:\var\log\startup.log per verificare se ci sono stati problemi per l'avvio.

    • Se il flannel 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 kubelet in "C:\var\log".
    • Se kube-proxy non è in esecuzione, controlla i log kube-proxy in C:\var\log.

Logging e Monitoring

Cluster Anthos su VMware supporta il logging e il monitoraggio per i nodi e i pod Windows, come per i nodi e i pod Linux.

Durante la configurazione di logging e monitoraggio, il deployment degli agenti viene eseguito su nodi Windows. Questi agenti raccolgono, elaborano ed esportano i log e le metriche del nodo.

Agente di logging di Windows

L'agente Logging di Windows raccoglie i seguenti log:

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

    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 nodo: kubelet, kube-proxy e log eventi di Windows

Puoi accedere ai log utilizzando Esplora log nella console. Per ulteriori informazioni, consulta Log di accesso.

Agente di monitoraggio di Windows

L'agente di monitoraggio di Windows raccoglie un insieme di metriche di CPU e memoria diverse rispetto all'agente di monitoraggio di Linux. Per monitorare lo stato dei nodi e dei pod di Windows, utilizza le dashboard preparate. Nella console, seleziona Monitoring > Dashboards, quindi seleziona "Stato nodo Windows GKE on-prem" e "Stato pod Windows on-premise GKE" 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 di 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é l'StorageClass predefinito 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 Windows a tua scelta, ad esempio il driver CSI SMB.

Rilevatore di problemi sui nodi Windows

Il daemon Rilevatore di problemi di nodo è disponibile sui nodi Windows. Se hai eseguito l'upgrade alla versione 1.9, il rilevamento dei problemi dei nodi è abilitato automaticamente. La funzionalità di rilevamento dei problemi dei nodi consente di rilevare rapidamente alcuni problemi comuni dei nodi. La funzionalità di rilevamento dei problemi dei nodi verifica la presenza di possibili problemi e li segnala come eventi e condizioni sul nodo. Quando un nodo si comporta in modo anomalo, puoi usare il comando kubectl per trovare gli eventi e le condizioni corrispondenti.

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

Per ricevere eventi e condizioni su un nodo:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Sostituisci:

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

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

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

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Ogni volta che una delle condizioni viene 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 rilevamento dei problemi dei nodi 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 logging e monitoraggio sono abilitati, il log viene esportato in Cloud Logging e puoi visualizzarlo in Esplora log.

Utilizza questo filtro per visualizzare i log di Node Detect Detector 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 di patch di sicurezza

Oltre alle release regolari delle patch per le versioni di Anthos supportate, il team Anthos qualifica continuamente i nuovi aggiornamenti delle patch di Windows durante periodi di non release e pubblica i risultati per riferimento futuro. Se è necessario un aggiornamento urgente della patch di sicurezza tra le release delle patch Anthos, puoi creare un nuovo modello VM utilizzando la versione più recente, quindi eseguire un aggiornamento in sequenza per i pool di nodi Windows esistenti in modo da utilizzare il nuovo modello.

Il processo della 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 qualifica.
  • In caso di idoneità, 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 qui riportati.
    • Aggiorna i pool di nodi Windows per utilizzare il nuovo modello eseguendo questo comando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

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

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

Unione di domini Active Directory

L'unione di dominio di Active Directory richiede che il nome host della VM non superi i 15 caratteri. Per la modalità IPAM, dato che 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 si basano sulle istruzioni per creare pool di nodi Windows, con il passaggio aggiuntivo per fornire uno script personalizzato durante la creazione del modello VM di Windows.

Verifica che il server DNS del dominio attivo sia raggiungibile

Servizi di dominio di Active Directory (AD DS) utilizza i servizi di risoluzione dei nomi di 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 DS DS ha installato la foresta principale. Affinché una VM Windows si unisca al dominio AD, deve essere in grado di raggiungere il server DNS. Configura le configurazioni DNS e firewall seguendo le indicazioni del provider di servizi DNS in uso. 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. Eseguire uno script personalizzato prima che il nodo di Windows si unisca al cluster utente per l'unione di dominio di Active Directory. Archivia questo script in un percorso locale sulla tua workstation di amministrazione. Ricorda:

    • Puoi sostituire lo script con il tuo per l'unione del dominio Active Directory.
    • Ti consigliamo di utilizzare un account utente con le autorizzazioni minime necessarie per partecipare a un dominio Active Directory anziché un utente.
    • (Facoltativo) Per evitare di archiviare la password come testo chiaro in questo script, inseriscila in un file nel modello di VM, consenti allo script di leggere 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

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 la partecipazione del dominio attivo per i nodi Windows

Nella VM del controller di dominio AD, esegui il comando seguente:

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

Segui queste istruzioni: Configura DASHA per pod e container Windows. Puoi configurare CPEA per i pod e i container Windows dopo l'unione dei nodi.

Risolvere i problemi

I log per l'esecuzione personalizzata dello 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. - Crea un nuovo modello di VM Windows. - Aggiorna i pool di nodi Windows per utilizzare il nuovo modello eseguendo questo comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Configura il supporto dei container per i pool di nodi Windows (anteprima)

Il runtime containerd è ora disponibile come funzionalità di anteprima per i pool di nodi Windows. Il supporto per i runtime Docker verrà deprecato in una versione successiva.

Per abilitare containerd, assicurati di aver impostato enableWindowsDataplaneV2 su true in ogni file di configurazione dei 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

Ecco alcune differenze significative tra i container Windows e Linux:

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

Limitazioni per Cluster Anthos su VMware 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 i componenti aggiuntivi critici.

  • Poiché per i nodi Windows è 1,5 volte più risorse rispetto ai nodi Linux, le risorse allocabili di Windows sono inferiori.

  • L'uso dei nodi Windows potrebbe richiedere una dimensione minima per le macchine rispetto alle dimensioni minime per i cluster Anthos su VMware Linux. In genere i nodi Windows richiedono più risorse a causa del maggiore sovraccarico di esecuzione dei componenti/servizi dei nodi.

Problemi noti

Questa sezione elenca i problemi noti dei nodi Windows utilizzati con i cluster Anthos su VMware, insieme alle soluzioni alternative per evitare o recuperare da questi problemi.

I pod Windows non possono comunicare con indirizzi IP esterni

Il problema è descritto nella documentazione di Microsoft, in cui si afferma che "è necessario escludere dall'elenco di eccezioni l'IP esterno da cui si sta tentando di eseguire la query".

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

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

Si tratta di un problema noto per 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 deve essere mitigato. Da Cluster Anthos su VMware 1.9, la versione dell'immagine del container fluent-win-win e la versione Docker sono state aggiornate per rilevare le correzioni a monte per questo problema, questo non dovrebbe più riprodurre. Se riscontri questo problema, contatta l'assistenza di Google Cloud.

Nodi Windows con conflitti di indirizzi IP

Si tratta di un problema noto che si verifica molto raramente. Se riscontri questo problema durante la creazione del pool di nodi Windows, puoi mitigare questa situazione seguendo questa procedura:

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

  • Se utilizzi la modalità DHCP, è probabile che le VM appena create abbiano di nuovo indirizzi IP duplicati perché il server DHCP riscontra problemi per l'allocazione degli indirizzi IP. Per eliminare il pool di nodi Windows in attesa, esegui gkectl update cluster e aggiungilo di nuovo in user-cluster.yaml, esegui di nuovo gkectl update cluster per crearlo. Il pool di nodi appena creato dovrebbe avere allocazioni 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 lo riavvii, lo script di avvio non verrà eseguito di nuovo. L'esecuzione di alcuni servizi Windows verrà interrotta, inclusi kubelet, kube-proxy e così via. Di conseguenza, il nodo è in stato NotReady. Se utilizzi Windows Dataplane V2, è necessario eseguire anche la pulizia della rete obsoleta prima che i servizi Dataplane V2 possano essere riavviati e richiederà l'esecuzione di uno script per la pulizia, il che potrebbe causare complicazioni. Pertanto, 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

Impossibile preparare il modello VM sui cluster con un registro privato

Quando esegui gkectl prepare windows su cluster con un registro privato, l'operazione potrebbe non riuscire e restituire l'errore seguente:

Failed to prepare your Windows environment: failed to create Anthos Windows VM template: failed to setup Windows VM template: failed to preload docker container images: failed to run "powershell.exe Get-Content 'C:\ProgramData\docker\config\registry-key.json' | docker login --username="" --password-stdin """ on VM "": timed out waiting for the condition

Questo accade perché la VM Windows utilizzata durante il comando gkectl prepare windows non è stata aggiornata con il certificato radice del registro privato, quindi il comando docker login non riesce.

Ecco un paio di soluzioni:

  • Carica il file del certificato CA nel modello di VM di base prima di eseguire gkectl prepare windows. Il percorso del file deve essere C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt.

  • Esegui il comando gkectl prepare windows. Quando si verifica questo errore, connettiti con la VM SSH alla VM Windows e carica il file del certificato CA. Il percorso file deve essere C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt.