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

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

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

Creazione di un cluster utilizzando i node pool Windows Server

In questa sezione, creerai un cluster che utilizza un container 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 node pool.
  4. Ottieni le credenziali kubectl.
  5. Attendi l'inizializzazione del cluster.

Configura i service account IAM per GKE

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

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

console

  1. Vai alla pagina Benvenuto:

    Vai a Benvenuto

  2. Nel campo Numero progetto, fai clic su Copia negli appunti.
  3. Vai alla pagina IAM:

    Vai a IAM

  4. Fai clic su Concedi l'accesso.
  5. Nel campo Nuove entità, specifica il seguente valore: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Sostituisci PROJECT_NUMBER con il numero di progetto che hai copiato.
  6. Nel menu Seleziona un ruolo, seleziona il ruolo Kubernetes Engine Default Node Service Account.
  7. Fai clic su Salva.

gcloud

  1. Trova il numero del tuo progetto Google Cloud : 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Sostituisci PROJECT_ID con l'ID progetto.

    L'output è simile al seguente:

    12345678901
  2. Concedi il ruolo roles/container.defaultNodeServiceAccount all'account di servizio predefinito di Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Sostituisci PROJECT_NUMBER con il numero di progetto del passaggio precedente.

Scegli l'immagine del nodo Windows Server

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

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

  • Orari di assistenza:
    • Le tempistiche di assistenza per un'immagine nodo Windows Server sono soggette alle tempistiche di assistenza fornite da Microsoft, come descritto nelle Norme relative all'assistenza per le immagini sistema operativo. Puoi trovare la data di fine del supporto per le immagini dei nodi GKE Windows utilizzando il comando gcloud container get-server-config come descritto nella sezione Mapping 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 del tuo pool di nodi, ma non esegui l'upgrade del pool di nodi a versioni GKE più recenti che hanno come target versioni SAC più recenti, non puoi creare nuovi nodi nel node pool al termine del ciclo di vita del supporto per la versione SAC. Scopri di più sul supporto di Google per il sistema operativo Windows Server. Consigliamo di utilizzare LTSC per il suo ciclo di vita 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 non sia più supportata mentre la versione stabile di GKE è ancora disponibile.
  • Compatibilità e complessità delle versioni:
    • Scegli SAC solo se puoi eseguire l'upgrade del node pool e dei container in esecuzione regolarmente. GKE aggiorna periodicamente la versione SAC utilizzata per i node pool Windows nelle nuove versioni di GKE, quindi la scelta di SAC per il tipo di immagine depool di nodiol richiede di ricompilare più spesso i container.
    • 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 manutenzione 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à delle versioni:
      • I container Windows Server creati per LTSC non vengono eseguiti sui nodi SAC e viceversa.
      • I container Windows Server creati per una versione LTSC o SAC specifica non vengono eseguiti su altre versioni LTSC o SAC senza essere ricompilati per essere destinati all'altra versione.
    • La creazione delle immagini dei container Windows Server come immagini multi-arch che possono essere destinate a più versioni di Windows Server può aiutarti a gestire questa complessità di controllo delle versioni.
  • Nuove funzionalità:
    • Le nuove funzionalità di Windows Server vengono in genere introdotte prima nelle versioni SAC. Per questo motivo, le nuove funzionalità di GKE Windows potrebbero essere introdotte prima nei node pool SAC.
    • Prendi in considerazione SAC se utilizzi funzionalità non ancora disponibili nella versione LTSC.

  • Runtime container:

    • Per le immagini dei nodi Windows Server LTSC e SAC, il runtime del container può essere Docker o containerd. Per la versione del nodo GKE 1.21.1-gke.2200 e successive, ti consigliamo di utilizzare il runtime containerd. Per maggiori informazioni, consulta 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à, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Crea un cluster e i node pool

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

