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 con Microsoft Windows Server. Con questo cluster puoi utilizzare Windows Server containers. I container Microsoft Hyper-V non sono attualmente supportati. Analogamente ai container Linux, i container Windows Server e fornire l'isolamento di processi e spazi dei nomi.

Un nodo Windows Server richiede più risorse di un tipico Linux. I nodi Windows Server richiedono le risorse aggiuntive per eseguire il sistema operativo Windows e i componenti Windows Server che non possono essere eseguiti nei container. Dal giorno I nodi Windows Server richiedono più risorse, risorse allocabili sono inferiori rispetto a quelli dei 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, devi creare le immagini dei nodi container di Windows Server su Windows Server versione 2019 (LTSC), Windows Server versione 20H2 (SAC) o Windows Server versione 2022 (LTSC). Un singolo cluster può avere più finestre Pool di nodi server che utilizzano versioni di Windows Server diverse, ma ogni singola versione il pool di nodi può utilizzare una sola versione di Windows Server.

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

• Tempistiche dell'assistenza:
  .
  • Il tempo di supporto per l'immagine di un nodo Windows Server è soggetto ai tempi dell'assistenza forniti da Microsoft, come descritto in Criteri di supporto per le immagini sistema operativo. Puoi trovare la data di fine del supporto per il nodo Windows di GKE di immagini utilizzando il comando gcloud container get-server-config descritto in Mappatura delle versioni GKE e Windows .
  • Le versioni SAC sono supportate da Microsoft solo per 18 mesi dopo la loro nella release iniziale. Se scegli SAC come tipo di immagine per il pool di nodi, ma non eseguire l'upgrade del pool di nodi a versioni GKE più recenti che hanno come target versioni SAC più recenti, non puoi creare nuovi nodi 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 perché ha un ciclo di vita dell'assistenza 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, è possibile rischio che l'immagine del pool di nodi SAC non sia più supportata mentre La versione GKE è ancora disponibile.
• Compatibilità e complessità delle versioni:
  .
  • Scegli SAC solo se puoi eseguire l'upgrade del pool di nodi e i container in esecuzione al suo interno. GKE aggiorna periodicamente la versione del SAC utilizzata per i pool di nodi Windows nei nuovi Release GKE, quindi scegliere SAC per il tipo di immagine del pool di nodi richiede di ricreare i container più spesso.
  • Se hai dubbi su quale tipo di immagine Windows Server utilizzare, consigliamo di scegliere Windows Server LTSC per evitare incompatibilità delle versioni durante l'upgrade del pool di nodi. Per ulteriori informazioni, vedi Canali di servizio di Windows Server: LTSC e SAC nella documentazione di Microsoft.
  • Sia Windows Server Core e Nano Server può essere utilizzata come immagine di base per i 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 essere eseguiti su altre versioni LTSC o SAC senza essere ricompilati per scegliere come target l'altra versione.
  • Crea le immagini container di Windows Server come immagini multi-arch che possono avere come target più versioni di Windows Server possono aiutarti a gestire la complessità del controllo delle versioni.
• Nuove funzionalità:
  .
  • Le nuove funzionalità di Windows Server vengono generalmente introdotte nelle versioni di SAC per prima cosa. Per questo motivo, le nuove funzionalità di GKE Windows nei pool di nodi SAC.
  • Prendi in considerazione il programma SAC se dipendi da funzionalità non ancora disponibili nel programma LTSC .

• Runtime del container:

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

Aggiorna e configura gcloud

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

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

• Assicurati di disporre dell'autorizzazione corretta per creare cluster. Come minimo, dovrebbe 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 e un pool di nodi Linux. Non puoi creare un cluster utilizzando solo Pool di nodi server. Il pool di nodi Linux è necessario per eseguire componenti critici del cluster on.

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 entra in un RECONCILE per diversi minuti mentre il piano di controllo viene aggiornato.

Ottieni credenziali kubectl

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

gcloud container clusters get-credentials CLUSTER_NAME

Per maggiori informazioni sul comando get-credentials, consulta l'SDK get-credentials documentazione.

Attendi l'inizializzazione del cluster

Prima di utilizzare il cluster, attendi alcuni secondi fino a quando Creazione di windows.config.common-webhooks.networking.gke.io completata. Questo webhook aggiunge pianificazione delle tolleranze per i pod creati con kubernetes.io/os: windows selettore di nodi per assicurarsi 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 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 LTSC ogni due o tre anni. Queste nuove versioni sono in genere disponibili in delle nuove versioni secondarie di GKE. All'interno di un oggetto Versione secondaria di GKE le versioni LTSC e SAC solitamente rimangono fisse.

