Questa pagina è stata tradotta dall'API Cloud Translation.

Creazione di un cluster mediante i pool di nodi di Windows Server

Standard

In questa pagina scoprirai come creare un cluster Google Kubernetes Engine (GKE) con pool di nodi che eseguono Microsoft Windows Server. Con questo cluster puoi utilizzare i contenitori Windows Server. I contenitori Microsoft Hyper-V non sono attualmente supportati. Come i container Linux, i container Windows Server forniscono isolamento di processi e spazi dei nomi.

Un nodo Windows Server richiede più risorse di un tipico nodo Linux. I nodi Windows Server richiedono risorse aggiuntive per eseguire il sistema operativo Windows e per i componenti di Windows Server che non possono essere eseguiti in container. Poiché i nodi Windows Server richiedono più risorse, le risorse allocabili sono inferiori rispetto a quelle dei nodi Linux.

Creazione di un cluster mediante i pool di nodi di Windows Server

In questa sezione crei un cluster che utilizza un contenitore Windows Server.

Per creare questo cluster, devi completare le seguenti attività:

Scegli l'immagine del nodo Windows Server.
Aggiorna e configura gcloud.
Crea un cluster e pool di nodi.
Ottieni le credenziali kubectl.
Attendi l'inizializzazione del cluster.

Configurare gli account di servizio IAM per GKE

GKE utilizza service account IAM collegati ai tuoi nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi account di servizio dei nodi devono avere il ruolo Account di servizio dei nodi predefinito di Kubernetes Engine (roles/container.defaultNodeServiceAccount) nel progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, creato automaticamente nel progetto, come account di servizio del nodo.

Per concedere il ruolo roles/container.defaultNodeServiceAccount all'account di servizio predefinito di Compute Engine, completa i seguenti passaggi:

console

Vai alla pagina Welcome (Ti diamo il benvenuto):
Vai a Benvenuto
Nel campo Numero progetto, fai clic su Copia negli appunti.
Vai alla pagina IAM:
Vai a IAM
Fai clic su Concedi accesso.
Nel campo Nuove entità, specifica il seguente valore:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Sostituisci PROJECT_NUMBER con il numero del progetto che hai copiato.
Nel menu Seleziona un ruolo, seleziona il ruolo Account di servizio del nodo predefinito Kubernetes Engine.
Fai clic su Salva.

gcloud

Trova il numero del tuo progetto Google Cloud:
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Sostituisci PROJECT_ID con l'ID progetto.

L'output è simile al seguente:
```
12345678901
```

Concedi il ruolo roles/container.defaultNodeServiceAccount all'account di servizio predefinito Compute Engine:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

Sostituisci PROJECT_NUMBER con il numero del progetto del passaggio precedente.

Scegli l'immagine del nodo Windows Server

Per essere eseguite su GKE, le immagini dei nodi dei container di Windows Server devono essere create su Windows Server versione 2019 (LTSC), Windows Server versione 20H2 (SAC) o Windows Server versione 2022 (LTSC). Un singolo cluster può avere più pool di nodi Windows Server che utilizzano versioni diverse di Windows Server, ma ogni singolo pool di nodi può utilizzare una sola versione di Windows Server.

Quando scegli l'immagine del nodo, tieni presente quanto segue:

Tempistiche di assistenza:
- Le tempistiche di assistenza per un'immagine del nodo Windows Server sono soggette alle tempistiche di assistenza fornite da Microsoft, come descritto nei Criteri di assistenza per le immagini del sistema operativo. Puoi trovare la data di fine del supporto per le immagini dei nodi GKE Windows utilizzando il comando gcloud container get-server-config come descritto nella sezione Mappare le versioni GKE e Windows.
- Le versioni SAC sono supportate da Microsoft solo per 18 mesi dopo la loro rilaciazione iniziale. Se scegli SAC per il tipo di immagine del tuo pool di nodi, ma non esegui l'upgrade del pool di nodi a versioni GKE più recenti che hanno come target versioni SAC più recenti, non puoi creare nuovi nodi nel node pool al termine del ciclo di vita del supporto per la versione SAC. Scopri di più sul supporto di Google per il sistema operativo Windows Server. Consigliamo di utilizzare LTSC per il suo ciclo di vita di supporto più lungo.
- Non scegliere SAC se registri il tuo cluster GKE nel canale di rilascio stabile. Poiché le versioni SAC sono supportate da Microsoft solo per 18 mesi, esiste il rischio che l'immagine del pool di nodi SAC non sia più supportata mentre la versione GKE stabile è ancora disponibile.
Compatibilità e complessità delle versioni:
- Scegli SAC solo se puoi eseguire l'upgrade del tuo node pool e dei contenitori in esecuzione al suo interno regolarmente. GKE aggiorna periodicamente la versione di SAC utilizzata per i node pool Windows nelle nuove release di GKE, pertanto la scelta di SAC per il tipo di immagine del pool di nodi richiede di ricostruire i container più spesso.
- Se non sai quale tipo di immagine Windows Server utilizzare, ti consigliamo di scegliere Windows Server LTSC per evitare problemi di incompatibilità delle versioni durante l'upgrade del pool di nodi. Per ulteriori informazioni, consulta Canali di assistenza di Windows Server: LTSC e SAC nella documentazione di Microsoft.
- Sia Windows Server Core che Nano Server possono essere utilizzati come immagine di base per i container.
- I container Windows Server hanno requisiti importanti di compatibilità delle versioni:
  - I container Windows Server creati per LTSC non vengono eseguiti sui nodi SAC e viceversa.
  - I container Windows Server creati per una versione LTSC o SAC specifica non vengono eseguiti su altre versioni LTSC o SAC senza essere ricostruiti in modo da avere come target l'altra versione.
