Anthos clusters on VMware ora è Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

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

Con Google Distributed Cloud, puoi creare un pool di nodi di sistemi operativi Windows Server. Il cluster utente che esegue i pool di nodi del sistema operativo Windows Server può eseguire anche pool di nodi contenenti nodi che utilizzano Ubuntu o Container-Optimized OS.

Requisiti per un pool di nodi del sistema operativo Windows Server

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

Prima di creare, nel cluster di utenti, 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, è 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, perché è 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. In questo modo, viene attivato Dataplane V2 sui nodi Linux del cluster.
Per impostazione predefinita, Windows Dataplane V2 è abilitato per i pool di nodi Windows per i nuovi cluster di utenti.
Hai scaricato un'immagine ISO di Windows Server 2019 da Microsoft per creare un modello VM specifico per i pool di nodi Windows. Il tag lingua/regione per l'ISO deve essere en-US.
L'ambiente vSphere deve essere vSphere 6.7, aggiornamento 3 o versioni successive.

Creare 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.

Crea un modello di VM Windows di base dall'immagine ISO di Windows Server 2019.
- Il tipo di adattatore di rete iniziale per la VM Windows su cui 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 dell'ISO di Windows, per utilizzarla in futuro.
- Assicurati di utilizzare la versione più recente della patch qualificata per Windows Server 2019. Consulta le nostre note di rilascio per scoprire la versione più recente dell'immagine del sistema operativo Windows qualificata per una determinata versione di Anthos. Consulta la Procedura per l'applicazione delle patch di sicurezza.
- Non puoi collegare alcun dispositivo che utilizza il controller IDE al modello VM di base.
Installa VMware Tools sul modello VM Windows di base, se non è già installato. Consulta la sezione Installare manualmente VMware Tools su Windows nella documentazione VMware.
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 VM Windows di base
- BUNDLE: il percorso del file del pacchetto Google Distributed Cloud
Nell'ambito della creazione del modello di VM Windows di base, gkectl prepare windows esegue Windows sysprep. In questo modo, il modello VM viene generalizzato e le impostazioni di rete della VM vengono ripulite, evitando così conflitti di indirizzi IP quando le VM vengono clonate dallo stesso modello. Tuttavia, Windows sysprep viene eseguito come un sistema chiuso, quindi è difficile gestire determinati errori di sysprep.

Se vuoi creare un modello di VM Windows di base senza eseguire Windowssysprep, includi --skip-sysprep nel comando gkectl prepare windows.
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 registry privato

Ometti questo passaggio se non utilizzi un registry privato.

Puoi automatizzare il caricamento delle immagini container di Windows in un registry privato utilizzando containerd su una workstation di amministrazione Linux. Tuttavia, containerd non può spingere il livello base dell'immagine container di Windows, il che significa che i livelli di base devono essere estratti dal registry di Microsoft durante il pull dell'immagine. Per inviare i livelli di base, segui i passaggi dell'opzione 2.

Opzione 1: se non devi eseguire manualmente il push delle immagini del livello di base di Windows nel registry 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 verranno eseguiti push delle immagini container Windows. Senza specificare questo flag, nel registry privato verranno inviate solo le immagini dei container Linux.

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

Prima di tentare questi passaggi, utilizza un computer Windows su cui è installato Docker e che ha accesso a gcr.io. Puoi estrarre le immagini container Windows solo su una macchina Windows.
Esegui docker login per autenticarti nel tuo registry privato.
Carica le immagini container Windows insieme ai relativi livelli di base nel tuo registry privato seguendo questa procedura:
- Vai al file Docker daemon.json sulla tua macchina Windows:
```
PS C:> cat C:\ProgramData\docker\config\daemon.json
```
- Aggiungi le seguenti righe per configurare il file Docker daemon.json in modo da consentire l'invio di livelli esterni al tuo registry privato:
```
{
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
```
- Scarica le immagini del contenitore Windows richieste sulla tua macchina Windows locale, quindi taggale ed eseguine il push nel tuo registry privato. Le modifiche apportate al file di configurazione Docker daemon.json consentono di eseguire il push del livello di base nel registry privato. Per completare queste attività, esegui i comandi seguenti:

# 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) Aggiungi gli URL alla 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