per vedere la mappatura delle versioni tra le versioni GKE e Windows Le versioni server: utilizza 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 GKE nel tuo cluster, esegui questi passaggi in un la 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 nel NODE_POOL_VERSION variabile:

   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

La compatibilità delle versioni dei container Windows Server e requisiti 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 garantire che le immagini container rimangano compatibili con i tuoi nodi, consigliamo di controllare la mappatura delle versioni e la build le immagini container di Windows Server come immagini multi-arch che possono scegliere come target più versioni di Windows Server. Dopodiché puoi aggiornare i deployment di container per scegliere come target le immagini multi-arch che funzioneranno su entrambe le l'attuale versione di GKE e quella successiva prima di richiamare manualmente un Upgrade del pool di nodi GKE. Upgrade manuali del pool di nodi devono essere eseguiti regolarmente perché i nodi non possono essere più di due versioni secondarie dietro la versione del piano di controllo.

Ti consigliamo di iscriverti per ricevere le notifiche di upgrade utilizzando Pub/Sub per ricevere in modo proattivo aggiornamenti sulle nuove versioni di GKE Le versioni del sistema operativo Windows che utilizzano.

Ti consigliamo di attivare upgrade automatici dei nodi solo se crei continuamente immagini container Windows Server multi-arch che avere come target le versioni più recenti di Windows Server, soprattutto se utilizzi Windows SAC server come tipo di immagine del nodo. Gli upgrade automatici dei nodi hanno meno probabilità di causare problemi con il tipo di immagine del nodo LTSC di Windows Server, ma sussiste ancora un rischio di problemi di incompatibilità delle versioni.

Aggiornamenti di Windows

Gli aggiornamenti di Windows sono disabilitati per i nodi Windows Server. Automatica aggiornamenti possono causare riavvii dei nodi in momenti imprevedibili e qualsiasi Gli aggiornamenti installati dopo l'avvio di un nodo andranno persi quando il nodo viene ricreato da GKE. GKE rende disponibili gli aggiornamenti di Windows aggiornare periodicamente le immagini dei nodi Windows Server utilizzate nelle nuove delle release di GKE. Potrebbe verificarsi un ritardo tra il momento in cui vengono aggiornati gli aggiornamenti di Windows vengono rilasciate da Microsoft e quando sono disponibili in GKE. Quando vengono rilasciati aggiornamenti critici della sicurezza, GKE aggiorna la il più rapidamente possibile.

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

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

Puoi avere un container Windows Server sui cluster criterio di rete abilitato in GKE 1.22.2 e versioni successive. Questo è disponibile per i cluster che utilizzano l'WINDOWS_LTSC WINDOWS_LTSC_CONTAINERD tipi di immagini dei nodi.

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

Dopo aver attivato il criterio di rete, tutti i criteri configurati in precedenza, inclusi che non funzionavano sui container Windows Server prima dell'abilitazione attiva.

Alcuni cluster non possono essere utilizzati con i container Windows Server su cluster con criterio di rete abilitato. Consulta la sezione Limitazioni per ulteriori informazioni i 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 su Windows Server nodi 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 su come connetterti, vedi Connessione a 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 da gruppo (gMSA) con i pool di nodi di Windows Server.

1. Configura i nodi Windows Server nel cluster in modo che si uniscano automaticamente ad AD dominio. Per istruzioni, vedi Configura i nodi Windows Server in modo che vengano aggiunti automaticamente a un dominio Active Directory.

2. Crea e concedi un accesso gMSA al gruppo di sicurezza creato automaticamente dal servizio di aggiunta al dominio. Questo passaggio deve essere eseguito in una macchina 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 tuo server Windows pool di nodi. Il gruppo di sicurezza creato automaticamente ha lo stesso nome di dal 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: nome di dominio completo (FQDN) dell'account di servizio che hai creato. Ad esempio, se GMSA_NAME è webapp01 e il dominio è example.com, poi DNS_HOST_NAME è webapp01.example.com.

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

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 di container Windows Server. Inoltre, alcune funzionalità sono specifiche di Linux e non per Windows. Per l'elenco completo delle funzionalità di Kubernetes supportate e non supportate, consulta la documentazione di Kubernetes.

