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ò eseguire anche pool di nodi che contengono nodi che utilizzano Ubuntu o Container-Optimized OS.

Requisiti per un pool di nodi del sistema operativo Windows Server

Tutti i nodi di un pool di nodi devono utilizzare 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:

  • Prima di poter creare un pool di nodi Windows, deve essere 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, perché è necessario per creare un pool di nodi Windows.
  • Un cluster utente con node pool Windows deve avere il campo enabledataplanev2 impostato su true nel file di configurazione del cluster utente. In questo modo viene abilitato Dataplane V2 sui nodi Linux del 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 lingua/regione per ISO deve essere en-US.

  • Il tuo ambiente vSphere deve essere vSphere 6.7, Update 3 o versioni successive.

  • I pool di nodi del sistema operativo Windows Server presentano le seguenti limitazioni:

    • IPv6 non è supportato.
    • I node pool Windows non sono supportati nei cluster avanzati.

Crea un pool di nodi Windows in un cluster utente

Passaggio 1: crea il modello di VM Windows per Google Distributed Cloud

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

  1. Crea 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 l'ISO di Windows Server 2019 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 patch qualificata più recente per Windows Server 2019. Consulta le nostre note di rilascio per scoprire la versione più recente dell'immagine del sistema operativo Windows qualificata per una determinata versione di Anthos. Consulta Procedura di applicazione delle 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 Windows di base, se non è già installato. Consulta Installare manualmente VMware Tools su Windows nella documentazione 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 Google Distributed Cloud

    Nell'ambito della creazione del modello di VM Windows di base, gkectl prepare windows viene eseguito Windows sysprep. In questo modo, il modello di VM viene generalizzato e le impostazioni di rete della VM vengono pulite, contribuendo così a evitare conflitti di indirizzi IP quando le VM vengono clonate dallo stesso modello. Tuttavia, Windows sysprep viene eseguito come una scatola chiusa, quindi è difficile gestire determinati 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 del comando, puoi trovare il nome del modello 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 utilizzi un registro privato.

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

Opzione 1: se non devi eseguire il push manuale delle immagini del livello di 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 container Windows. Solo le immagini container Linux verranno inviate al registro privato senza specificare questo flag.

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

  • Prima di tentare questi passaggi, utilizza un computer Windows con Docker installato e con accesso a gcr.io. Puoi eseguire il pull delle immagini container Windows solo su una macchina Windows.
  • Esegui docker login per autenticarti nel tuo registro privato.

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

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

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

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

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Scarica le immagini container Windows richieste sulla tua macchina Windows locale, quindi taggale ed esegui il push nel tuo registro privato. Le modifiche apportate al file di configurazione Docker daemon.json significano che il livello di base può essere inviato al registro privato. Per completare queste attività, esegui i seguenti 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) 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 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 del 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 i 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 che il tipo di immagine sistema operativo deve essere windows.
# 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 i pool di nodi Windows

Prima di creare pool di nodi Windows, esegui un elenco di validator preflight per Windows. Salta questo passaggio se hai già un cluster utente. (Facoltativo) Esegui uno o entrambi i controlli preliminari 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 deve essere eseguito prima di creare un cluster utente. Se hai già un cluster utente, alcuni controlli potrebbero non andare a buon fine. Ad esempio, gli indirizzi IP nel file hostconfig.yaml potrebbero essere già in uso da nodi esistenti nel cluster utente.
  • Sebbene non sia consigliabile, puoi ignorare i controlli preliminari di Windows con il flag --skip-validation-windows.
  • La gestione dei node pool Windows è la stessa dei node pool Linux. Consulta la Guida dell'utente per i pool di nodi del sistema operativo Windows Server. Anche i comandi per creare, aggiornare ed eseguire l'upgrade di cluster e node pool 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 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 contaminati con questa coppia chiave-valore: node.kubernetes.io/os=windows:NoSchedule.

Questa contaminazione garantisce che lo scheduler GKE non tenti di eseguire container Linux sui nodi Windows Server. Per pianificare i contenitori 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 la presenza di questo selettore di nodi Windows nei nuovi carichi di lavoro e, quando lo trova, applica la seguente tolleranza al carico di lavoro, che gli consente di essere eseguito sui nodi Windows Server contaminati:

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 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 che l'output restituito mostri 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 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 IIS.