- La creazione di immagini dei container di Windows Server come immagini multi-arch che possono avere come target più versioni di Windows Server può aiutarti a gestire questa complicazione del versionamento.
Nuove funzionalità:
- In genere, le nuove funzionalità di Windows Server vengono introdotte prima nelle versioni SAC. Per questo motivo, le nuove funzionalità di GKE Windows potrebbero essere introdotte inizialmente nei node pool SAC.
- Valuta la possibilità di utilizzare il SAC se hai bisogno di funzionalità non ancora disponibili nella release LTSC.
Runtime del contenitore:
- Sia per le immagini dei nodi Windows Server LTSC che per quelle SAC, il runtime del container può essere Docker o containerd. Per la versione del nodo GKE 1.21.1-gke.2200 e successive, consigliamo di utilizzare il runtime containerd. Per maggiori informazioni, consulta Immagini dei nodi.
  
  Avviso: nella versione 1.24 e successive di GKE, i tipi di immagini dei nodi basate su Docker non sono supportati. Nella versione 1.23 di GKE, non puoi nemmeno creare nuovi node pool con tipi di immagini dei nodi Docker. Devi eseguire la migrazione a un tipo di immagine del nodo containerd. Per approfondire questa modifica, consulta Informazioni sulla deprecazione delle immagini dei nodi Docker.

Aggiorna e configura `gcloud`

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Assicurati di disporre dell'autorizzazione corretta per creare cluster. Come minimo, devi avere il ruolo Amministratore cluster Kubernetes Engine.

Crea un cluster e pool di nodi

Per eseguire i contenitori Windows Server, il cluster deve avere almeno un pool di nodi Windows e uno Linux. Non puoi creare un cluster utilizzando solo un pool di nodi Windows Server. Il pool di nodi Linux è necessario per eseguire componenti aggiuntivi critici del cluster.

Data la sua importanza, ti consigliamo di attivare la scalabilità automatica per assicurarti che il pool di nodi Linux abbia una capacità sufficiente per eseguire i componenti aggiuntivi del cluster.

gcloud

Crea un cluster con i seguenti campi:

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

Sostituisci quanto segue:

CLUSTER_NAME: il nome scelto per il cluster.
--enable-ip-alias attiva l'IP alias. L'IP alias è obbligatorio per i nodi Windows Server. Per scoprire di più sui vantaggi, consulta Informazioni sul routing dei contenitori nativi con gli IP alias.
NUMBER_OF_NODES: il numero di nodi Linux che crei. Devi fornire risorse di calcolo sufficienti per eseguire i componenti aggiuntivi del cluster. Questo è un campo facoltativo e, se omesso, viene utilizzato il valore predefinito 3.
VERSION_NUMBER: la versione specifica del cluster che vuoi utilizzare, che deve essere 1.16.8-gke.9 o successiva. Se non specifichi un canale di rilascio, GKE registra il tuo cluster nel canale di rilascio più maturo in cui è disponibile la versione.
CHANNEL: il canale di rilascio in cui registrare il cluster, che può essere rapid, regular, stable o None. Per impostazione predefinita, il cluster è registrato nel canale di rilascio regular, a meno che non venga specificato almeno uno dei seguenti flag: --cluster-version, --release-channel, --no-enable-autoupgrade e --no-enable-autorepair. Devi specificare None se scegli una versione del cluster e non vuoi che il tuo cluster venga registrato in un canale di rilascio.