Data la sua importanza, ti consigliamo di attivare lo scaling automatico 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 \
    --location=CONTROL_PLANE_LOCATION \
    --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.
  • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.
  • --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 nativo con gli IP alias.
  • NUMBER_OF_NODES: il numero di nodi Linux che crei. Devi fornire risorse di calcolo sufficienti per eseguire i componenti aggiuntivi del cluster. Questo è un campo facoltativo e, se omesso, viene utilizzato il valore predefinito 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ù maturo in cui è disponibile la versione.
  • CHANNEL: il canale di rilascio in cui registrare il cluster, che può essere rapid, regular, stable o None. Per impostazione predefinita, il cluster è registrato nel canale di rilascio regular, a meno che non venga specificato almeno uno dei seguenti flag: --cluster-version, --release-channel, --no-enable-autoupgrade e --no-enable-autorepair. Devi specificare None se scegli una versione del cluster e non vuoi che il cluster venga registrato in un canale di rilascio.

Ti consigliamo vivamente di specificare un account di servizio IAM con privilegi minimi che i nodi possono utilizzare al posto del account di servizio predefinito di Compute Engine. Per scoprire come creare un account di servizio con privilegi minimi, vedi Utilizzare un service account con privilegio minimo minimi.

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

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

Sostituisci SERVICE_ACCOUNT_NAME con il nome del service account con privilegi minimi.

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

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --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 tuo pool di nodi Windows Server.
  • CLUSTER_NAME: il nome del cluster che hai creato sopra.

  • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

  • IMAGE_NAME: puoi specificare uno dei seguenti valori:

    • WINDOWS_LTSC_CONTAINERD: Windows Server LTSC con containerd. Questo è il tipo di immagine per le immagini del sistema operativo Windows Server 2022 e 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 saperne di più su queste immagini dei nodi, consulta la sezione Scegliere l'immagine del nodo Windows.

  • --no-enable-autoupgrade disattiva l'upgrade automatico dei nodi. Consulta la sezione Upgrade dei pool di nodi Windows Server prima dell'attivazione.

  • 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 macchine f1-micro e g1-small non sono supportati. Ogni tipo di macchina viene fatturato in modo diverso. Per ulteriori informazioni, consulta il listino prezzi dei tipi di macchine.

  • WINDOWS_OS_VERSION: definisce la versione del sistema operativo Windows da utilizzare per il tipo di immagine WINDOWS_LTSC_CONTAINERD. Questo è un flag facoltativo. Se non specificata, la versione del sistema operativo predefinita utilizzata sarà LTSC2019. Imposta il valore su ltsc2022 per creare unpool di nodil Windows Server 2022. Imposta il valore su ltsc2019 per creare un pool di nodi Windows Server 2019.

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

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --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 \
    --location=us-central1 \
    --windows-os-version=ltsc2022

Console

  1. Nella console Google Cloud , vai alla pagina Crea un cluster Kubernetes.

    Vai a Crea un cluster Kubernetes

  2. Nella sezione Impostazioni di base del cluster, completa quanto segue:
    1. Inserisci il nome del cluster.
    2. Per Tipo di località, seleziona la regione o zona che preferisci per il tuo cluster.
    3. In Versione del control plane, seleziona un canale di rilascio o scegli di specificare una versione statica. La versione statica deve essere 1.16.8-gke.9 o successive.
  3. Nel riquadro di navigazione, in Pool di nodi, fai clic su default-pool per creare il pool di nodi Linux. Quando configuri questo pool di nodi, devi fornire risorse di calcolo sufficienti per eseguire i componenti aggiuntivi del cluster. Devi anche disporre di una quota di risorse disponibile per i nodi e le relative risorse (come le route firewall).
  4. Nella parte superiore della pagina, fai clic su Aggiungi node pool per creare ilpool di nodil Windows Server.
  5. Nella sezione Dettagli del pool di nodi, completa quanto segue:
    1. Inserisci un nome per il pool di nodi.
    2. Per i nodi della versione statica, scegli la Versione del nodo.
    3. Inserisci il numero di nodi da creare nel pool di nodi.

  6. 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 del nodo:

      • Long-Term Servicing Channel di Windows con Docker
      • Long-Term Servicing Channel di Windows con containerd
      • Canale semestrale di Windows con Docker
      • Canale semestrale di Windows con containerd

      Per saperne di più, consulta la sezione Scegliere l'immagine del nodo Windows.

    2. Scegli la configurazione macchina predefinita da utilizzare per le istanze. n1-standard-2 è la dimensione minima consigliata, in quanto i nodi Windows Server richiedono risorse aggiuntive. I tipi di macchine f1-micro e g1-small non sono supportati. Ogni tipo di macchina viene fatturato in modo diverso. Per ulteriori informazioni, consulta il listino prezzi dei tipi di macchine.

  7. Nel riquadro di navigazione, seleziona il nome del pool di nodi Windows Server. In questo modo tornerai alla pagina Dettagli del node pool.

    1. In Automazione, deseleziona la casella di controllo Abilita upgrade automatico dei nodi. Esamina la sezione Upgrade dei pool di nodi Windows Server prima di attivare l'upgrade automatico.

  8. 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 nativo con gli IP alias.

  9. Fai clic su Crea.

