Creazione di un cluster mediante 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 usare i container Windows Server. I container Microsoft Hyper-V non sono attualmente supportati. Analogamente ai container Linux, quelli Windows Server forniscono l'isolamento di processo e spazio dei nomi.

Un nodo Windows Server richiede più risorse di un nodo Linux tipico. I nodi di Windows Server hanno bisogno delle risorse aggiuntive per eseguire il sistema operativo Windows e per i componenti di 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 otterrebbero con i nodi Linux.

Creazione di un cluster mediante pool di nodi Windows Server

In questa sezione creerai un cluster che utilizza un contenitore 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 dei pool di nodi.
  4. Recupera le credenziali di kubectl.
  5. Attendi l'inizializzazione del cluster.

Scegli l'immagine del nodo Windows Server

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

Quando scegli l'immagine del nodo, considera quanto segue:

  • Tempistiche dell'assistenza:
    • Le tempistiche del supporto per un'immagine del nodo Windows Server sono soggette a quelle dell'assistenza 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 di 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 le 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. Ti consigliamo di utilizzare LTSC poiché il suo ciclo di vita del 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 diventi non supportata finché 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 regolarmente. GKE aggiorna periodicamente la versione SAC utilizzata per i pool di nodi Windows nelle nuove release di GKE, perciò la scelta di SAC per il tipo di immagine del pool di nodi richiede di ricreare 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à della versione durante l'upgrade del pool di nodi. Per ulteriori informazioni, consulta 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 container.
    • I container Windows Server hanno importanti requisiti di compatibilità della versione:
      • 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 in altre versioni LTSC o SAC senza essere stati ricreati per avere come target l'altra versione.
    • Creare le immagini container 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 in genere introdotte prima nelle versioni SAC. Di conseguenza, la nuova funzionalità GKE Windows potrebbe essere introdotta prima nei pool di nodi SAC.
    • Valuta SAC se fai affidamento su funzionalità non ancora disponibili nella release LTSC.

  • Runtime container:

    • Sia per le immagini dei nodi LTSC che per quelle 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, consulta la sezione 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 initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Crea un cluster e pool di nodi

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

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 che scegli per il cluster.
  • --enable-ip-alias attiva l'IP alias. L'IP alias è obbligatorio per i nodi Windows Server. Per saperne di più sui vantaggi, consulta Informazioni sul routing dei container nativi con IP alias.
  • NUMBER_OF_NODES: il numero di nodi Linux che hai creato. Devi fornire risorse di computing sufficienti per eseguire i componenti aggiuntivi del cluster. Questo è un campo facoltativo e, se omesso, utilizza il valore predefinito di 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 cluster nel canale di rilascio più adulto 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 cluster venga registrato 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 che scegli per il pool di nodi di Windows Server.
  • CLUSTER_NAME: il nome del cluster che hai creato in precedenza.

  • IMAGE_NAME: puoi specificare uno dei seguenti valori:

    • WINDOWS_LTSC_CONTAINERD: LTSC di Windows Server con containerd. Questo è il tipo di immagine sia del sistema operativo Windows Server 2022 che di Windows Server 2019
    • WINDOWS_SAC_CONTAINERD: SAC di Windows Server con containerd (non supportata dopo il 9 agosto 2022)
    • WINDOWS_LTSC: LTSC di Windows Server con Docker
    • WINDOWS_SAC: SAC di Windows Server con Docker (non supportato dopo il 9 agosto 2022)

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

  • --no-enable-autoupgrade disabilita l'upgrade automatico dei nodi. Consulta la pagina relativa all'upgrade dei pool di nodi Windows Server prima di abilitarla.

  • MACHINE_TYPE_NAME: definisce il tipo di macchina. n1-standard-2 è il tipo di macchina minimo consigliato, poiché 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 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 specificata, la versione predefinita del sistema operativo utilizzata sarà LTSC2019. Imposta il valore su ltsc2022 per creare un pool di nodi di Windows Server 2022. Imposta il valore su ltsc2019 per creare un pool di nodi Windows Server 2019.