Ti consigliamo vivamente di specificare un account di servizio IAM con privilegi minimi che i tuoi nodi possano utilizzare al posto dell'account di servizio predefinito di Compute Engine. Per imparare a creare un account di servizio con privilegi minimi, consulta Utilizzare un account di servizio con privilegio minimo minimi.

Per specificare un account di servizio personalizzato in gcloud CLI, aggiungi il seguente flag al comando:

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Sostituisci SERVICE_ACCOUNT_NAME con il nome del tuo account di servizio con privilegi minimi.

Crea il pool di nodi Windows Server con i seguenti campi:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

Sostituisci quanto segue:

NODE_POOL_NAME: il nome scelto per il pool di nodi Windows Server.
CLUSTER_NAME: il nome del cluster creato sopra.
IMAGE_NAME: puoi specificare uno dei seguenti valori:
- WINDOWS_LTSC_CONTAINERD: Windows Server LTSC con containerd. Questo è il tipo di immagine sia per l'immagine del sistema operativo Windows Server 2022 sia per l'immagine del sistema operativo Windows Server 2019
- WINDOWS_SAC_CONTAINERD: SAC di Windows Server con containerd (non supportato dopo il 9 agosto 2022)
- WINDOWS_LTSC: Windows Server LTSC con Docker
- WINDOWS_SAC: Windows Server SAC con Docker (non supportato dopo il 9 agosto 2022)
Avviso: in GKE 1.24 e versioni successive, le immagini con il runtime Docker non sono supportate. Esegui la migrazione alle immagini con il runtime containerd prima di eseguire l'upgrade a GKE 1.24. Per scoprire di più su questa modifica, consulta la sezione Eseguire la migrazione da Docker a containerd.

Per saperne di più su queste immagini dei nodi, consulta la sezione Scegliere l'immagine del nodo Windows.
--no-enable-autoupgrade disattiva l'upgrade automatico dei nodi. Consulta Eseguire l'upgrade dei pool di nodi Windows Server prima di attivare la funzionalità.
MACHINE_TYPE_NAME: definisce il tipo di macchina. n1-standard-2 è il tipo di macchina minimo consigliato perché i nodi Windows Server richiedono risorse aggiuntive. I tipi di macchine f1-micro e g1-small non sono supportati. Ogni tipo di macchina viene fatturato in modo diverso. Per ulteriori informazioni, consulta il listino prezzi dei tipi di macchine.
WINDOWS_OS_VERSION: definisce la versione del sistema operativo Windows da utilizzare per il tipo di immagine WINDOWS_LTSC_CONTAINERD. Questo è un flag facoltativo. Se non specificato, la versione predefinita del sistema operativo utilizzata sarà LTSC2019. Imposta il valore su ltsc2022 per creare un pool di nodi Windows Server 2022. Imposta il valore su ltsc2019 per creare un pool di nodi Windows Server 2019.

L'esempio seguente mostra come creare un pool di nodi Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

L'esempio seguente mostra come aggiornare un pool di nodi Windows esistente per utilizzare l'immagine del sistema operativo Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --windows-os-version=ltsc2022

Console

Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

Vai a Google Kubernetes Engine
Fai clic su Crea.
Nella sezione Nozioni di base sul cluster, completa quanto segue:
1. Inserisci il nome del cluster.
2. Per Tipo di località, seleziona la regione o la zona che preferisci per il tuo cluster.
3. In Versione del piano di controllo, seleziona un canale di rilascio o scegli di specificare una versione statica. La versione statica deve essere 1.16.8-gke.9 o successiva.
Nel riquadro di navigazione, fai clic su default-pool in Pool di nodi per creare il pool di nodi Linux. Quando configuri questo pool di nodi, devi fornire risorse di calcolo sufficienti per eseguire i componenti aggiuntivi del cluster. Devi inoltre disporre di una quota di risorse disponibile per i nodi e le relative risorse (ad esempio le route del firewall).
Nella parte superiore della pagina, fai clic su Aggiungi pool di nodi per creare il pool di nodi Windows Server.
Nella sezione Dettagli del pool di nodi, completa quanto segue:
1. Inserisci un nome per il pool di nodi.
2. Per i nodi con versione statica, scegli Versione del nodo.
3. Inserisci il numero di nodi da creare nel pool di nodi.
Nel riquadro di navigazione, in Pool di nodi, fai clic su Nodi.
1. Nell'elenco a discesa Tipo di immagine, seleziona una delle seguenti immagini di nodo:
  - Long-Term Servicing Channel di Windows con Docker
  - Long-Term Servicing Channel di Windows con containerd
  - Canale semestrale di Windows con Docker
  - Canale semestrale di Windows con containerd
  Avviso: nella versione 1.24 e successive di GKE, i tipi di immagini dei nodi basate su Docker non sono supportati. Nella versione 1.23 di GKE, non puoi nemmeno creare nuovi node pool con tipi di immagini dei nodi Docker. Devi eseguire la migrazione a un tipo di immagine del nodo containerd. Per approfondire questa modifica, consulta Informazioni sulla deprecazione delle immagini dei nodi Docker.
  
  Per saperne di più, consulta la sezione Scegliere l'immagine del nodo Windows.
