Creazione di un cluster tramite pool di nodi Windows Server

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina imparerai a 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 container Microsoft Hyper-V non sono attualmente supportati. Analogamente ai container Linux, i container Windows Server forniscono l'isolamento dei processi e dello spazio dei nomi.

Un nodo Windows Server richiede più risorse di un tipico nodo Linux. I nodi di Windows Server hanno bisogno di 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 di Windows Server richiedono più risorse, le tue risorse allocabili sono inferiori rispetto a quelle dei nodi Linux.

Creazione di un cluster tramite pool di nodi 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 i pool di nodi.
  4. Recupera le credenziali di kubectl.
  5. Attendi l'inizializzazione del cluster.

Scegli l'immagine del nodo Windows Server

Per l'esecuzione su GKE, le immagini dei nodi container di Windows Server devono essere basate su Windows Server versione 2019 (LTSC) o Windows Server versione 20H2 (SAC). Un singolo cluster può avere più pool di nodi Windows Server utilizzando 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:

  • Tempistiche dell'assistenza:
    • La durata del supporto per un'immagine dei nodi Windows Server è soggetta ai tempi di supporto forniti da Microsoft, come descritto in Criterio di supporto per le immagini del sistema operativo. Puoi trovare la data di fine del supporto per le immagini dei nodi Windows GKE utilizzando il comando gcloud container get-server-config, come descritto nella sezione Mappatura di versioni di GKE e Windows.
    • Le versioni dei SAC sono supportate solo da Microsoft per 18 mesi dopo la release iniziale. Se scegli SAC come tipo di immagine per il tuo pool di nodi, ma non eseguire l'upgrade del pool di nodi a versioni più recenti di GKE destinate alle versioni SAC più recenti, non puoi creare nuovi nodi nel pool dei 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. Consigliamo di utilizzare la funzionalità LTSC per via del suo ciclo di vita di assistenza più lungo.
    • Non scegliere SAC se registri il tuo cluster GKE nel canale di rilascio stabile. Poiché le versioni SAC sono supportate solo da Microsoft per 18 mesi, c'è 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 la SAC solo se puoi eseguire l'upgrade del pool di nodi e dei container che lo eseguono regolarmente. GKE aggiorna periodicamente la versione SAC utilizzata per i pool di nodi Windows nelle nuove release GKE, quindi la scelta del SAC per il tipo di immagine del pool di nodi richiede la ricostruzione più frequente dei container.
    • Se hai dubbi su quale tipo di immagine di 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 i canali di manutenzione di Windows Server: LTSC e SAC nella documentazione di Microsoft.
    • Windows Server Core e Nano Server possono essere utilizzati come immagini 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 su altre versioni LTSC o SAC senza essere ricreati per scegliere come target l'altra versione.
    • La creazione di immagini container di Windows Server come immagini ad arco multiplo che possono scegliere 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 per prime nelle versioni SAC. Per questo motivo, nei pool di nodi SAC potrebbe essere innanzitutto introdotta una nuova funzionalità di Windows GKE.
    • Valuta la possibilità di utilizzare SAC se utilizzi funzionalità non ancora disponibili nella release LTSC.
  • Runtime del container:

    • Per entrambe le immagini dei nodi LTSC e SAC di Windows Server, il tempo di esecuzione del container può essere Docker o containerd. Per i nodi GKE versione 1.21.1-gke.2200 e successive, consigliamo di utilizzare il runtime containerizzato. 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 poi inizializza l'interfaccia a riga di comando gcloud.

Crea un cluster e i pool di nodi

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

