Creazione di un cluster utilizzando i node pool Windows Server

In questa pagina scopri come creare un cluster Google Kubernetes Engine (GKE) con node pool che eseguono Microsoft Windows Server. Con questo cluster, puoi utilizzare i container Windows Server. I container 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 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 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 al account di servizio Compute Engine predefinito: 
    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 l'esecuzione su GKE, le immagini dei nodi dei container Windows Server devono essere create sulla versione 2022 (LTSC) di Windows Server consigliata o sulla versione 2019 (LTSC) di Windows Server, che è ritirata da GKE e non può essere utilizzata per i pool di nodi che eseguono GKE versione 1.37 o successive. 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 una sola versione di Windows Server.

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

  • Aggiornamenti: utilizza LTSC2022, perché LTSC2019 è ritirato da GKE. Tieni presente quanto segue su LTSC2019:
    • Nessun aggiornamento dell'immagine del nodo: GKE non fornisce aggiornamenti dell'immagine del nodo per LTSC2019 a causa di problemi di stabilità con gli aggiornamenti all'immagine sottostante poiché Microsoft ha terminato il supporto Mainstream per l'immagine. Le immagini dei nodi GKE sono bloccate alla versione di dicembre 2025 dell'immagine sottostante. Per ulteriori informazioni, consulta Windows Server 2019.
    • Compatibilità con la versione 1.37: per GKE versione 1.37 e successive, non puoi utilizzare LTSC2019. Non puoi creare nuovi node pool con LTSC2019 e con 1.37 né eseguire l'upgrade dei node pool LTSC2019 esistenti a 1.37.
  • Orari di assistenza:
  • Compatibilità e complessità delle versioni:
    • Sia Windows Server Core che Nano Server possono essere utilizzati come immagine di base per i container.
    • La creazione di immagini container di 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.

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
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

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 i componenti aggiuntivi del cluster critici.

Prima di creare un cluster utilizzando i node pool Windows Server, consulta la sezione Upgrade dei node pool Windows Server.

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 \
    --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 nativi 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, utilizza il valore predefinito di 3.
  • VERSION_NUMBER: la versione specifica del cluster che vuoi utilizzare. 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 a cui registrare il cluster, che può essere rapid, regular, stable o None (ritirato). Per impostazione predefinita, il cluster è registrato nel canale di rilascio regular.

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, consulta 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=WINDOWS_LTSC_CONTAINERD \
    --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.
  • 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 macchina.
  • WINDOWS_OS_VERSION: questo è un flag facoltativo che definisce la versione del sistema operativo Windows da utilizzare per il tipo di immagine WINDOWS_LTSC_CONTAINERD. Per GKE versione 1.37 e successive, puoi utilizzare solo LTSC2022 (ltsc2022). Per la versione 1.36 o precedenti, ti consigliamo di impostare esplicitamente il valore su ltsc2022. In caso contrario, GKE utilizza LTSC2019 (ltsc2019), che non è consigliato in quanto è deprecato da GKE.

L'esempio seguente 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 una regione o una zona per il cluster.
    3. In Canali di rilascio, seleziona un Canale di rilascio e, facoltativamente, una Versione di destinazione.
  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. 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 la seguente immagine del nodo:

      • Long-Term Servicing Channel 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, 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 dei tipi di macchina.

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

  8. Fai clic su Crea.

Terraform

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

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 del sistema operativo Windows Server 2022 e Windows Server 2019 (ritirate da GKE). Per saperne di più sulle immagini dei nodi, consulta 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 finché non viene creato 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, esegue la convalida del 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 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 rimangono in genere fisse.

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

gcloud beta container get-server-config

La mappatura delle versioni viene restituita nel campo windowsVersionMaps della risposta. Per filtrare la risposta e visualizzare 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_LTSC:

    gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_LTSC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

    L'output è simile al seguente:

    10.0.17763.1577

Eseguire l'upgrade dei node pool Windows Server

I requisiti di compatibilità della versione del contenitore del server Windows implicano che potrebbe essere necessario ricompilare le immagini container in modo che corrispondano alla versione di Windows Server per una nuova versione di GKE prima di eseguire l'upgrade dei pool di nodi. Esamina i seguenti consigli sull'upgrade di questo tipo di pool di nodi:

  • Se necessario, impedisci gli upgrade automatici dei nodi con le esclusioni dalla manutenzione.
  • Assicurati che le immagini container rimangano compatibili con i tuoi nodi controllando il mapping delle versioni e creando 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 di GKE attuale sia su quella successiva prima di richiamare manualmente un upgrade del pool di nodi GKE.
  • Se impedisci gli upgrade automatici dei nodi, esegui regolarmente gli upgrade pool di nodi pool perché i nodi non possono essere precedenti di più di due versioni secondarie rispetto alla versione del control plane.
  • Per ricevere in modo proattivo aggiornamenti sulle nuove versioni di GKE e sulle versioni del sistema operativo Windows che utilizzano, iscriviti alle notifiche di upgrade.
  • Consenti a GKE di eseguire upgrade automatici dei nodi solo se crei continuamente immagini container Windows Server multi-architettura che hanno come target le ultime versioni di Windows Server. Gli upgrade automatici dei nodi non causano problemi con il tipo di immagine del nodo Windows Server LTSC, ma esiste comunque il rischio di riscontrare problemi di incompatibilità delle versioni.

Aggiornamenti di Windows

Gli aggiornamenti di Windows sono disabilitati per i nodi Windows Server. Gli aggiornamenti automatici possono causare riavvii dei nodi in momenti imprevedibili e tutti gli aggiornamenti di Windows installati dopo l'avvio di un nodo 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ò verificarsi un ritardo tra il momento in cui Microsoft rilascia gli aggiornamenti di Windows e il momento 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 la comunicazione tra i pod e i servizi Windows 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'abilitazione della funzionalità, diventano attivi.

Alcuni cluster non possono essere utilizzati con i container Windows Server sui cluster con il criterio di rete abilitato. 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 quelli di altri servizi sui nodi Windows Server utilizzando Kubernetes Engine Monitoring.

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

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

Utilizzo di gMSA

I passaggi seguenti 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 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 nodi 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) del 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 nell'esercitazione 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

Le seguenti funzionalità non sono supportate con i node pool Windows Server:

Per limitazioni specifiche con altri prodotti Google Cloud che potresti voler utilizzare con i cluster GKE, consulta la documentazione relativa a quel prodotto.

Risoluzione dei problemi

Per indicazioni per la risoluzione dei problemi specifiche per i pool di nodi Windows Server, vedi Risoluzione dei problemi relativi ai pool di nodi Windows Server.

Per indicazioni generali, consulta la documentazione di Kubernetes sul debug dei pod e dei servizi.

Passaggi successivi