2. Scegli la configurazione della macchina predefinita da utilizzare per le istanze. n1-standard-2 è la dimensione minima consigliata perché i nodi Windows Server richiedono risorse aggiuntive. I tipi di macchine f1-micro e g1-small non sono supportati. Ogni tipo di macchina viene fatturato in modo diverso. Per ulteriori informazioni, consulta il listino prezzi dei tipi di macchine.
Nel riquadro di navigazione, seleziona il nome del pool di nodi Windows Server. In questo modo tornerai alla pagina Dettagli del pool di nodi.
1. In Automazione, deseleziona la casella di controllo Abilita upgrade automatico dei nodi. Esamina la sezione Eseguire l'upgrade dei pool di nodi Windows Server prima di attivare l'upgrade automatico.
Nel riquadro di navigazione, in Cluster, seleziona Networking.
1. In Opzioni di networking avanzate, assicurati che l'opzione Abilita routing del traffico VPC nativo (mediante IP alias) sia selezionata. L'IP alias è obbligatorio per i nodi Windows Server. Per scoprire di più sui vantaggi, consulta Informazioni sul routing dei contenitori nativi con gli IP alias.
Fai clic su Crea.

Terraform

Per creare un cluster GKE Standard e un pool di nodi Windows Server utilizzando Terraform, consulta il seguente esempio:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

Questo esempio utilizza Windows Server LTSC con containerd. Questo è il tipo di immagine sia per l'immagine del sistema operativo Windows Server 2022 sia per quella di Windows Server 2019. Per maggiori informazioni sulle immagini dei nodi, consulta Scegliere l'immagine del nodo Windows.

Per scoprire di più sull'utilizzo di Terraform, consulta Assistenza di Terraform per GKE.

Dopo aver creato un pool di nodi Windows Server, il cluster entra in uno stato RECONCILE per diversi minuti durante l'aggiornamento del piano di controllo.

Ottenere le credenziali kubectl

Utilizza il comando get-credentials per consentire a kubectl di lavorare con il cluster che hai creato.

gcloud container clusters get-credentials CLUSTER_NAME

Per ulteriori informazioni sul comando get-credentials, consulta la documentazione dell'SDK su get-credentials.

Attendi l'inizializzazione del cluster

Prima di utilizzare il cluster, attendi alcuni secondi fino alla creazione di windows.config.common-webhooks.networking.gke.io. Questo webhook aggiunge tolleranze di pianificazione ai pod creati con il selettore di nodi kubernetes.io/os: windows per garantire che possano essere eseguiti sui nodi Windows Server. Inoltre, convalida il pod per assicurarsi che utilizzi solo le funzionalità supportate su Windows.

Per assicurarti che l'webhook sia stato creato, esegui il seguente comando:

kubectl get mutatingwebhookconfigurations

L'output dovrebbe mostrare l'esecuzione del webhook:

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

Ora che hai un cluster con due pool di nodi (uno Linux e uno Windows), puoi eseguire il deployment di un'applicazione Windows.

Mappatura delle versioni di GKE e Windows

Microsoft rilascia nuove versioni di SAC ogni sei mesi circa e nuove versioni LTSC ogni due-tre anni. Queste nuove versioni sono in genere disponibili nelle nuove versioni secondarie di GKE. All'interno di una versione secondaria di GKE le versioni LTSC e SAC di solito rimangono invariate.

Per visualizzare la mappatura delle versioni tra GKE e Windows Server, utilizza il comando gcloud beta container get-server-config:

gcloud beta container get-server-config

La mappatura delle versioni viene restituita nel campo windowsVersionMaps della risposta. Per filtrare la risposta in modo da visualizzare la mappatura delle versioni per versioni GKE specifiche nel cluster, esegui i seguenti passaggi in una shell Linux o in Cloud Shell.