Data la sua importanza, consigliamo di attivare la scalabilità automatica per garantire 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 scoprire di più sui vantaggi, consulta Comprendere il routing dei container nativi con gli IP alias.
  • NUMBER_OF_NODES: numero di nodi Linux che crei. Fornisci 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, che deve essere 1.16.8-gke.9 o successiva. Puoi anche scegliere di utilizzare un flag --release-channel per selezionare un canale di rilascio.
  • CHANNEL: il canale di rilascio per registrare il cluster, che può essere rapid, regular, stable o None. Per impostazione predefinita, il cluster è registrato nel canale di rilascio regular se i seguenti flag non sono specificati: --cluster-version, --release-channel, --no-enable-autoupgrade e --no-enable-autorepair.

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

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome che scegli per il pool di nodi Windows Server.
  • CLUSTER_NAME: il nome del cluster creato in precedenza.
  • IMAGE_NAME: puoi specificare uno dei seguenti valori:

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

  • --no-enable-autoupgrade disabilita l'upgrade automatico dei nodi. Consulta l'articolo sull'upgrade dei pool di nodi di Windows Server prima dell'abilitazione.

  • MACHINE_TYPE_NAME: definisce il tipo di macchina. n1-standard-2 è il tipo di macchina minimo consigliato in quanto i nodi Windows Server richiedono risorse aggiuntive. I tipi di macchina f1-micro e g1-small non sono supportati. La fatturazione per ogni tipo di macchina avviene in modo diverso. Per ulteriori informazioni, consulta il listino prezzi per tipo di macchina.

console

  1. Vai alla pagina Google Kubernetes Engine in Google Cloud Console.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nella sezione Nozioni di base sul cluster, completa quanto segue:

    1. Inserisci il nome del tuo cluster.
    2. In Tipo di località, seleziona l'area geografica o la zona desiderata per il cluster.
    3. In Versione del piano di controllo, seleziona un canale di rilascio oppure 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 calcolo sufficienti per eseguire i componenti aggiuntivi del cluster. Devi anche disporre della quota di risorse disponibile per i nodi e le relative risorse (ad esempio le route firewall).

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

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

    1. Inserisci un Nome per il pool di nodi.
    2. Per i nodi di versione statica, scegli la versione del 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 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 ulteriori informazioni, consulta la sezione Scegli l'immagine del nodo Windows.

    2. Scegli la configurazione della macchina predefinita da utilizzare per le istanze. n1-standard-2 è la dimensione minima consigliata, in quanto i nodi di Windows Server richiedono risorse aggiuntive. I tipi di macchina f1-micro e g1-small non sono supportati. Ogni tipo di macchina viene fatturata in modo diverso. Per ulteriori informazioni, consulta il listino prezzi per 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 di Windows Server prima di abilitare l'upgrade automatico.
  9. Nel riquadro di navigazione, in Cluster, seleziona Networking.

    1. In Opzioni di rete 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 scoprire di più sui vantaggi, consulta Comprendere il routing dei container nativi con gli 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 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 superiore.
  • NODE_POOL_NAME: il nome che scegli per il pool di nodi di Windows Server.
  • IMAGE_NAME: puoi specificare uno dei seguenti valori:

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

  • MACHINE_TYPE_NAME: definisce il tipo di macchina. n1-standard-2 è il tipo di macchina minimo consigliato in quanto i nodi di Windows Server richiedono risorse aggiuntive. I tipi di macchina f1-micro e g1-small non sono supportati. La fatturazione per ogni tipo di macchina avviene in modo diverso. Per ulteriori informazioni, consulta il tariffario del tipo di macchina.

Dopo aver creato un pool di nodi Windows Server, il cluster passa allo stato RECONCILE per diversi minuti man mano che il piano di controllo viene aggiornato.

Recupero credenziali kubectl

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

gcloud container clusters get-credentials CLUSTER_NAME

Per scoprire di più sul comando get-credentials, consulta la documentazione dell'SDK get-credentials.

Attendi l'inizializzazione del cluster

Prima di utilizzare il cluster, attendi diversi secondi fino alla creazione di windows.config.common-webhooks.networking.gke.io. Questo webhook aggiunge tolleranze di programmazione ai pod creati con il selettore di nodi kubernetes.io/os: windows per garantire che possano essere eseguite sui nodi di Windows Server. Inoltre, convalida il pod per assicurare 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 le versioni SAC ogni sei mesi circa e le 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, in genere le versioni LTSC e SAC rimangono fisse.