Esegui l'upgrade del cluster utente con i node pool Windows

La procedura di upgrade per un cluster utente con pool di nodi Windows è simile a quella per l'upgrade dei cluster utente solo Linux, tranne per il fatto che devi creare un modello di VM Windows da un modello di VM di base prima dell'upgrade.

Puoi aggiornare la versione di build della patch del modello VM di base durante l'upgrade scaricando una versione della patch più recente di Windows Server 2019 da Microsoft come patch di sicurezza. Consulta Procedura di applicazione delle 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 riportato di seguito per 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 modo standard per accedere ai nodi Windows è con un nome utente e una password, che differiscono dai nodi Linux, a cui in genere si accede 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 dal 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 vCenter. Vai alla VM a cui vuoi accedere, quindi puoi trovare la password nella proprietà vApp password di quella VM.

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

Utilizzo di Remote Desktop Protocol

Poiché RDP è stato abilitato durante la creazione 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 tua VM Windows

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

Carica i file nella 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 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 ritirati in una release successiva. Se applicabile, ti consigliamo di aggiornare subito la configurazione per utilizzare containerd e Windows Dataplane V2. Consulta Aggiorna la configurazione di Windows Server.

Impossibile connettersi tramite SSH/RDP alla VM Windows

Verifica se la VM ha una connessione di rete eseguendo Test-NetConnection nella console web 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 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 i passaggi descritti qui ed esegui i seguenti comandi, 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 il cluster è configurato con windowsDataplaneV2 impostato su true, verifica che i servizi antrea-agent, ovsdb-server e ovs-vswitchd siano "Running" (In esecuzione).

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

  3. In caso contrario, verifica che il processo flanneld sia "Running":

    # Check that the flanneld process exists
Get-Process flanneld

Utilizzare lo strumento di snapshot

Utilizza lo strumento di snapshot per recuperare il tarball dello snapshot. Questo tarball contiene i file di log sui nodi, nonché gli output per la risoluzione dei problemi dei 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 modello di VM si trovi nello stesso data center e datastore specificati 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 che si trova in C:\var\log\startup.log per vedere se l'avvio di qualche elemento non è riuscito.

    • Se flanneld non è in esecuzione, prova a eseguire di nuovo lo script di avvio che si trova in 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.

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

Per verificarlo, ottieni una connessione SSH alla VM Windows ed esegui il seguente comando:

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

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

Ciò è in genere causato dalla conversione del modello di VM generato da gkectl prepare windows in una VM e dalla sua accensione.

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

Logging e monitoraggio

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

Quando il logging e il monitoraggio sono configurati, gli agenti vengono implementati 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 di sistema e delle applicazioni utente.

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

    • Modifica il 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.(?<podname>[a-z0-9](?:[-a-z0-9][a-z0-9])?(?:.[a-z0-9]([-a-z0-9][a-z0-9])?)*)(?<namespacename>[^]+)_(?<container_name>.+)-(?<docker_id>[a-z0-9]{64}).log$
#      Tag                k8s_container.<namespace_name>.<pod_name>.<container_name>
#      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 la sezione Log di accesso.

Agente Monitoring Windows

L'agente Monitoring per Windows raccoglie un insieme diverso di metriche di utilizzo di CPU e memoria rispetto all'agente Monitoring per Linux. Per monitorare lo stato dei nodi e dei pod Windows, utilizza le dashboard preparate. Dalla console, seleziona Monitoraggio > Dashboard, poi seleziona "Stato nodo Windows 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 questi 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 spazio di archiviazione permanente, devi creare un oggetto StorageClass e specificarne il nome nel campo storageClassName dell'oggetto PersistentVolumeClaim, perché l'oggetto StorageClass predefinito nel cluster utente on-premise 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 proxy CSI viene implementato automaticamente sui nodi Windows. Puoi installare e utilizzare un driver CSI Windows a tua scelta, ad esempio il driver SMB CSI.