Imposta le seguenti variabili:
```
CLUSTER_NAME=CLUSTER_NAME
NODE_POOL_NAME=NODE_POOL_NAME
ZONE=COMPUTE_ZONE
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del tuo cluster.
- NODE_POOL_NAME: il nome del pool di nodi Windows Server.
- COMPUTE_ZONE: la zona di calcolo per il cluster.

Ottieni la versione del pool di nodi e memorizzala nella variabile NODE_POOL_VERSION:

NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`

Ottieni le versioni di Windows Server per NODE_POOL_VERSION:

gcloud beta container get-server-config \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

L'output è simile al seguente:

windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

Ottieni la versione di Windows Server per il tipo di immagine WINDOWS_SAC:

gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

L'output è simile al seguente:

10.0.18363.1198

Upgrade dei pool di nodi Windows Server

I requisiti di compatibilità della versione del contenitore Windows Server indicano che le immagini dei contenitori potrebbero dover essere ricostruite in modo da corrispondere alla versione di Windows Server per una nuova versione di GKE prima di eseguire l'upgrade dei pool di nodi.

Per assicurarti che le immagini container rimangano compatibili con i tuoi nodi, ti consigliamo di controllare la mappatura delle versioni e di creare le immagini container di Windows Server come immagini multi-arch che possono avere come target più versioni di Windows Server. Prima di eseguire manualmente un upgrade del pool di nodi GKE, puoi aggiornare i deployment dei container in modo che abbiano come target le immagini multi-architettura che funzioneranno sia nella versione GKE corrente sia in quella successiva. Gli upgrade pool di nodi pool devono essere eseguiti regolarmente perché i nodi non possono essere più di due versioni secondarie in ritardo rispetto alla versione del control plane.

Ti consigliamo di abbonarti alle notifiche di upgrade utilizzando Pub/Sub per ricevere proattivamente aggiornamenti sulle nuove versioni di GKE e sulle versioni del sistema operativo Windows che utilizzano.

Consigliamo di attivare gli upgrade automatici dei nodi solo se crei continuamente immagini contenitore Windows Server multi-arch che hanno come target le versioni più recenti di Windows Server, in particolare se utilizzi Windows Server SAC come tipo di immagine del nodo. È meno probabile che gli upgrade automatici dei nodi causino problemi con il tipo di immagine del nodo Windows Server LTSC, ma esiste comunque il rischio di riscontrare problemi di incompatibilità delle versioni.

Windows Update

Gli aggiornamenti di Windows sono disattivati per i nodi Windows Server. Gli aggiornamenti automatici possono causare riavvii dei nodi in momenti imprevedibili e tutti gli aggiornamenti di Windows installati dopo l'avvio di un nodo andranno persi quando il nodo verrà ricreato da GKE. GKE rende disponibili gli aggiornamenti di Windows aggiornando periodicamente le immagini dei nodi Windows Server utilizzate nelle nuove release di GKE. Può intercorrere un certo lasso di tempo tra il momento in cui gli aggiornamenti di Windows vengono rilasciati da Microsoft e il momento in cui sono disponibili in GKE. Quando vengono rilasciati aggiornamenti della sicurezza critici, GKE aggiorna le immagini dei nodi Windows Server il più rapidamente possibile.

Controllare la comunicazione tra i pod e i servizi Windows

Puoi controllare la modalità di comunicazione dei pod e dei servizi Windows utilizzando criteri di rete.

Puoi avere un contenitore Windows Server nei cluster in cui è attivato il criterio di rete nelle versioni GKE 1.22.2 e successive. Questa funzionalità è disponibile per i cluster che utilizzano i tipi di immagini dei nodi WINDOWS_LTSC o WINDOWS_LTSC_CONTAINERD.

Se i tuoi piani di controllo o i tuoi nodi eseguono versioni precedenti, puoi eseguire la migrazione dei tuoi pool di nodi a una versione che supporta i criteri di rete eseguendo l'upgrade dei pool di nodi e del piano di controllo alla versione GKE 1.22.2 o successiva. Questa opzione è disponibile solo se hai creato il cluster con il flag --enable-dataplane-v2.

Dopo aver attivato il criterio di rete, diventano attivi tutti i criteri configurati in precedenza, inclusi quelli che non funzionavano nei contenitori Windows Server prima di attivare la funzionalità.

Alcuni cluster non possono essere utilizzati con i container Windows Server su cluster con i criteri di rete abilitati. Per ulteriori dettagli, consulta la sezione Limitazioni.

Visualizzazione e query dei log

La registrazione è attivata automaticamente nei cluster GKE. Puoi visualizzare i log dei container e di altri servizi sui nodi Windows Server utilizzando il monitoraggio di Kubernetes Engine.

Di seguito è riportato un esempio di filtro per ottenere il log del contenitore:

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

