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

In questa pagina imparerai a creare un cluster Google Kubernetes Engine (GKE) con pool di nodi che eseguono Microsoft Windows Server. Con questo cluster puoi utilizzare i container di Windows Server. I container Microsoft Hyper-V non sono attualmente supportati. Come i container Linux, i container Windows Server forniscono l'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 Windows Server che non possono essere eseguiti nei container. Poiché i nodi Windows Server richiedono più risorse, le risorse allocabili sono inferiori rispetto a quelle che sarebbero sui nodi Linux.

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

In questa sezione creerai un cluster che utilizza un container Windows Server.

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

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

Scegli l'immagine del nodo Windows Server

Per l'esecuzione su GKE, le immagini dei nodi dei container di Windows Server devono essere create con 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 di Windows Server diverse, ma ogni singolo pool di nodi può utilizzare una sola versione di Windows Server.

Considera quanto segue quando scegli l'immagine del tuo nodo:

• Tempistiche dell'assistenza:
  • Le tempistiche del supporto per un'immagine dei nodi Windows Server sono soggette alle tempistiche del supporto fornite da Microsoft, come descritto in Criteri di supporto per le immagini del sistema operativo. Puoi trovare la data di fine del supporto per le immagini dei nodi Windows di GKE utilizzando il comando gcloud container get-server-config, come descritto nella sezione Mappatura delle versioni GKE e Windows.
  • Le versioni SAC sono supportate da Microsoft solo per 18 mesi dopo il rilascio iniziale. Se scegli SAC per il tipo di immagine per il 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 pool di nodi 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 perché ha un ciclo di assistenza più lungo.
  • Non scegliere SAC se registri il cluster GKE nel canale di rilascio stabile. Poiché le versioni SAC sono supportate da Microsoft solo per 18 mesi, c'è il rischio che l'immagine del pool di nodi SAC non sia più supportata mentre la versione stabile di GKE è ancora disponibile.
• Compatibilità e complessità della versione:
  • Scegli SAC solo se puoi eseguire l'upgrade del pool di nodi e dei container in esecuzione al suo interno regolarmente. GKE aggiorna periodicamente la versione SAC utilizzata per i pool di nodi Windows nelle nuove release di GKE, quindi la scelta di SAC per il tipo di immagine del pool di nodi richiede di ricreare i container più spesso.
  • Se hai dubbi sul tipo di immagine Windows Server da utilizzare, ti consigliamo di scegliere il protocollo LTSC di Windows Server per evitare problemi di incompatibilità delle versioni durante l'upgrade del pool di nodi. Per ulteriori informazioni, consulta la documentazione relativa ai canali di servizio 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 tuoi container.
  • I container Windows Server hanno importanti requisiti 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 ricreati per scegliere come target l'altra versione.
  • Creare immagini container di Windows Server come immagini multi-arch che possono avere come target più versioni di Windows Server può aiutarti a gestire questa complessità del controllo delle versioni.
• Nuove funzionalità:
  • Le nuove funzionalità di Windows Server vengono generalmente introdotte prima nelle versioni di SAC. Per questo motivo, nei pool di nodi SAC potrebbero essere introdotte prima nuove funzionalità Windows.
  • Prendi in considerazione SAC se dipendi da funzionalità non ancora disponibili nella release LTSC.

• Runtime del container:

  • Per le immagini dei nodi LTSC e SAC di Windows Server, il runtime del container può essere Docker o containerd. Per il nodo GKE versione 1.21.1-gke.2200 e successive, consigliamo di utilizzare il runtime containerd. Per ulteriori informazioni, vedi Immagini dei nodi.

Aggiorna e configura gcloud

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

• Assicurati di disporre dell'autorizzazione corretta per creare cluster. Come minimo, dovresti essere un amministratore di cluster Kubernetes Engine.

Crea un cluster e i pool di nodi

Per eseguire i container Windows Server, il cluster deve avere almeno un pool di nodi Windows e un pool di nodi 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, consigliamo di attivare la scalabilità automatica per garantire che il pool di nodi Linux abbia una capacità sufficiente per eseguire componenti aggiuntivi del cluster.

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

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

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

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

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"
  }
}

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

Ottieni credenziali kubectl

Usa il comando get-credentials per abilitare kubectl in modo che funzioni con il cluster che hai creato.

gcloud container clusters get-credentials CLUSTER_NAME

Per ulteriori informazioni sul comando get-credentials, consulta la documentazione sull'SDK 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 le 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 funzionalità supportate su Windows.

Per assicurarti che il webhook venga creato, esegui questo comando:

kubectl get mutatingwebhookconfigurations

L'output dovrebbe mostrare il webhook in esecuzione:

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 GKE e Windows

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

