Risolvi i problemi relativi ai node pool Windows Server

Quando esegui i pool di nodi Windows Server in Google Kubernetes Engine (GKE), potresti riscontrare problemi come l'impossibilità di avviare i pod, errori durante il pull delle immagini container Windows, problemi di connettività di rete o nodi che non riescono ad avviarsi.

Utilizza questo documento per diagnosticare e risolvere questi problemi comuni e mantenere in esecuzione in modo affidabile le applicazioni basate su Windows.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma che gestiscono i cluster GKE con pool di nodi Windows e per gli sviluppatori di applicazioni che eseguono il deployment e l'esecuzione di applicazioni basate su Windows in GKE. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.

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

Problemi relativi ai nodi containerd

Per informazioni sulla risoluzione dei problemi se utilizzi un'immagine del nodo containerd, consulta Problemi relativi ai pool di nodi Windows Server.

Impossibile avviare i pod Windows

Le incompatibilità tra l'immagine di base e le versioni del sistema operativo host Windows Server possono impedire l'avvio dei pod.

Sintomi

  • Impossibile avviare i pod Windows.
  • Il nodo segnala lo stato NotReady.

Causa

L'immagine container è stata creata su un'immagine Windows di base precedente che non è compatibile con la versione di Windows Server del nodo host.

Risoluzione

Crea le immagini container utilizzando immagini Windows di base che includono gli aggiornamenti di Windows di marzo 2020 o versioni successive. Per ulteriori informazioni sulla compatibilità dei container Microsoft, consulta la documentazione di Microsoft relativa al problema di incompatibilità dei container Windows Server di febbraio 2020.

Errori pull immagine

Le immagini container Windows Server sono spesso molto più grandi delle immagini Linux, il che può causare timeout.

Sintomi

  • Messaggi di errore come Failed to pull image o context cancelled.
  • I pod mostrano lo stato ErrImagePull.

Causa

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

Risoluzione

Per risolvere questi errori pull immagine, prova le seguenti soluzioni:

  • Aumenta la CPU del nodo: 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.
  • Ottimizza i livelli immagine: per migliorare la memorizzazione nella cache dei livelli Docker e aumentare la probabilità di successo dei tentativi di pull immagine, suddividi i livelli dell'applicazione in livelli più piccoli. Per ulteriori informazioni, consulta Immagini e livelli nella documentazione del driver di archiviazione Docker.
  • Utilizza i pull manuali: connettiti ai nodi Windows Server ed esegui manualmente il comando docker pull sulle immagini container prima di creare i pod.

Per indicazioni più generali, consulta Risolvere i problemi relativi ai pull immagine.

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

GKE ritira periodicamente le famiglie di immagini Windows Server precedenti quando il supporto del fornitore termina. Questo ritiro blocca la creazione di pool di nodi con queste immagini.

Sintomi

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.

Causa

La famiglia di immagini Windows Server selezionata non è più supportata in GKE.

Risoluzione

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 in Mappare le versioni di GKE e Windows.

Timeout durante la creazione del pool di nodi

L'inizializzazione simultanea di un numero elevato di nodi Windows Server può causare timeout.

Sintomi

Le operazioni di creazione del pool di nodi vanno in timeout prima del completamento.

Causa

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

Risoluzione

Riduci il numero iniziale di nodi durante la creazione del pool di nodi. Dopo aver creato il pool di nodi, puoi aumentare il numero di nodi.

I nodi Windows diventano NotReady con l'errore: PLEG is not healthy

La pianificazione rapida di più container Windows su un singolo nodo può sovraccaricare il generatore di eventi del ciclo di vita dei pod (PLEG).

Sintomi

  • I nodi Windows entrano nello stato NotReady.
  • Gli eventi o i log mostrano un messaggio di errore PLEG is not healthy.

Causa

Si verifica un problema noto di Kubernetes quando più pod vengono avviati molto rapidamente su un singolo nodo Windows.

Risoluzione

Per ripristinare gli errori PLEG ed evitarne la ricomparsa:

  • Riavvia il nodo Windows Server interessato.
  • Limita la creazione di pod Windows a non più di un pod ogni 30 secondi.

TerminationGracePeriod incoerente

Le differenze tra i timer di arresto dei container Windows e le impostazioni del periodo di tolleranza di Kubernetes possono causare l'arresto imprevisto dei container.

Sintomi

I container vengono arrestati forzatamente da Windows prima della scadenza della durata configurata nel campo TerminationGracePeriodSeconds.

Causa

Il timeout interno del sistema Windows per il container è diverso dal periodo di tolleranza specificato nel manifest del pod Kubernetes.

Risoluzione

Modifica il timeout del container Windows modificando le chiavi del registro locale del container al tempo di compilazione dell'immagine. Allinea di conseguenza il campo TerminationGracePeriodSeconds nel manifest del pod.

Problemi di connettività di rete

Le mancate corrispondenze delle dimensioni dell'unità massima di trasmissione (MTU) tra la rete dei container Windows Server e le Google Cloud reti possono causare la perdita di pacchetti.

Sintomi

Le applicazioni in esecuzione all'interno dei container Windows Server riscontrano errori di connettività di rete o perdita di pacchetti.

Causa

La rete dei container Windows Server spesso presuppone una MTU di rete di 1500, che non è compatibile con Google Cloud's MTU di 1460.

Risoluzione

Configura il valore MTU dell'interfaccia di rete del container e il valore MTU dell'interfaccia di rete del nodo Windows Server su 1460 o un valore inferiore. Per ulteriori informazioni, consulta i problemi noti relativi ai container Windows nella documentazione di Compute Engine.

Problemi di avvio dei nodi

Le nuove istanze Windows Server potrebbero non riuscire a completare gli script di inizializzazione o a registrarsi con il piano di controllo.

Sintomi

I nodi Windows Server non riescono a inizializzarsi o ad unirsi al cluster.

Causa

Gli errori durante l'inizializzazione del nodo impediscono l'avvio o l'unione del nodo al cluster.

Risoluzione

Per identificare gli errori di avvio che potrebbero causare il problema, esamina l'output della porta seriale del nodo: porta seriale:

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

Sostituisci quanto segue:

Servizi non raggiungibili in modo intermittente nei nodi Windows con cluster che eseguono la versione 1.24 o precedenti

Nei cluster che eseguono la versione 1.24 o precedenti, il riavvio del componente kube-proxy crea ritardi temporanei nel routing di rete durante la rielaborazione delle regole del bilanciatore del carico del servizio di rete host (HNS).

Sintomi

I servizi non sono raggiungibili in modo intermittente dai pod in esecuzione sui nodi Windows.

Causa

Per i cluster GKE che eseguono la versione 1.24 o precedenti, se un evento riavvia il componente kube-proxy su un nodo Windows, ad esempio l'avvio del nodo, l'upgrade del nodo o il riavvio manuale, il componente deve sincronizzare e ricreare tutte le regole del bilanciatore del carico HNS. Se il cluster ha un numero elevato di queste regole, l'elaborazione può subire un ritardo significativo, della durata di circa 30 secondi per regola. Durante questo ritardo di sincronizzazione, i servizi non sono raggiungibili in modo intermittente dai pod in esecuzione su quel nodo. Per ulteriori informazioni, consulta il problema originale su GitHub.

Risoluzione

Esegui l'upgrade del piano di controllo del cluster alla versione 1.25 o successive. Questo comportamento è notevolmente migliorato nelle versioni più recenti, come descritto nella richiesta di pull su GitHub.

Passaggi successivi