Accesso a un nodo Windows Server utilizzando il protocollo Remote Desktop Protocol (RDP)

Puoi connetterti a un nodo Windows Server nel cluster utilizzando RDP. Per istruzioni su come effettuare la connessione, consulta Connessione alle istanze Windows nella documentazione di Compute Engine.

Creazione di immagini multi-arch

Puoi creare le immagini multi-arch manualmente o utilizzare un generatore Cloud Build. Per le istruzioni, vedi Creare immagini multi-arch Windows.

Utilizzo di gMSA

I passaggi riportati di seguito mostrano come utilizzare un account di servizio gestito dal gruppo (gMSA) con i pool di nodi Windows Server.

Configura i nodi Windows Server nel cluster in modo che si uniscano automaticamente al tuo dominio AD. Per le istruzioni, consulta Configurare i nodi Windows Server per l'unione automatica a un dominio Active Directory.
Crea e concedi a un gMSA l'accesso al gruppo di sicurezza creato automaticamente dal servizio di adesione al dominio. Questo passaggio deve essere eseguito su un computer con accesso amministrativo al tuo dominio AD.
```
$instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName
```
Sostituisci quanto segue:
- NODE_POOL_NAME: il nome del pool di nodi Windows Server. Il gruppo di sicurezza creato automaticamente ha lo stesso nome del tuo pool di nodi Windows Server.
- CLUSTER_NAME: il nome del tuo cluster.
- GMSA_NAME: il nome scelto per il nuovo gMSA.
- DNS_HOST_NAME: il nome di dominio completo (FQDN) dell'account di servizio che hai creato. Ad esempio, se GMSA_NAME è webapp01 e il dominio è example.com, DNS_HOST_NAME è webapp01.example.com.
Configura il gMSA seguendo le istruzioni riportate nel tutorial Configurare GMSA per pod e contenitori Windows.

Eliminazione di pool di nodi Windows Server

Elimina un pool di nodi Windows Server utilizzando gcloud o la console Google Cloud.

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

Console

Per eliminare un pool di nodi Windows Server utilizzando la console Google Cloud, svolgi i seguenti passaggi:

Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

Vai a Google Kubernetes Engine
Accanto al cluster che vuoi modificare, fai clic su Azioni e poi su Modifica.
Seleziona la scheda Nodi.
Nella sezione Pool di nodi, fai clic su Elimina accanto al pool di nodi che vuoi eliminare.
Quando ti viene chiesto di confermare, fai di nuovo clic su Elimina.

Limitazioni

Alcune funzionalità di Kubernetes non sono ancora supportate per i container Windows Server. Inoltre, alcune funzionalità sono specifiche per Linux e non funzionano su Windows. Per l'elenco completo delle funzionalità di Kubernetes supportate e non supportate, consulta la documentazione di Kubernetes.

Oltre alle funzionalità di Kubernetes non supportate, alcune funzionalità di GKE non sono supportate.

Per i cluster GKE, le seguenti funzionalità non sono supportate con i node pool Windows Server:

Cloud TPU (--enable-tpu)
Streaming di immagini
Visibilità tra nodi (--enable-intra-node-visibility)
Agente di mascheramento IP
Cluster alpha Kubernetes (--enable-kubernetes-alpha)
Cache DNS locale del nodo
Utilizzo privato di indirizzi IP di classe E
Utilizzo privato di indirizzi IP pubblici
Logging dei criteri di rete
Kubernetes service.spec.sessionAffinity
GPU (--accelerator)
Impostazione del numero massimo di pod per nodo superiore al limite predefinito di 110
Driver CSI Filestore
Proxy di autenticazione CloudSQL basato su Docker
Reti a doppio stack IPv4/IPv6 IPv6 non è supportato sui nodi Windows.

Il criterio per il traffico esterno locale nel pool di nodi Windows è supportato solo con GKE versione v1.23.4-gke.400 o successive.

Altri prodotti Google Cloud che vuoi utilizzare con i cluster GKE potrebbero non supportare i pool di nodi Windows Server. Per limitazioni specifiche, consulta la documentazione del prodotto.

Risoluzione dei problemi

Consulta la documentazione di Kubernetes per indicazioni generali sul debug dei pod e dei servizi.

Problemi relativi ai nodi containerd

Per i problemi noti relativi all'utilizzo di un'immagine del nodo Containerd, consulta la sezione Problemi noti.

I pod Windows non riescono ad avviarsi

Una mancata corrispondenza della versione tra il contenitore Windows Server e il nodo Windows che sta tentando di eseguire il contenitore può comportare l'interruzione dell'avvio dei pod Windows.