Terraform

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

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

  initial_node_count = 1
}

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

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

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

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

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

Recuperare le credenziali di kubectl

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

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

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

Attendi l'inizializzazione del cluster

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

Per assicurarti che il webhook sia 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 node pool (uno Linux e uno Windows), puoi eseguire il deployment di un'applicazione Windows.

Mapping delle versioni di GKE e Windows

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

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

gcloud beta container get-server-config

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

  1. Imposta le seguenti variabili:

    CLUSTER_NAME=CLUSTER_NAME \
NODE_POOL_NAME=NODE_POOL_NAME \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • NODE_POOL_NAME: il nome del pool di nodi Windows Server.
    • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

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

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

  3. Ottieni le versioni di Windows Server per NODE_POOL_VERSION:

    gcloud beta container get-server-config \
    --location=$CONTROL_PLANE_LOCATION \
    --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

Eseguire l'upgrade dei node pool Windows Server

I requisiti di compatibilità della versione del container Windows Server significano che le tue immagini container potrebbero dover essere ricompilate in modo che corrispondano alla versione di Windows Server per una nuova versione di GKE prima di eseguire l'upgrade dei tuoi node pool.

Per garantire che le immagini container rimangano compatibili con i tuoi nodi, ti consigliamo di controllare il mapping delle versioni e di creare le immagini container di Windows Server come immagini multi-arch in grado di 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 sulla versione GKE attuale sia su quella successiva prima di richiamare manualmente un upgrade del pool di nodi GKE. Gli upgrade pool di nodi pool devono essere eseguiti regolarmente perché i nodi non possono essere più di due versioni secondarie precedenti alla versione del control plane.

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

Consigliamo di attivare l'upgrade automatico dei nodi solo se crei continuamente immagini container Windows Server multi-architettura che hanno come target le versioni più recenti di Windows Server, soprattutto se utilizzi Windows Server SAC come tipo di immagine 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à di versione.

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 andrebbero persi quando il nodo viene ricreato da GKE. GKE rende disponibili gli aggiornamenti di Windows aggiornando periodicamente le immagini dei nodi Windows Server utilizzate nelle nuove release di GKE. Può esserci un ritardo tra il momento in cui Microsoft rilascia gli aggiornamenti di Windows e quello in cui sono disponibili in GKE. Quando vengono rilasciati aggiornamenti della sicurezza critici, GKE aggiorna le immagini dei nodi Windows Server il più rapidamente possibile.

Controllare la comunicazione tra i pod e i servizi Windows

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

Puoi avere un container Windows Server sui cluster in cui sono abilitati i criteri 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 control plane o i nodi eseguono versioni precedenti, puoi eseguire la migrazione dei node pool a una versione che supporta le policy di rete eseguendo l'upgrade dei node pool e del control plane alla versione 1.22.2 o successive di GKE. 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 sui container Windows Server prima dell'attivazione della funzionalità, diventano attivi.

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

Visualizzazione e query dei log

La registrazione è abilitata automaticamente nei cluster GKE. Puoi visualizzare i log dei container e quelli 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 utilizzando Remote Desktop Protocol (RDP)

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

Creazione di immagini multi-architettura

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

Utilizzo di gMSA

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

  1. Configura i nodi Windows Server nel cluster in modo che si uniscano automaticamente al tuo dominio AD. Per istruzioni, vedi Configurare i nodi Windows Server per aggiungere automaticamente un dominio Active Directory.

  2. Crea e concedi a gMSA l'accesso al gruppo di sicurezza creato automaticamente dal servizio di unione al dominio. Questo passaggio deve essere eseguito su un computer con accesso amministrativo al tuo dominio AD.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

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

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del pool di nodi Windows Server. Il gruppo di sicurezza creato automaticamente ha lo stesso nome del pool di nodil 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 riportate nel tutorial Configurare gMSA per pod e container Windows.