Rilevatore problemi nodo sui nodi Windows

Il daemon Node Problem Detector è disponibile sui nodi Windows. Se hai eseguito l'upgrade alla versione 1.9, Node Problem Detector viene attivato automaticamente. Node Problem Detector aiuta a rilevare rapidamente alcuni problemi comuni dei nodi. Node Problem Detector continua a verificare la presenza di possibili problemi e li segnala come eventi e condizioni sul nodo. Quando un nodo non funziona correttamente, puoi utilizzare il comando kubectl per trovare eventi e condizioni corrispondenti.

Per Node Problem Detector sono abilitate le seguenti configurazioni di monitoraggio:

Per visualizzare gli eventi e le condizioni di 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 Node Problem Detector, cerca il nome del monitor nel campo reason di una regola specificata nella sezione rules.

I monitor di Node Problem Detector generano anche le seguenti condizioni sul nodo. Ciascuno di questi valori è impostato su true se Node Problem Detector rileva lo scenario di errore corrispondente sul nodo.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

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

Quando viene rilevata una condizione di integrità non ottimale, Node Problem Detector tenta di riparare automaticamente il nodo riavviando il servizio di sistema pertinente.

I log di Node Problem Detector si trovano nella cartella C:\var\log\node-problem-detector del nodo. Se logging e monitoraggio sono attivati, il log viene esportato in Cloud Logging e puoi visualizzarlo in Esplora log.

Utilizza questo filtro per ottenere i log di Node Problem 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.

Procedura di applicazione delle patch di sicurezza

Oltre alle release di patch regolari per le versioni di Anthos supportate, il team di Anthos qualifica continuamente gli aggiornamenti delle patch di Windows più recenti durante i periodi non di rilascio e pubblica i risultati come riferimento. Se è necessario un aggiornamento urgente della patch di sicurezza tra le release delle patch 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 che utilizzino il nuovo modello.

La procedura di applicazione delle patch di sicurezza include i seguenti passaggi:

  • Microsoft rilascia una nuova patch di sicurezza per Windows Server 2019.
  • Anthos qualifica l'ultima versione della patch di sicurezza e annuncia il risultato della qualifica.
  • Se idonei, gli utenti:
    • Scarica l'ultima versione della patch da Microsoft
    • Crea un nuovo modello di VM Windows utilizzando questa versione della patch seguendo i passaggi descritti 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 di Anthos successiva 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 successivo aggiornamento della sicurezza di Microsoft.

Unione 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 <= 15 caratteri. Queste istruzioni si basano su quelle per la creazione di node pool Windows, con il passaggio aggiuntivo di fornire uno script personalizzato durante la creazione del modello di 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 domain controller e ai domain controller che ospitano il servizio di directory di comunicare tra loro.

Il server DNS è stato creato quando il ruolo AD DS ha installato la foresta radice. Affinché qualsiasi VM Windows possa unirsi al dominio AD, deve essere in grado di raggiungere il server DNS. Configura le configurazioni DNS e firewall seguendo le indicazioni del fornitore di servizi DNS che utilizzi. Puoi verificare se le VM Windows nella rete corrente 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 entri a far parte del cluster utente per l'aggiunta al dominio Active Directory. Archivia questo script in un percorso locale sulla workstation amministrativa. Ricorda:

    • Puoi sostituire lo script con il tuo per eseguire l'unione al dominio Active Directory.
    • Ti consigliamo di utilizzare un account utente con le autorizzazioni minime richieste per l'aggiunta a un dominio Active Directory, anziché utilizzare un utente amministratore.
    • (Facoltativo) Per evitare di archiviare la password come testo non crittografato in questo script, inseriscila in un file sul modello VM, consenti allo script di leggere da quel file di password, quindi elimina il file dopo l'aggiunta 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 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 VM Windows personalizzato.

Passaggio 3: verifica l'unione al 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 di gruppo (facoltativo)

Segui queste istruzioni: Configurare GMSA per pod e container Windows. Puoi configurare GMSA per i pod e i container Windows dopo che i nodi sono stati aggiunti 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. - Crea 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

Considerazioni sui container Windows