Se la versione del pool di nodi Windows è 1.16.8-gke.8 o successiva, consulta la documentazione di Microsoft relativa al problema di incompatibilità dei container di Windows Server di febbraio 2020 e crea le immagini dei container con le immagini di base di Windows che includono gli aggiornamenti di Windows di marzo 2020. Le immagini dei container create su immagini Windows di base precedenti potrebbero non riuscire a essere eseguite su questi nodi Windows e possono anche causare un errore del nodo con stato NotReady.

Errori di pull delle immagini

Le immagini container di Windows Server e i singoli livelli di cui sono composte possono essere molto grandi. Le loro dimensioni possono causare il timeout di Kubelet e l'errore durante il download e l'estrazione dei livelli del contenitore.

Potresti aver riscontrato questo problema se visualizzi i messaggi di errore "Impossibile estrarre l'immagine" o "Contesto di estrazione dell'immagine annullato" o uno stato ErrImagePull per i tuoi pod.

Se l'immagine di pull si verifica di frequente, devi utilizzare pool di nodi con una specifica della CPU più elevata. L'estrazione dei contenitori viene eseguita in parallelo sui core, pertanto i tipi di macchine con più core riducono il tempo di pull complessivo.

Prova le seguenti opzioni per estrarre correttamente i contenitori Windows Server:

Suddividi i livelli di applicazione dell'immagine del container Windows Server in livelli più piccoli che possono essere estratti e estratti più rapidamente. In questo modo, la memorizzazione nella cache dei livelli di Docker può essere più efficace e le ripetizioni del pull delle immagini hanno maggiori probabilità di successo. Per scoprire di più sui livelli, consulta l'articolo di Docker su Driver di archiviazione.
Connettiti ai nodi Windows Server e utilizza manualmente il comando docker pull sulle immagini container prima di creare i pod.
Imposta il flag image-pull-progress-deadline per il servizio kubelet per aumentare il timeout per il recupero delle immagini dei contenitori.

Imposta il flag connettendoti ai nodi Windows ed eseguendo i seguenti comandi PowerShell.