Eliminazione dei node pool 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
    --location=CONTROL_PLANE_LOCATION

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, quindi 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 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, alcune funzionalità di GKE non sono supportate.

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

Local External Traffic Policy sul pool di nodi Windows è supportata solo con GKE versione v1.23.4-gke.400 o successive.

Altri prodotti Google Cloud che vuoi utilizzare con i cluster GKE potrebbero non supportare i node pool 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, vedi Problemi noti.

Impossibile avviare i pod Windows

Una mancata corrispondenza tra la versione del container Windows Server e il nodo Windows che tenta di eseguire il container può impedire l'avvio dei pod Windows.

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

Errori pull immagine

Le immagini container Windows Server e i singoli livelli che le compongono possono essere piuttosto grandi. Le loro dimensioni possono causare il timeout e l'errore di Kubelet durante il download e l'estrazione dei livelli del container.

Potresti aver riscontrato questo problema se visualizzi i messaggi di errore "Failed to pull image" (Impossibile estrarre l'immagine) o "Image pull context cancelled" (Contesto di estrazione dell'immagine annullato) o lo stato ErrImagePull per i tuoi pod.

Se il pull dell'immagine 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 il pull dei contenitori Windows Server:

  • Dividi i livelli dell'applicazione dell'immagine container Windows Server in livelli più piccoli che possono essere estratti e recuperati più rapidamente. In questo modo, la memorizzazione nella cache dei livelli di Docker diventa più efficace e i tentativi di pull delle immagini hanno più probabilità di riuscire. Per saperne di più sui livelli, consulta l'articolo di Docker Storage drivers.

  • Connettiti ai nodi Windows Server e utilizza manualmente il comando docker pull nelle immagini container prima di creare i pod.

  • Imposta il flag image-pull-progress-deadline per il servizio kubelet in modo da aumentare il timeout per il pull delle immagini dei 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 stata apportata correttamente.

      PS C:\> reg query ${regkey} /v ${name}

    4. Riavvia il servizio kubelet in modo che il nuovo flag abbia effetto.

      PS C:\> Restart-Service kubelet

    5. Verifica che il servizio kubelet sia stato riavviato correttamente.

      PS C:\> Get-Service kubelet # ensure state is Running

La famiglia di immagini ha raggiunto la fine del ciclo di vita

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

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

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

Timeout durante la creazione pool di nodi

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

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

I nodi Windows diventano NotReady con l'errore: "PLEG is not healthy" (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 Windows. Per risolvere il problema, riavvia il nodo Windows Server. Una soluzione alternativa consigliata per evitare questo problema è limitare la velocità di creazione dei pod Windows a un pod ogni 30 secondi.

TerminationGracePeriod incoerente

Il timeout del sistema Windows per il contenitore potrebbe essere diverso dal periodo di tolleranza che configuri. Questa differenza può causare l'interruzione forzata del contenitore 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 locale del container in fase di creazione dell'immagine. Se modifichi il timeout di Windows, potresti anche dover modificare TerminationGracePeriodSeconds in modo che corrisponda.

Problemi di connettività di rete

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

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

Problemi di avvio dei nodi

Se i nodi non vengono avviati nel cluster o non riescono a unirsi al cluster correttamente, esamina le informazioni diagnostiche fornite nell'output della porta seriale del nodo.

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

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

Sostituisci quanto segue:

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

Servizi non raggiungibili a intermittenza nei nodi Windows con cluster che eseguono la versione 1.24 o precedenti

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

Per i cluster GKE che eseguono la versione 1.24 o precedente, con tutti i nodi Windows che hanno avuto un evento che ha riavviato kube-proxy, ad esempio l'avvio del nodo, l'upgrade del nodo, il 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 è migliorato notevolmente. Per maggiori dettagli su questo miglioramento, consulta la pull request su GitHub. Se riscontri questo problema, ti consigliamo di eseguire l'upgrade del control plane del cluster alla versione 1.25 o successive.

Passaggi successivi