Alcune differenze significative tra i container Windows e Linux sono:

  • 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: principale, secondaria, build e revisione.
    • L'immagine di base del container del server Windows deve corrispondere alle prime tre parti della tupla della versione dell'immagine del sistema operativo host. La revisione non deve corrispondere, anche se è consigliabile aggiornare sia l'host sia le immagini di base del container.
    • Gli utenti devono ricompilare le immagini container ogni volta che cambia la versione dell'immagine del sistema operativo
  • I container privilegiati e gli spazi dei nomi host non sono supportati.
    • Gli utenti non possono configurare/modificare i nodi eseguendo il deployment di container, ad esempio 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 un solo pool di nodi Windows
    • I node pool Linux sono necessari per eseguire componenti aggiuntivi critici.

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

  • L'utilizzo di nodi Windows potrebbe richiedere una dimensione minima della macchina maggiore rispetto alla dimensione minima della macchina Google Distributed Cloud Linux. I nodi Windows in genere richiedono più risorse a causa dell'overhead maggiore per l'esecuzione di componenti/servizi del nodo.

Problemi noti

Questa sezione elenca i problemi noti relativi ai nodi Windows utilizzati con Google Distributed Cloud, insieme alle soluzioni alternative per evitare o risolvere questi problemi.

I pod Windows non possono comunicare con indirizzi IP esterni

Questo problema è descritto nella documentazione di Microsoft, che afferma: "Devi escludere l'IP esterno che stai cercando di interrogare da ExceptionList".

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, in cui docker RemoveContainer tenta di chiamare anche CreateFile su Windows. Come soluzione alternativa, accedi al nodo Windows che presenta il problema, esegui Restart-Service docker e il problema dovrebbe essere risolto. A partire da Google Distributed Cloud 1.9, la versione dell'immagine container fluent-bit-win e la versione di Docker sono state aggiornate per includere le correzioni upstream per questo problema, che non dovrebbe più ripresentarsi. 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 riscontri durante la creazione del pool di nodi Windows, puoi risolverlo seguendo questi passaggi:

  • Se utilizzi la modalità IPAM, puoi rimuovere manualmente da vCenter le VM che presentano conflitti IP. Verranno create automaticamente nuove VM che dovrebbero avere allocazioni IP corrette. In alternativa, puoi semplicemente attendere che la riparazione automatica dei nodi rilevi questo problema e ricrei 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 per l'allocazione IP. Puoi eliminare il pool di nodi Windows in attesa eseguendo gkectl update cluster e aggiungerlo di nuovo in user-cluster.yaml. Esegui di nuovo gkectl update cluster per crearlo. Il pool di nodi appena creato dovrebbe avere allocazioni IP corrette.

Il nodo Windows diventa NotReady dopo il riavvio della VM

Al momento, lo script di avvio del nodo viene eseguito solo al primo avvio della VM, quindi se riavvii la VM, lo script di avvio non viene eseguito di nuovo. In questo modo, alcuni servizi Windows smetteranno di essere eseguiti, inclusi i servizi kubelet, kube-proxy e così via. In questo modo, il nodo si trova nello stato NotReady. Se utilizzi Windows Dataplane V2, è necessario pulire anche la rete obsoleta prima che i servizi Dataplane V2 possano riavviarsi e sarà necessario eseguire uno script per la pulizia, il che potrebbe causare complicazioni. Pertanto, ricrea il nodo. Come soluzione alternativa, puoi eliminare il nodo eseguendo il comando riportato di seguito e attendere che il controller lo ricrei automaticamente.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Il comando di diagnostica non riesce quando le versioni hardware della 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, segui questi passaggi:

  1. Rinomina il modello di VM attualmente in uso.

    Questo passaggio è necessario per poter creare un nuovo modello di VM nei passaggi successivi.

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

  3. Segui i passaggi descritti in Eseguire l'upgrade di una macchina virtuale all'ultima versione hardware per eseguire l'upgrade della versione hardware della VM.

  4. Converti di nuovo la VM in un modello di VM.

  5. Esegui il comando seguente 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 di osImage in modo che corrisponda al nuovo nome del modello di VM generato ed esegui il seguente 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.