Nota: questa procedura richiede un kubelet restart, che può interrompere i pod in esecuzione sul nodo.
1. Recupera la riga di comando esistente per il servizio Kubelet dal Registro di sistema di Windows.
```
PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
```
```
PS C:\> $name = "ImagePath"
```
```
PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
"(?s)${name}.*(C:.*kubelet\.exe.*)"
```
```
PS C:\> $kubelet_cmd = $Matches[1] -replace `
"--image-pull-progress-deadline=.* ","" -replace "\r\n"," "
```
2. Imposta una nuova riga di comando per il servizio Kubelet, con un flag aggiuntivo per aumentare il timeout.
```
PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
--image-pull-progress-deadline=40m "
```
3. Verifica che la modifica sia andata a buon fine.
```
PS C:\> reg query ${regkey} /v ${name}
```
4. Riavvia il servizio kubelet in modo che il nuovo flag venga applicato.
```
PS C:\> Restart-Service kubelet
```
5. Verifica che il servizio kubelet sia stato riavviato correttamente.
```
PS C:\> Get-Service kubelet # ensure state is Running
```

La famiglia di immagini ha raggiunto fine del ciclo di vita

Quando crei un pool di nodi con un'immagine Windows, ricevi un errore simile al seguente:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer versions are still available.

Per risolvere questo errore, scegli un'immagine di Windows disponibile e supportata. Puoi trovare la data di fine dell'assistenza per le immagini dei nodi Windows di GKE utilizzando il comando gcloud container get-server-config come descritto nella sezione Mappare le versioni di GKE e Windows.

Timeout durante la creazione pool di nodi

La creazione del pool di nodi può scadere se stai creando un numero elevato di nodi (ad esempio 500) e si tratta del primo pool di nodi nel cluster che utilizza un'immagine di Windows Server.

Per risolvere il problema, riduci il numero di nodi che stai creando. Puoi aumentare il numero di nodi in un secondo momento.

I nodi Windows diventano `NotReady` con l'errore: "PLEG non è in stato normale"

Si tratta di un problema noto di Kubernetes che si verifica quando vengono avviati più pod molto rapidamente su un singolo node Windows. Per risolvere il problema, riavvia il nodo Windows Server. Una soluzione alternativa consigliata per evitare questo problema è limitare la frequenza di creazione dei pod Windows a un pod ogni 30 secondi.

TerminationGracePeriod incoerente

Il timeout del sistema Windows per il contenitore potrebbe essere diverso dal periodo di tolleranza configurato. Questa differenza può causare l'interruzione forzata del contenitore da parte di Windows prima del termine del periodo di tolleranza passato al runtime.

Puoi modificare il timeout di Windows modificando le chiavi del Registro di sistema locali del contenitore al momento della compilazione dell'immagine. Se modifichi il timeout di Windows, potrebbe essere necessario anche modificare TerminationGracePeriodSeconds in modo che corrisponda.

Problemi di connettività di rete

Se riscontri problemi di connettività di rete nei contenitori Windows Server, potrebbe essere perché la rete dei contenitori Windows Server spesso presuppone un MTU di rete di 1500, che non è compatibile con l'MTU di Google Cloud di 1460.

Verifica che sia l'MTU dell'interfaccia di rete nel contenitore sia le interfacce di rete del nodo Windows Server stesso siano impostate sullo stesso valore (ovvero 1460 o meno). Per informazioni su come impostare il valore MTU, consulta i problemi noti per i contenitori Windows.

Problemi di avvio dei nodi

Se i nodi non riescono ad avviarsi nel cluster o non riescono ad aggiungersi correttamente al cluster, esamina le informazioni di diagnostica fornite nell'output della porta seriale del nodo.

Esegui questo comando per visualizzare l'output della porta seriale:

gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE

Sostituisci quanto segue:

NODE_NAME: il nome del nodo.
COMPUTE_ZONE: la zona di calcolo per il nodo specifico.

Servizi intermittentemente non raggiungibili nei nodi Windows con cluster che eseguono 1.24 o versioni precedenti

Quando avvii i nodi Windows nei cluster Kubernetes con un numero elevato di regole del bilanciatore del carico del servizio di rete dell'host, si verifica un ritardo nell'elaborazione delle regole. I servizi non sono raggiungibili a intermittenza durante il ritardo, che dura circa 30 secondi per regola, e il ritardo totale può essere significativo se sono presenti regole sufficienti. Per saperne di più, consulta il problema originale su GitHub.

Per i cluster GKE che eseguono la versione 1.24 o precedenti, con eventuali nodi Windows che hanno avuto un evento di riavvio kube-proxy, ad esempio avvio del node, upgrade del node, riavvio manuale, tutti i servizi raggiunti da un pod in esecuzione su quel nodo non saranno raggiungibili finché tutte le regole non saranno sincronizzate dal componente.

Per i cluster GKE che eseguono la versione 1.25 o successive, questo comportamento è notevolmente migliorato. Per maggiori dettagli su questo miglioramento, consulta la pull request su GitHub. Se riscontri questo problema, ti consigliamo di eseguire l'upgrade del piano di controllo del tuo cluster alla versione 1.25 o successiva.

Passaggi successivi

Scopri come implementare un'applicazione Windows.
Leggi la breve introduzione di Microsoft ai container Windows.
Leggi le linee guida di Microsoft sulla scelta delle immagini di base del contenitore.
Scopri di più sulla compatibilità delle versioni dei contenitori di Microsoft su Windows.

Creazione di un cluster mediante i pool di nodi di Windows Server

Creazione di un cluster mediante i pool di nodi di Windows Server

Configurare gli account di servizio IAM per GKE

console

gcloud

Scegli l'immagine del nodo Windows Server

Aggiorna e configura gcloud

Crea un cluster e pool di nodi

gcloud

Console

Terraform

Ottenere le credenziali kubectl

Attendi l'inizializzazione del cluster

Mappatura delle versioni di GKE e Windows

Upgrade dei pool di nodi Windows Server

Windows Update

Controllare la comunicazione tra i pod e i servizi Windows

Visualizzazione e query dei log

Accesso a un nodo Windows Server utilizzando il protocollo Remote Desktop Protocol (RDP)

Creazione di immagini multi-arch

Utilizzo di gMSA

Eliminazione di pool di nodi Windows Server

gcloud

Console

Limitazioni

Risoluzione dei problemi

Problemi relativi ai nodi containerd

I pod Windows non riescono ad avviarsi

Errori di pull delle immagini

La famiglia di immagini ha raggiunto fine del ciclo di vita

Timeout durante la creazione pool di nodi

I nodi Windows diventano NotReady con l'errore: "PLEG non è in stato normale"

TerminationGracePeriod incoerente

Problemi di connettività di rete

Problemi di avvio dei nodi

Servizi intermittentemente non raggiungibili nei nodi Windows con cluster che eseguono 1.24 o versioni precedenti

Passaggi successivi

Aggiorna e configura `gcloud`

I nodi Windows diventano `NotReady` con l'errore: "PLEG non è in stato normale"