Per visualizzare la mappatura delle versioni tra le versioni GKE e le versioni di 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 e visualizzare la mappatura delle versioni per versioni di GKE specifiche nel cluster, esegui questi passaggi in una shell di Linux o in Cloud Shell.

1. 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 computing per il cluster.

2. Ottieni la versione del pool di nodi e archiviala nella variabile NODE_POOL_VERSION:

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

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

4. 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 dei container di Windows Server indicano che potrebbe essere necessario ricreare le immagini container per 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. Puoi quindi aggiornare i deployment dei container in modo che abbiano come target le immagini multi-arch che funzioneranno sia sulla versione GKE attuale sia su quella successiva prima di richiamare manualmente un upgrade del pool di nodi GKE. Gli upgrade manuali del pool di nodi devono essere eseguiti regolarmente perché i nodi non possono essere più di due versioni secondarie dopo la versione del piano di controllo.

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.

Ti consigliamo di abilitare gli upgrade automatici dei nodi solo se crei continuamente immagini container di Windows Server multi-arch destinate alle versioni più recenti di Windows Server, soprattutto se utilizzi SAC di Windows Server come tipo di immagine dei nodi. Gli upgrade automatici dei nodi hanno meno probabilità di causare problemi con il tipo di immagine dei nodi LTSC di Windows Server, ma c'è comunque il rischio di riscontrare problemi di incompatibilità delle versioni.

Aggiornamenti di Windows

Gli aggiornamenti di Windows sono disabilitati 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 viene ricreato da GKE. GKE rende disponibili gli aggiornamenti di Windows aggiornando periodicamente le immagini dei nodi Windows Server utilizzate nelle nuove release di GKE. Potrebbe verificarsi un ritardo tra il rilascio degli aggiornamenti Windows da parte di Microsoft e quello 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.

Controlla il modo in cui comunicano i pod e i servizi Windows

Puoi controllare il modo in cui i pod e i servizi Windows comunicano utilizzando i criteri di rete.

Puoi avere un container Windows Server sui cluster con criterio di rete abilitato in GKE 1.22.2 e versioni successive. Questa funzionalità è disponibile per i cluster che utilizzano i tipi di immagine dei nodi WINDOWS_LTSC o WINDOWS_LTSC_CONTAINERD.

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

Dopo aver abilitato il criterio di rete, tutti i criteri configurati in precedenza, inclusi quelli che non funzionavano nei container Windows Server prima dell'abilitazione della funzionalità, diventano attivi.

Alcuni cluster non possono essere utilizzati con i container Windows Server sui cluster in cui è abilitato il criterio di rete. Consulta la sezione Limitazioni per ulteriori dettagli.

Visualizzazione ed esecuzione di query sui log

Il logging è abilitato automaticamente nei cluster GKE. Puoi visualizzare i log dei container e quelli di altri servizi sui nodi di Windows Server utilizzando il monitoraggio di Kubernetes Engine.

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

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 tramite Remote Desktop Protocol (RDP)

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

Creazione di immagini multi-arco

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

Utilizzo di gMSA

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

1. Configura i nodi Windows Server nel cluster in modo che vengano aggiunti automaticamente al dominio AD. Per le istruzioni, consulta Configurare i nodi Windows Server per l'aggiunta automatica a un dominio Active Directory.

2. Creare e concedere un accesso gMSA al gruppo di sicurezza creato automaticamente dal servizio di aggiunta al dominio. Questo passaggio deve essere eseguito in una macchina con accesso amministrativo al 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 di Windows Server. Il gruppo di sicurezza creato automaticamente ha lo stesso nome del pool di nodi di Windows Server.
   • CLUSTER_NAME: il nome del tuo cluster.
   • GMSA_NAME: il nome che scegli 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.

3. Configura gMSA seguendo le istruzioni nel tutorial Configurare pod e container GMSA per Windows.

Eliminazione dei pool di nodi di Windows Server

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

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

Limitazioni

Alcune funzionalità di Kubernetes non sono ancora supportate per i container Windows Server. Inoltre, alcune funzionalità sono specifiche di Linux e non funzionano per 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, esistono alcune funzionalità GKE che non sono supportate.

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

• Cloud TPU (--enable-tpu)
• Streaming di immagini
• In entrata con gruppi di endpoint di rete
• Gateway
• Visibilità tra nodi (--enable-intra-node-visibility)
• Agente di mascheramento IP
• Cluster Kubernetes alpha (--enable-kubernetes-alpha)
• Cache DNS locale dei nodi
• 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 Cloud SQL basato su Docker
• Networking a doppio stack IPv4/IPv6 L'IPv6 non è supportato sui nodi Windows.

Il criterio del traffico esterno locale nel pool di nodi Windows è supportato solo con GKE versione 1.23.4-gke.400 o successive.

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

Risoluzione dei problemi

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

Problemi relativi ai nodi containerd