Per visualizzare la mappatura delle versioni tra le versioni di GKE e quelle 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 per visualizzare la mappatura delle versioni per versioni specifiche di GKE nel cluster, esegui i passaggi seguenti in una shell Linux o in Cloud Shell.

  1. Imposta le variabili seguenti:

    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 di Windows Server.
    • COMPUTE_ZONE: la zona di calcolo per il cluster.
  2. Ottieni 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 di Windows Server per il tipo di immagine WINDOWS_SAC:

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

    L'output è simile al seguente:

    10.0.18363.1198
    

Upgrade dei pool di nodi Windows Server

In base ai requisiti di compatibilità della versione del container di Windows Server, è possibile che le immagini del container debbano essere ricreate in modo che corrispondano 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 rimangano compatibili con i nodi, ti consigliamo di controllare la mappatura delle versioni e creare immagini container di Windows Server come immagini multi-arco che possano avere come target più versioni di Windows Server. Puoi quindi aggiornare i tuoi deployment container per scegliere come target le immagini multi-arch che funzioneranno sia nella versione GKE attuale 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 trovarsi a più di due versioni secondarie rispetto alla 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 che utilizzano.

Ti consigliamo di abilitare gli upgrade automatici dei nodi solo se crei continuamente immagini container Windows Server multi-arco destinate alle ultime versioni di Windows Server, soprattutto se utilizzi SAC di Windows Server come tipo di immagine nodo. Gli upgrade automatici dei nodi hanno meno probabilità di causare problemi con il tipo di immagine nodo LTSC di Windows Server, ma c'è comunque il rischio che si verifichino problemi di incompatibilità della versione.

Aggiornamenti di Windows

Gli aggiornamenti di Windows sono disabilitati per i nodi di Windows Server. Gli aggiornamenti automatici possono causare riavvii dei nodi in tempi imprevisti e qualsiasi aggiornamento di Windows installato dopo l'avvio di un nodo andrà perso quando il nodo viene ricreato da GKE. GKE mette a disposizione gli aggiornamenti di Windows aggiornando periodicamente le immagini dei nodi di Windows Server utilizzate nelle nuove release di GKE. Potrebbe verificarsi un ritardo tra il rilascio degli aggiornamenti di Windows da parte di Microsoft e il momento in cui sono disponibili in GKE. Quando vengono rilasciati aggiornamenti critici della sicurezza, GKE aggiorna le immagini dei nodi Windows Server il più rapidamente possibile.

Attivazione del criterio di rete

Puoi utilizzare i container Windows Server nei cluster per cui sono abilitati i criteri di rete nelle versioni GKE 1.22.2 e successive. Questa funzionalità è disponibile solo per i cluster che utilizzano il tipo di immagine nodo WINDOWS_LTSC.

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 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 attivato il criterio di rete, tutti i criteri configurati in precedenza, inclusi i criteri 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 sui cluster con criterio di rete abilitato. Per ulteriori dettagli, consulta la sezione sulle limitazioni.

Visualizzazione ed esecuzione di query sui log

Il logging viene abilitato automaticamente nei cluster GKE. Puoi visualizzare i log dei container e quelli 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 di Windows Server nel cluster tramite RDP. Per istruzioni su come connetterti, consulta l'articolo Connessione alle istanze Windows nella documentazione di Compute Engine.

Creare immagini multi-arco

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

Utilizzo di gMSA

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

  1. Configura i nodi Windows Server nel cluster per unirli automaticamente al tuo dominio AD. Per le istruzioni, consulta la pagina sulla configurazione dei nodi Windows Server per aggiungere automaticamente un dominio AD.

  2. Crea e concedi a gMSA l'accesso al gruppo di sicurezza creato automaticamente dal servizio di unione del dominio. Questo passaggio deve essere eseguito in una macchina 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) dell'account di servizio che hai creato. Ad esempio, se GMSA_NAME è webapp01 e il dominio è example.com, DNS_HOST_NAME è webapp01.example.com.
  3. Configura il tuo gMSA seguendo le istruzioni nel tutorial Configura GMSA per pod e container Windows.

