Creazione di un cluster mediante i pool di nodi Windows Server

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 Windows Server containerizzati. I container 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 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. 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à:

  1. Scegli l'immagine del nodo Windows Server.
  2. Aggiorna e configura gcloud.
  3. Crea un cluster e 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.

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

  • Tempistiche dell'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 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 rilaciazione 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 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 operazioni:

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

Crea un cluster e i 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 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

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 che scegli per il cluster.
  • --enable-ip-alias attiva IP alias. L'IP alias è per i nodi Windows Server. Per saperne di più sui vantaggi, vedi Informazioni sul routing dei container nativi con IP alias
  • NUMBER_OF_NODES: il numero di nodi Linux che crei. Devi fornire risorse di calcolo sufficienti per eseguire il cluster componenti aggiuntivi. Questo è un campo facoltativo e, se omesso, utilizza il valore predefinito di 3.
  • VERSION_NUMBER: la versione specifica del cluster che utilizzi che deve essere 1.16.8-gke.9 o superiore. Se non specifichi un canale di rilascio, GKE registra il cluster nell' canale di rilascio maturo in cui è disponibile la versione in questione.
  • CHANNEL: il canale di rilascio per registrare il cluster, che può essere uno tra 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 la registrazione del cluster in un canale di rilascio.

Crea il pool di nodi di 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)

    Per ulteriori informazioni su queste immagini dei nodi, consulta Scegli l'immagine del tuo nodo Windows .

  • --no-enable-autoupgrade disattiva l'upgrade automatico dei nodi. Consulta l'articolo 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 le tariffario del tipo di macchina.

  • 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 in un pool di nodi di Windows Server 2022. Imposta il valore su ltsc2019 per creare un pool di nodi di Windows Server 2019.

L'esempio seguente mostra come creare un pool di nodi di 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

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nella sezione Impostazioni di base del cluster, completa quanto segue:

    1. Inserisci il nome del cluster.
    2. Per Tipo di località, seleziona l'area geografica o la zona desiderata per il tuo in un cluster Kubernetes.
    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.

  4. Dal riquadro di navigazione, in Pool di nodi, fai clic su default-pool per il tuo 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).

  5. Nella parte superiore della pagina, fai clic su Aggiungi pool di nodi per creare il pool di nodi Windows Server.

  6. Nella sezione Dettagli del pool di nodi, completa quanto segue:

    1. Inserisci un nome per il pool di nodi.
    2. Per i nodi versione statica, scegli la Versione nodo.
    3. Inserisci il numero di nodi da creare nel pool di nodi.

  7. Nel riquadro di navigazione, in Pool di nodi, fai clic su Nodi.

    1. Dall'elenco a discesa Tipo di immagine, seleziona uno dei seguenti nodi immagini:

      • 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

      Per ulteriori informazioni, consulta Scegliere l'immagine del nodo Windows .

    2. Scegli l'impostazione predefinita Configurazione macchina. da utilizzare per le istanze. n1-standard-2 è la dimensione minima consigliata perché i nodi Windows Server richiedono risorse aggiuntive. I tipi di macchina 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.

  8. Dal riquadro di navigazione, seleziona il nome del tuo nodo Windows Server piscina. Verrà visualizzata la 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.

  9. 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 Nodi Windows Server. Per saperne di più sui vantaggi, vedi Informazioni sul routing dei container nativi con IP alias

  10. Fai clic su Crea.

Terraform

Per creare un cluster GKE Standard e un cluster Pool di nodi server che utilizza Terraform, fai riferimento all'esempio seguente:

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

In questo esempio viene utilizzato Windows Server LTSC con containerd. Questa è l'immagine per l'immagine sistema operativo Windows Server 2022 e Windows Server 2019. Per ulteriori informazioni sulle immagini dei nodi, vedi Scegli l'immagine del tuo nodo Windows.

Per saperne di più sull'utilizzo di Terraform, consulta Supporto Terraform per GKE.

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.

Ottenere le 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 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 venga creato, esegui il seguente 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 secondarie di GKE. All'interno di una versione minore di GKE le versioni LTSC e SAC di solito rimangono invariate.

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 la risposta corretta. Per filtrare la risposta in modo da visualizzare la mappatura delle versioni per versioni GKE specifiche nel cluster, esegui i passaggi che seguono in una shell 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

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 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. Puoi quindi 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 prima di invocare 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 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 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. È 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 critici della sicurezza, GKE aggiorna la il più rapidamente possibile.

Controlla il modo in cui comunicano 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 container Windows Server sui cluster criterio di rete abilitato in GKE 1.22.2 e versioni 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 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, 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 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 cluster utilizzando RDP. Per istruzioni su come connetterti, vedi Connessione a istanze Windows nella documentazione di Compute Engine.

Creazione di immagini multi-arch

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 le istruzioni, consulta Configurare i nodi Windows Server per l'unione automatica a un dominio Active Directory.

  2. 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 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, DNS_HOST_NAME è webapp01.example.com.

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

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Accanto al cluster che vuoi modificare, fai clic su Azioni e poi su Modifica.

  3. Seleziona la scheda Nodi.

  4. Nella sezione Pool di nodi, fai clic su Elimina accanto al pool di nodi che vuoi eliminare.

  5. 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 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, sono disponibili anche che non sono supportate.

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

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 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 tenta di eseguire il contenitore può comportare l'interruzione dell'avvio dei pod Windows.

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 di cui sono composte possono essere molto grandi. Le dimensioni possono causare il timeout e il mancato download di Kubelet ed estraendo i livelli container.

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 container di Windows Server in strati più piccoli, ciascuno dei quali può essere estratto ed estratto 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 Informazioni su immagini, contenitori 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 i seguenti comandi PowerShell.

    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 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 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 aumenta 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 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 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 presuppone spesso 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 la MTU, consulta problemi noti relativi ai container Windows.

Problemi di avvio del nodo

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