Per utilizzare i pool di nodi Windows, Dataplane V2 deve essere abilitato nel cluster utente. Aggiungi la seguente riga al file di configurazione del cluster utente per abilitare Dataplane V2:
```
enableDataplaneV2: true
```
Aggiungi un pool di nodi Windows alla sezione nodePools del file di configurazione del cluster utente. Oltre ai pool di nodi Windows, è necessario 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 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: 8
  memoryMB: 16384
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

Passaggio 5: crea pool di nodi Windows

Prima di creare pool di nodi Windows, esegui un elenco di convalidatori preflight per Windows. Ignora questo passaggio se hai già un cluster di utenti. (Facoltativo) Esegui uno o entrambi i controlli di preflight rapidi e lenti, che creano una VM di test per Windows e convalidano il modello 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 di utenti, alcuni controlli potrebbero non andare a buon fine. Ad esempio, gli indirizzi IP nel file hostconfig.yaml potrebbero essere già in uso dai nodi esistenti nel cluster utente.
Sebbene non sia consigliabile, puoi saltare i controlli preliminari di Windows con il flag --skip-validation-windows.
La gestione dei pool di nodi Windows è la stessa dei pool di nodi Linux. Consulta la Guida dell'utente per i pool di nodi del sistema operativo Windows Server. Anche i comandi per la creazione, l'aggiornamento e 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: convalida che i nodi Windows siano in esecuzione

Verifica che i nodi Windows siano stati creati e siano Ready.
```
kubectl --kubeconfig USER_KUBECONFIG get nodes 
```

Diagnostica il cluster di utenti per verificare che sia 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.

Questo danneggiamento garantisce che lo scheduler GKE non provi a 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, se lo trova, applica al carico di lavoro la seguente tolleranza che gli consente di essere eseguito sui nodi Windows Server compromessi:

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 il pod ha lo stato "In esecuzione".

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

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Risultato 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 per visualizzare la pagina web di IIS.

Eseguire l'upgrade del cluster utente con pool di nodi Windows

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

Puoi aggiornare la versione della build della patch del modello VM di base durante l'upgrade scaricando una versione della patch di Windows Server 2019 più recente da Microsoft come patch di sicurezza. Consulta la Procedura per l'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 nome del nuovo modello 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 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 è con un nome utente e una password, diversamente 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 memorizzata nel secret windows-node-password nello spazio dei nomi utente del cluster di amministrazione. Il comando per recuperare la password dal segreto è:

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

Puoi anche recuperare la password utilizzando l'interfaccia utente di vCenter. Vai alla VM a cui vuoi accedere e trova la password nella proprietà vApp password della VM.

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

Utilizzo del protocollo Remote Desktop

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

Utilizzo di SSH

Per connetterti tramite SSH a una VM Windows:

ssh Administrator@[VM_IP_ADDRESS]

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

Trasferimento di file da e verso la VM Windows

Puoi trasferire file dalla e verso la 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 anche trasferire i file utilizzando Cloud Storage o RDP, come descritto in Trasferimento di file nelle VM Windows.

Aggiornamento della configurazione di Windows Server

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

Docker e Flannel per i nodi Windows verranno ritirati in una release successiva. Ti consigliamo di aggiornare subito la configurazione, se applicabile, per utilizzare containerd e Windows Dataplane V2. Consulta Aggiornare 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 di vCenter.

Il risultato deve contenere PingSucceeded: true se è presente una connessione di rete. Se la VM non ha una connessione di rete, controlla l'adattatore di rete utilizzato 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 questi passaggi ed esegui i comandi seguenti, a seconda della configurazione:

Per tutte le configurazioni, esegui questi comandi:

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

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
```
In caso contrario, verifica che il processo flanneld sia "In esecuzione":
```
# Check that the flanneld process exists
Get-Process flanneld
```

Utilizzo dello strumento di istantanea

Utilizza lo strumento di snapshot per acquisire il file tarball dello snapshot. Questo file tarball contiene i file di log sui nodi e gli output per i comandi per la risoluzione dei problemi 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 contenitore 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 VM si trovi nello stesso data center e nello stesso 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 all'indirizzo C:\var\log\startup.log per verificare se l'avvio non è riuscito.
- Se flanneld non è in esecuzione, prova a eseguire di nuovo lo script di avvio 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.
Controlla se cloudbase-init ha già eseguito UserDataPlugin prima di eseguire lo script di avvio.

Per verificare, effettua 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à il salto dell'esecuzione dello script di avvio e il bootstrap del nodo Windows non verrà eseguito.

Questo problema è solitamente causato dalla conversione del modello VM generato da gkectl prepare windows in una VM e dalla sua attivazione.

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

Logging e monitoraggio

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

Quando il logging e il monitoraggio sono configurati, gli agenti vengono dipartiti sui nodi Windows. Questi agenti raccolgono, elaborano ed esportano i log e le metriche del nodo.

Agente di logging di Windows

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

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

Tieni presente che i log dei workload delle applicazioni utente di Windows vengono raccolti per impostazione predefinita. Per disattivare i log dell'applicazione:

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 in 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 del nodo: log degli eventi di kubelet, kube-proxy e 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 diverso di metriche relative all'utilizzo della CPU e della memoria rispetto all'agente di monitoraggio di Linux. Per monitorare lo stato dei nodi e dei pod Windows, utilizza le dashboard preparate. Nella console, seleziona Monitoraggio > Dashboard e poi "Stato del nodo Windows GKE on-premise" e "Stato del pod Windows GKE on-premise" dall'elenco Tutte le dashboard.

Queste dashboard vengono create automaticamente durante l'installazione del cluster amministrativo 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 di Windows

Quando utilizzi i 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 di utenti 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 disegnato automaticamente sui nodi Windows. Puoi installare e utilizzare un driver CSI Windows a tua scelta, come il driver SMB CSI.

Node Problem Detector sui nodi Windows

Il demone 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 consente di rilevare rapidamente alcuni problemi comuni dei nodi. Il rilevatore problemi nodo continua a controllare la presenza di possibili problemi e li segnala come eventi e condizioni sul nodo. Quando un nodo si comporta in modo anomalo, puoi utilizzare il comando kubectl per trovare gli eventi e le condizioni corrispondenti.

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

Per ottenere eventi e condizioni in un nodo:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Sostituisci:

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

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

Il Node Problem Detector monitora anche le seguenti condizioni sul nodo. Ognuno di questi è impostato 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 di disponibilità del nodo diventa false, impedendo la pianificazione di nuovi pod sul nodo.

Quando viene rilevata una condizione non corretta, 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 il logging e il 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 regolari delle patch per le versioni Anthos supportate, il team di Anthos convalida continuamente gli aggiornamenti delle patch di Windows più recenti durante i periodi di tempo in cui non sono disponibili 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 VM utilizzando la versione più recente, quindi eseguire un aggiornamento graduale per i pool di nodi Windows esistenti in modo che utilizzino il nuovo modello.

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

Microsoft rilascia una nuova patch di sicurezza per Windows Server 2019.
Anthos convalida la versione più recente della patch di sicurezza e annuncia il risultato della convalida.
Se idonei, gli utenti potranno:
- Scarica la versione più recente della patch da Microsoft
- Crea un nuovo modello 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 la prossima release mensile delle patch di Anthos ed eseguire l'upgrade dei cluster.
Se la nuova versione di Windows non è compatibile con Anthos, il team di Anthos la ignorerà e attenderà il prossimo aggiornamento della sicurezza di Microsoft.

Join 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 sulle istruzioni per la creazione di pool di nodi Windows, con il passaggio aggiuntivo di fornire uno script personalizzato durante la compilazione del modello VM Windows.

Verifica che il server DNS del dominio attivo sia raggiungibile

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

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

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

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

Esegui uno script personalizzato prima che il nodo Windows si unisca al cluster di utenti per l'unione al dominio Active Directory. Salva questo script in un percorso locale sulla tua workstation di amministrazione. Ricorda:
- Puoi sostituire lo script con il tuo script per l'unione al dominio Active Directory.
- Ti consigliamo di utilizzare un account utente con le autorizzazioni minime richieste per l'unione a un dominio Active Directory anziché un utente amministratore.
- (Facoltativo) Per evitare di memorizzare la password in testo normale in questo script, inseriscila in un file nel modello VM, consenti allo script di leggerla da quel file e poi elimina il file dopo l'unione al dominio.
```
$domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force
```

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 descritte nei passaggi 2-6 per creare un pool di nodi Windows utilizzando il modello VM Windows personalizzato.

Passaggio 3: verifica l'unione al dominio Active per i nodi Windows

Nella VM del controller di dominio AD, esegui il seguente 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 di gruppo

Segui queste istruzioni: Configurare GMSA per pod e contenitori Windows. Puoi configurare GMSA per i pod e i contenitori 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 per utilizzare il nuovo modello eseguendo:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Considerazioni per i 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: major, minor, build e revision.
- L'immagine di base del contenitore 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 le immagini di base dell'host sia quelle del contenitore.
- Gli utenti devono ricostruire le immagini dei 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 dispiegando contenitori, ad esempio i daemonset.

Limitazioni per Google Distributed Cloud su Windows vSphere

I cluster di utenti devono contenere almeno un pool di nodi Linux.
- Non puoi creare un cluster con un solo 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, le risorse allocabili per Windows sono inferiori.
L'utilizzo di nodi Windows potrebbe richiedere dimensioni minime della macchina maggiori rispetto a quelle minime di Google Distributed Cloud Linux. I nodi Windows in genere richiedono più risorse a causa dell'overhead maggiore dei componenti/servizi del nodo in esecuzione.

Problemi noti

Questa sezione elenca i problemi noti relativi ai nodi Windows utilizzati con Google Distributed Cloud, nonché le soluzioni alternative per evitarli o recuperarli.

I pod Windows non possono comunicare con indirizzi IP esterni

Questo problema è descritto nella documentazione di Microsoft, che afferma: "Devi escludere l'IP esterno per cui stai tentando di eseguire una query dall'elenco 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 anche di chiamare CreateFile su Windows. Come soluzione alternativa, accedi al nodo Windows con il problema, esegui Restart-Service docker e il problema dovrebbe essere attenuato. 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 acquisire le correzioni a monte per questo problema, che non dovrebbe più verificarsi. 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 attenuarlo seguendo questi passaggi:

Se utilizzi la modalità IPAM, puoi rimuovere manualmente le VM con conflitti IP da vCenter. Verranno create automaticamente nuove VM con allocazioni IP corrette. In alternativa, puoi semplicemente attendere che la riparazione automatica dei nodi rilevi il problema e ricrei i nodi Windows.
Se utilizzi la modalità DHCP, è probabile che le VM appena create abbiano nuovamente IP duplicati poiché il server DHCP sta riscontrando problemi di allocazione degli IP. Puoi eliminare il pool di nodi Windows in attesa eseguendo gkectl update cluster, aggiungerlo di nuovo in user-cluster.yaml, eseguire 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 la prima volta che la VM viene accesa, quindi se la riavvii, lo script di avvio non viene eseguito di nuovo. Ciò causerà l'interruzione dell'esecuzione di alcuni servizi Windows, tra cui kubelet, i servizi kube-proxy e così via. Di conseguenza, il nodo è in stato NotReady. Se utilizzi Windows Dataplane 2, è necessario ripulire anche la rete obsoleta prima che i servizi Dataplane 2 possano essere riavviati e sarà necessario eseguire uno script per la pulizia, il che potrebbe causare complicazioni. Pertanto, crea nuovamente 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 diagnosi non riesce quando le versioni hardware delle VM Windows sono inferiori a quanto previsto

Quando il modello VM Windows utilizza una versione hardware precedente, il comando gkectl diagnose cluster non va a buon fine con 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:

Rinomina il modello VM attualmente in uso.

Questo è necessario per poter creare un nuovo modello VM nei passaggi successivi.
Converti il modello VM di base Windows in una VM.
Segui i passaggi descritti in Eseguire l'upgrade di una macchina virtuale alla versione hardware più recente per eseguire l'upgrade della versione hardware della VM.
Ripristina la VM in un modello VM.
Esegui il seguente comando per preparare un nuovo modello VM, utilizzando il modello VM di cui è stato eseguito l'upgrade nei passaggi precedenti come modello VM di base.
```
gkectl prepare windows
```
Il nome del nuovo modello VM generato deve corrispondere al valore del campo pool di nodi WindowsosImage 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 nome del nuovo modello VM generato ed esegui il seguente comando:
```
gkectl update cluster
```
Ricrea il nodo Windows eseguendo il seguente comando:
```
kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
```
Attendi che il controller ricrei automaticamente il nodo.