Nell'esempio seguente viene illustrato 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 per il cluster.
    2. In Tipo di località, seleziona l'area geografica o la zona desiderata per il cluster.
    3. In Versione 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. Nel riquadro di navigazione, in Pool di nodi, fai clic su default-pool per creare il tuo pool di nodi Linux. Quando configuri questo pool di nodi, devi fornire risorse di computing sufficienti per eseguire i componenti aggiuntivi del cluster. Devi inoltre disporre di una quota di risorse per i nodi e le relative risorse (come le route firewall).

  5. Nella parte superiore della pagina, fai clic su Aggiungi pool di nodi per creare il tuo 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 di 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 una delle seguenti immagini dei nodi:

      • 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 la sezione Scegli l'immagine del nodo Windows.

    2. Scegli l'opzione Configurazione macchina predefinita da utilizzare per le istanze. n1-standard-2 è la dimensione minima consigliata, poiché 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 del tipo di macchina.

  8. Nel riquadro di navigazione, seleziona il nome del tuo pool di nodi Windows Server. Viene visualizzata la pagina Dettagli del pool di nodi.

    1. In Automazione, deseleziona la casella di controllo Abilita upgrade automatico dei nodi. Consulta la sezione Upgrade dei pool di nodi Windows Server prima di abilitare 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 i nodi Windows Server. Per saperne di più sui vantaggi, consulta Informazioni sul routing dei container nativi con IP alias.

  10. Fai clic su Crea.

Terraform

Puoi utilizzare il provider Google Terraform per creare un cluster GKE con un pool di nodi Windows Server.

Aggiungi questo blocco alla tua configurazione Terraform:

resource "google_container_cluster" "cluster" {
  project  = "PROJECT_ID"
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  min_master_version = "VERSION_NUMBER"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name       = "linux-pool"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name       = "NODE_POOL_NAME"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type   = "IMAGE_NAME"
    machine_type = "MACHINE_TYPE_NAME"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto in cui viene creato il cluster.
  • CLUSTER_NAME: il nome del cluster GKE.
  • LOCATION: la località (regione o zona) in cui viene creato il cluster.
  • VERSION_NUMBER: deve essere 1.16.8-gke.9 o successiva.
  • NODE_POOL_NAME: il nome che scegli per il pool di nodi di Windows Server.

  • IMAGE_NAME: puoi specificare uno dei seguenti valori:

    • WINDOWS_LTSC_CONTAINERD: LTSC di Windows Server con containerd. Questo è il tipo di immagine sia del sistema operativo Windows Server 2022 che di Windows Server 2019.
    • WINDOWS_SAC_CONTAINERD: SAC di Windows Server con containerd (non supportata dopo il 9 agosto 2022)
    • WINDOWS_LTSC: LTSC di Windows Server con Docker
    • WINDOWS_SAC: SAC di Windows Server con Docker (non supportato dopo il 9 agosto 2022)

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

  • MACHINE_TYPE_NAME: definisce il tipo di macchina. n1-standard-2 è il tipo di macchina minimo consigliato, poiché 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 del tipo di macchina.

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.

Recupera le credenziali kubectl

Utilizza il comando get-credentials per abilitare kubectl al funzionamento con il cluster che hai creato.

gcloud container clusters get-credentials CLUSTER_NAME

Per ulteriori informazioni sul comando get-credentials, consulta la documentazione relativa all'SDK get-credentials.

Attendi l'inizializzazione del cluster

Prima di utilizzare il cluster, attendi qualche secondo 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 garantirne l'esecuzione sui nodi Windows Server. Inoltre, convalida il pod per garantire 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 di GKE e Windows

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

Per visualizzare la mappatura delle versioni tra le versioni di GKE e le versioni 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 nella 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. Recupera 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 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 Windows Server indicano che potrebbe essere necessario ricreare le immagini container 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 restino compatibili con i nodi, ti consigliamo di controllare il mapping delle versioni e 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 da scegliere come target le immagini multi-arch che funzioneranno sia nella versione attuale di GKE che in 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 avere più di due versioni secondarie dopo la versione del piano di controllo.

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

Ti consigliamo di abilitare gli upgrade automatici dei nodi solo se crei continuamente immagini container di Windows Server multi-arch che hanno come target le versioni più recenti di Windows Server, soprattutto se utilizzi Windows Server SAC come tipo di immagine dei nodi. È meno probabile che gli upgrade automatici dei nodi causino problemi con il tipo di immagine dei nodi LTSC di Windows Server, ma esiste ancora il rischio che si verifichino 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 se 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 di Windows da Microsoft e la disponibilità in GKE. Quando vengono rilasciati aggiornamenti critici della sicurezza, 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 servizi e i pod di Windows comunicano utilizzando i criteri di rete.

Puoi avere un container Windows Server sui cluster in cui è abilitato il criterio di rete 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 eseguono versioni precedenti, puoi eseguire la migrazione dei pool di nodi a una versione che supporti 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 nei cluster in cui è abilitato il criterio di rete. Per ulteriori dettagli, consulta la sezione Limitazioni.

Visualizzazione ed esecuzione di query sui log

Logging è abilitato automaticamente nei cluster GKE. Puoi visualizzare i log dei container e i log 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 su come connettersi, consulta Connessione alle istanze Windows nella documentazione di Compute Engine.

Creazione di immagini multi-arcate

Puoi creare manualmente le immagini multi-archetto o utilizzare un builder di Cloud Build. Per le istruzioni, consulta Creazione di immagini multi-archetto 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 tuo cluster in modo che vengano aggiunti automaticamente al dominio AD. Per le istruzioni, consulta Configurare i nodi Windows Server per l'unione automatica a un dominio Active Directory.

  2. Creare e concedere un accesso gMSA al gruppo di sicurezza creato automaticamente dal servizio di join 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 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, allora DNS_HOST_NAME è webapp01.example.com.

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

Eliminazione dei 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, segui questi 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à 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à di GKE che non sono supportate.

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

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

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 di pod e sui servizi.

Problemi relativi ai nodi containerd

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

Impossibile avviare i pod Windows

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

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

Errori di pull dell'immagine

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

Questo problema potrebbe essersi verificato se vengono visualizzati i messaggi di errore "Impossibile eseguire il pull dell'immagine" o "Contesto dell'immagine pull annullato" oppure se viene visualizzato uno stato ErrImagePull per i tuoi pod.

Se l'immagine pull si verifica di frequente, devi utilizzare 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 macchine 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 del container Windows Server in livelli più piccoli da cui è possibile estrarre ed estrarre più rapidamente. Ciò può rendere più efficace la memorizzazione nella cache dei livelli di Docker e aumentare le probabilità di successo in caso di nuovi tentativi di pull delle immagini. Per scoprire di più sui livelli, consulta l'articolo 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 per 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 riuscita.

      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. Conferma 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, viene visualizzato 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 di 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'immagine Windows Server.

Per risolvere questo 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 consigliata per evitare questo problema è limitare la frequenza con cui vengono creati i pod Windows a un pod ogni 30 secondi.

Periodo di tolleranza per fine incoerente

Il timeout di 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 dell'immagine. Se modifichi il timeout di Windows, potresti anche dover modificare TerminazioneGracePeriodsecondi di conseguenza.

Problemi di connettività di rete

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

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

Problemi di avvio dei nodi

Se i nodi non si avviano nel cluster o non riescono a unirsi al cluster, esamina le informazioni diagnostiche fornite nell'output della porta di serie 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 in nodi Windows con cluster che esegue la versione 1.24 o precedente

Quando avvii i nodi Windows in cluster Kubernetes con un numero elevato di regole del bilanciatore del carico Host Network Service, 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 ci sono abbastanza regole. Per saperne di più, consulta il problema originale in GitHub.

Per i cluster GKE che eseguono la versione 1.24 o precedenti, con tutti i nodi Windows che hanno subito un evento che ha riavviato kube-proxy, ad esempio avvio, upgrade del nodo o riavvio manuale, tutti i servizi raggiunti da un pod in esecuzione su quel nodo non saranno raggiungibili finché tutte le regole non vengono 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 pagina relativa alla 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