Per conoscere i problemi noti relativi all'utilizzo di un'immagine dei nodi Containerd, consulta Problemi noti.

I pod Windows non si avviano

Una mancata corrispondenza della versione tra il container Windows Server e il nodo Windows che sta tentando di eseguire il container può causare l'impossibilità di avviare i pod Windows.

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

Errori di pull delle immagini

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

Potresti aver riscontrato questo problema se visualizzi i messaggi di errore "Impossibile eseguire il pull dell'immagine" o "Contesto del pull dell'immagine annullato" o uno stato ErrImagePull per i tuoi pod.

Se l'immagine pull avviene di frequente, dovresti usare pool di nodi con una specifica della CPU più elevata. L'estrazione dei container viene eseguita in parallelo tra i core, quindi i tipi di macchina con più core riducono il tempo di pull complessivo.

Prova le seguenti opzioni per eseguire correttamente il pull dei container Windows Server:

• Suddividi i livelli dell'applicazione dell'immagine container di Windows Server in livelli più piccoli, ciascuno dei quali può essere estratti ed estratto più rapidamente. Ciò può rendere più efficace la memorizzazione nella cache del livello di Docker e aumentare la probabilità di esito positivo dei nuovi tentativi di pull delle immagini. Per saperne di più sui livelli, consulta l'articolo di Docker Informazioni su immagini, container e 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 in modo da aumentare il timeout per il pull delle immagini container.

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

  1. Recupera la riga di comando esistente per il servizio kubelet dal registro 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 per applicare il nuovo flag.

     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 la 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 Windows che sia disponibile e supportata. Puoi trovare la data di fine del supporto per le immagini dei nodi Windows di GKE utilizzando il comando gcloud container get-server-config, come descritto nella sezione Mappatura delle versioni GKE e Windows.

Timeout durante la creazione del pool di nodi

La creazione di pool di nodi può scadere se stai creando un numero elevato di nodi (ad esempio 500) e se 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 è integro"

Questo è un problema noto di Kubernetes che si verifica quando più pod vengono avviati molto rapidamente su un singolo nodo Windows. Per ripristinare questa situazione, riavvia il nodo Windows Server. Una soluzione alternativa consigliata per evitare questo problema è limitare la frequenza con cui i pod di Windows vengono creati a un pod ogni 30 secondi.

Risoluzione incoerenteGracePeriod

Il timeout del sistema Windows per il container potrebbe essere diverso dal periodo di tolleranza configurato. Questa differenza può causare la chiusura forzata del container da parte di Windows prima della fine del periodo di tolleranza passato al runtime.

Puoi modificare il timeout di Windows modificando le chiavi del Registro di sistema locali del container al momento della creazione delle immagini. Se modifichi il timeout di Windows, potresti anche dover modificare TermsGracePeriodSeconds in modo che corrisponda.

Problemi di connettività di rete

Se riscontri problemi di connettività di rete dai container di Windows Server, è possibile che il networking dei container di Windows Server spesso preveda una MTU di rete 1500, incompatibile con la MTU di Google Cloud 1460.

Verifica che sia l'MTU dell'interfaccia di rete nel container sia le interfacce di rete del nodo Windows Server stesso siano impostate sullo stesso valore (ossia 1460 o un valore inferiore). Per informazioni su come impostare la MTU, consulta i problemi noti relativi ai container Windows.

Problemi di avvio dei nodi

Se i nodi non si avviano nel cluster o non vengono uniti al cluster, rivedi 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 computing per il nodo specifico.

Servizi a intermittenza non raggiungibili nei nodi Windows con cluster in esecuzione 1.24 o precedenti

Quando avvii nodi Windows nei cluster Kubernetes con un numero elevato di regole del bilanciatore del carico Host Network Service, si verifica un ritardo nell'elaborazione delle regole. Durante il ritardo, che dura circa 30 secondi per regola, i servizi non sono raggiungibili a intermittenza. Il ritardo totale può essere significativo se esistono abbastanza regole. Per scoprire di più, consulta il problema originale in GitHub.

Per i cluster GKE che eseguono la versione 1.24 o precedenti, con qualsiasi nodo Windows che presenta un evento che ha riavviato kube-proxy, ad esempio avvio del nodo, upgrade del nodo, riavvio manuale, qualsiasi servizio raggiunto da un pod in esecuzione su quel nodo sarà irraggiungibile fino a quando tutte le regole non sono sincronizzate dal componente.

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

Passaggi successivi

• Scopri come eseguire il deployment di un'applicazione Windows.
• Leggi la breve introduzione di Microsoft sui container Windows.
• Leggi le linee guida di Microsoft sulla scelta delle immagini di base dei container.
• Leggi ulteriori informazioni sulla compatibilità delle versioni del container di Microsoft su Windows.