Eliminazione dei pool di nodi Windows Server in corso...

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 Google Cloud Console, esegui questi passaggi:

  1. Vai alla pagina Google Kubernetes Engine in Google Cloud Console.

    Vai a Google Kubernetes Engine

  2. Accanto al cluster che vuoi modificare, fai clic su Azioni, quindi fai clic 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à Kubernetes non supportate, alcune funzionalità di GKE non sono supportate.

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

I criteri del traffico esterno locale sul pool di nodi Windows sono supportati solo con GKE v1.23.4-gke.400 o versione 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.

I container Windows Server sui cluster con criterio di rete abilitato non possono essere utilizzati con:

  • Cluster con Workload Identity abilitato
  • Cluster privati

Risolvere i problemi

Consulta la documentazione di Kubernetes per indicazioni generali sul debug dei pod e dei servizi.

Problemi relativi ai nodi containerizzati

Per informazioni sui problemi noti che utilizzano un'immagine del nodo Containerd, vedi Problemi noti.

Impossibile avviare i pod Windows

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

Se la versione del pool di nodi Windows è 1.16.8-gke.8 o successiva, 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 aggiornamenti di Windows a partire da marzo 2020. Le immagini container basate su immagini Windows di base 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 composti possono essere di dimensioni molto grandi. Le loro dimensioni possono causare un timeout di Kubelet, che non riesce durante il download e l'estrazione dei livelli container.

Potresti aver riscontrato questo problema se vedi il messaggio "Errore pull dell'immagine" o "Immagine pull pull annullato" oppure "ErrImagePull" per i tuoi pod.

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

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

  • Suddividere i livelli dell'applicazione dell'immagine container di Windows Server in livelli più piccoli che possono essere estratti ed estratti più rapidamente. Ciò può rendere più efficace la memorizzazione nella cache del livello di Docker e rendere più riusciti i tentativi di pull delle immagini. Per saperne di più sui livelli, consulta l'articolo su Docker relativo a 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 di 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 andata a buon fine.

      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. Verifica che il servizio kubelet sia stato riavviato.

      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 GKE utilizzando il comando gcloud container get-server-config, come descritto nella sezione Mappatura di versioni di GKE e Windows.

Timeout durante la creazione del pool di nodi

La creazione del pool di nodi può causare un timeout 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 errore: "PLEG non è integro"

Questo è un problema noto di Kubernetes che si verifica quando più pod vengono avviati molto rapidamente su un singolo nodo di Windows. Per eseguire il ripristino in questo caso, riavvia il nodo di Windows Server. Una soluzione alternativa consigliata per evitare questo problema è limitare la frequenza con cui i pod di Windows vengono creati su un pod ogni 30 secondi.

Periodo di tolleranza interruzione (coerenza)

Il timeout di sistema di Windows per il container potrebbe essere diverso dal periodo di tolleranza configurato. Questa differenza può causare l'interruzione 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, potrebbe anche essere necessario regolare TerminaGracePeriodSeconds per assicurare la corrispondenza.

Problemi di connettività di rete

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

Verifica che la MTU dell'interfaccia di rete nel container e le interfacce di rete del nodo Windows Server siano tutte 1460 o meno. Per informazioni su come impostare la MTU, consulta i problemi noti relativi ai container Windows.

Problemi di avvio del nodo

Se i nodi non si avviano nel cluster o non riescono a unirsi al cluster, rivedi le informazioni diagnostiche fornite nell'output della porta seriale del nodo.

Esegui il comando seguente 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 calcolo per il nodo specifico.

Passaggi successivi