Oltre alle funzionalità Kubernetes non supportate, esistono anche che non sono supportate.

Per i cluster GKE, le seguenti funzionalità non sono supportate con Pool di nodi 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.

Criterio del traffico esterno locale su un pool di nodi Windows è supportato solo con GKE versione v1.23.4-gke.400 o successiva.

Altri prodotti Google Cloud che vuoi utilizzare con i cluster GKE potrebbe 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 su il debug dei 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

Mancata corrispondenza della versione tra il container Windows Server e il nodo Windows che sta tentando di eseguire il container può causare l'errore per iniziare.

Se la versione per il pool di nodi Windows è 1.16.8-gke.8 o successiva, rivedi la documentazione di Microsoft per Problema di incompatibilità dei container Windows Server di febbraio 2020 e creare le tue immagini container immagini Windows di base che includono gli aggiornamenti di Windows di marzo 2020. Immagini container create in precedenza le immagini Windows di base potrebbero non essere eseguite su questi nodi Windows e possono anche del nodo con stato NotReady.

Errori di pull delle immagini

le immagini container di Windows Server e i singoli livelli da cui sono composti può essere molto grande. Le dimensioni possono causare il timeout e il mancato download di Kubelet ed estraendo i livelli container.

Potresti aver riscontrato questo problema se visualizzi il messaggio "Impossibile eseguire il pull dell'immagine" o "Immagine contesto pull annullato" messaggi di errore o uno stato ErrImagePull per di pod.

Se l'immagine pull si verifica spesso, dovresti usare pool di nodi con una CPU la specifica del container. L'estrazione dei container viene eseguita in parallelo tra i core, quindi tipi di macchine con più core riduce il tempo di pull complessivo.

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

• Suddividi i livelli di applicazione dell'immagine container di Windows Server in strati più piccoli, ciascuno dei quali può essere estratto ed estratto più rapidamente. Questo può rendere più efficace la memorizzazione nella cache dei livelli di Docker e aumentare i tentativi di pull delle immagini le probabilità di successo. 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 parametro image-pull-progress-deadline flag del servizio kubelet per aumentare il timeout per il pull del container in formato Docker.

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

  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 a questo: le seguenti:

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 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) ed è il primo pool di nodi nel cluster che utilizza un server dell'immagine.

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

I nodi Windows diventano NotReady con l'errore: "PLEG non è integro"

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

Risoluzione incoerenteGracePeriod

Il timeout del sistema Windows per il container potrebbe essere diverso dal periodo di tolleranza che configuri. 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 dei container all'indirizzo la fase di creazione dell'immagine. Se modifichi il timeout di Windows, potresti anche dover e regolare TerminaGracePeriodSeconds in modo che corrisponda.

Problemi di connettività di rete

Se riscontri problemi di connettività di rete dai container di Windows Server, il motivo potrebbe essere che il networking dei container di Windows Server spesso presuppone che una MTU di rete 1500, che non è compatibile con la MTU di Google Cloud 1460.

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

Problemi di avvio dei nodi

Se i nodi non si avviano nel cluster o non si uniscono correttamente al cluster, Rivedi le informazioni diagnostiche fornite nella porta seriale del nodo come output.

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

All'avvio di nodi Windows in cluster Kubernetes con un numero elevato di host delle regole del bilanciatore del carico di Network Service, si è verificato un ritardo nell'elaborazione delle regole. Durante il ritardo, che dura circa 30, i servizi sono irraggiungibili a intermittenza secondi per regola e il ritardo totale può essere significativo se sono presenti le regole del caso. Per scoprire di più, consulta il problema originale in GitHub.

Per i cluster GKE che eseguono la versione 1.24 o precedenti, con qualsiasi Nodi Windows con un evento che è stato riavviato kube-proxy, ad esempio nodo avvio, upgrade del nodo, riavvio manuale: qualsiasi servizio raggiunto da un pod in esecuzione su quel nodo non sarà raggiungibile finché tutte le regole non saranno sincronizzate di strumento di authoring.

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

Passaggi successivi

• Scopri come eseguire il deployment di un'applicazione Windows.
• Leggi le best practice di Microsoft breve introduzione dei container Windows.
• Letto Linee guida di Microsoft sulla scelta delle immagini di base del container.
• Informazioni su Microsoft su Windows compatibilità delle versioni del container.