Risoluzione dei problemi di archiviazione in GKE

I problemi relativi allo spazio di archiviazione nei cluster Google Kubernetes Engine (GKE) possono manifestarsi in vari modi, dai colli di bottiglia delle prestazioni e dagli errori di montaggio dei volumi agli errori durante l'utilizzo di tipi di dischi specifici con determinati tipi di macchine. Questi problemi possono influire sulla statefulness dell'applicazione, sulla persistenza dei dati e sull'integrità complessiva del workload.

Utilizza questo documento per risolvere i problemi comuni che influiscono sulla funzionalità di archiviazione nei tuoi cluster. Trova indicazioni sulla risoluzione dei problemi relativi al provisioning e al collegamento dei volumi, all'accesso ai dati e alle prestazioni, nonché alla gestione della capacità di archiviazione.

Queste informazioni sono importanti sia per gli amministratori e gli operatori della piattaforma che gestiscono l'infrastruttura e lo spazio di archiviazione del cluster, sia per gli sviluppatori di applicazioni i cui workload si basano sull'archiviazione permanente. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Cloud de Confiance by S3NS , consulta Ruoli e attività comuni degli utenti GKE.

Errore 400: impossibile collegare il disco RePD a una VM ottimizzata

L'utilizzo dei Persistent Disk regionali con macchine ottimizzate per la memoria o ottimizzate per il calcolo è limitato.

Se l'utilizzo di un Persistent Disk a livello di regione non è un requisito obbligatorio, valuta la possibilità di utilizzare una classe di archiviazione di disco permanente non a livello di regione. Se l'utilizzo di un disco permanente regionale è un requisito obbligatorio, prendi in considerazione strategie di pianificazione come taint e tolleranze per assicurarti che i pod che necessitano di dischi permanenti regionali siano pianificati su un pool di nodi che non sia composto da macchine ottimizzate.

Risoluzione dei problemi relativi alle prestazioni del disco

Le prestazioni del disco di avvio sono importanti perché il disco di avvio per i nodi GKE non viene utilizzato solo per il sistema operativo, ma anche per:

  • Immagini Docker.
  • Il file system del container per ciò che non è montato come volume (ovvero il file system overlay), che spesso include directory come /tmp.
  • Volumi emptyDir supportati da disco, a meno che il nodo non utilizzi un SSD locale.

Le prestazioni del disco sono condivise per tutti i dischi dello stesso tipo di disco su un nodo. Ad esempio, se hai un disco di avvio pd-standard da 100 GB e un PersistentVolume pd-standard da 100 GB con molta attività, le prestazioni del disco di avvio sono quelle di un disco da 200 GB. Inoltre, se l'attività sul PersistentVolume è intensa, ciò influisce anche sulle prestazioni del disco di avvio.

Se sui tuoi nodi vengono visualizzati messaggi simili ai seguenti, potrebbero essere sintomi di prestazioni del disco ridotte:

INFO: task dockerd:2314 blocked for more than 300 seconds.

fs: disk usage and inodes count on following dirs took 13.572074343s

PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s

Per risolvere questi problemi, esamina quanto segue:

  • Assicurati di aver consultato i confronti tra i tipi di dischi di archiviazione e di aver scelto un tipo di disco permanente adatto alle tue esigenze.
  • Questo problema si verifica spesso per i nodi che utilizzano Standard Persistent Disk con una dimensione inferiore a 200 GB. Valuta la possibilità di aumentare le dimensioni dei dischi o di passare alle unità SSD, soprattutto per i cluster utilizzati in produzione.
  • Valuta la possibilità di attivare l'SSD locale per l'archiviazione temporanea nei tuoi node pool. Questo è particolarmente efficace se hai container che utilizzano spesso volumi emptyDir.

Il montaggio di un volume non risponde a causa dell'impostazione fsGroup

Un problema che può causare l'errore di montaggio di PersistentVolume è un pod configurato con l'impostazione fsGroup. In genere, i montaggi vengono ripetuti automaticamente e l'errore di montaggio si risolve da solo. Tuttavia, se PersistentVolume contiene un numero elevato di file, kubelet tenterà di modificare la proprietà di ogni file nel file system, il che può aumentare la latenza di montaggio del volume.

Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition

Per verificare se un errore di montaggio non riuscito è dovuto all'impostazione fsGroup, puoi controllare i log del pod. Se il problema riguarda l'impostazione fsGroup, viene visualizzata la seguente voce di log:

Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

Se PersistentVolume non viene montato entro pochi minuti, prova i seguenti passaggi per risolvere il problema:

Le operazioni lente sul disco causano errori di creazione dei pod

Per saperne di più, consulta il problema #4604 di containerd.

Versioni dei nodi GKE interessate: 1.18, 1.19, da 1.20.0 a 1.20.15-gke.2100, da 1.21.0 a 1.21.9-gke.2000, da 1.21.10 a 1.21.10-gke.100, da 1.22.0 a 1.22.6-gke.2000, da 1.22.7 a 1.22.7-gke.100, da 1.23.0 a 1.23.3-gke.700, da 1.23.4 a 1.23.4-gke.100

Nei log di k8s_node container-runtime potrebbero essere visualizzati i seguenti errori di esempio:

Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"

Mitigazione

  1. Se i pod non funzionano, valuta l'utilizzo di restartPolicy:Always o restartPolicy:OnFailure in PodSpec.
  2. Aumenta le IOPS del disco di avvio (ad esempio, esegui l'upgrade del tipo di disco o aumenta le dimensioni del disco).

Correggi

Questo problema è stato risolto in containerd 1.6.0 e versioni successive. Le versioni di GKE con questa correzione sono 1.20.15-gke.2100 e versioni successive, 1.21.9-gke.2000 e versioni successive, 1.21.10-gke.100 e versioni successive, 1.22.6-gke.2000 e versioni successive, 1.22.7-gke.100 e versioni successive, 1.23.3-gke.1700 e versioni successive e 1.23.4-gke.100 e versioni successive

Le modifiche all'espansione del volume non si riflettono nel file system del container

Quando esegui l'espansione del volume, assicurati sempre di aggiornare PersistentVolumeClaim. La modifica diretta di un PersistentVolume può comportare la mancata espansione del volume. Ciò potrebbe portare a uno dei seguenti scenari:

  • Se un oggetto PersistentVolume viene modificato direttamente, i valori PersistentVolume e PersistentVolumeClaim vengono aggiornati a un nuovo valore, ma le dimensioni del file system non vengono applicate nel container, che continua a utilizzare le dimensioni del volume precedente.

  • Se un oggetto PersistentVolume viene modificato direttamente, seguito da aggiornamenti al PersistentVolumeClaim in cui il campo status.capacity viene aggiornato a una nuova dimensione, ciò può comportare modifiche al PersistentVolume, ma non al PersistentVolumeClaim o al file system del container.

Per risolvere questo problema, completa i seguenti passaggi:

  1. Mantieni l'oggetto PersistentVolume modificato così com'era.
  2. Modifica l'oggetto PersistentVolumeClaim e imposta spec.resources.requests.storage su un valore superiore a quello utilizzato nel PersistentVolume.
  3. Verifica se il PersistentVolume è stato ridimensionato in base al nuovo valore.

Dopo queste modifiche, il PersistentVolume, il PersistentVolumeClaim e il file system del container dovrebbero essere ridimensionati automaticamente dal kubelet.

Verifica se le modifiche si riflettono nel pod.

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Sostituisci POD_NAME con il pod collegato a PersistentVolumeClaim.

Il tipo di macchina selezionato deve avere SSD locali

Quando crei un cluster o un pool di nodi che utilizza SSD locali, potresti riscontrare il seguente errore:

The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.

Nel messaggio di errore, potresti visualizzare LocalNvmeSsdBlockConfig anziché EphemeralStorageLocalSsdConfig, a seconda di ciò che hai specificato.

Questo errore si verifica quando il numero di dischi SSD locali specificato non corrisponde al numero di dischi SSD locali inclusi nel tipo di macchina.

Per risolvere il problema, specifica un numero di dischi SSD locali che corrisponda al tipo di macchina che vuoi. Per le serie di macchine di terza generazione, devi omettere il flag SSD locale count e il valore corretto verrà configurato automaticamente.

Pool di archiviazione Hyperdisk: la creazione del cluster o pool di nodi non riesce

Potresti riscontrare l'errore ZONE_RESOURCE_POOL_EXHAUSTED o errori delle risorse di Compute Engine simili quando provi a eseguire il provisioning dei dischi Hyperdisk Balanced come dischi di avvio o collegati del nodo in un pool di archiviazione Hyperdisk.

Questo accade quando provi a creare un cluster GKE o un pool di nodi in una zona con risorse in esaurimento, ad esempio:

  • La zona potrebbe non avere un numero sufficiente di dischi Hyperdisk bilanciato disponibili.
  • La zona potrebbe non avere capacità sufficiente per creare i nodi del tipo di macchina specificato, ad esempio c3-standard-4.

Per risolvere il problema:

  1. Seleziona una nuova zona all'interno della stessa regione con capacità sufficiente per il tipo di macchina scelto e in cui sono disponibili i pool di archiviazione Hyperdisk bilanciato.
  2. Elimina il pool di archiviazione esistente e ricrealo nella nuova zona. Questo perché i pool di archiviazione sono risorse di zona.
  3. Crea il cluster o pool di nodi nella nuova zona.

Rilevata pressione di archiviazione dei nodi elevata

Se osservi eventi o condizioni dei nodi correlati a StoragePressureRootFileSystem con il motivo StoragePressureDetected, significa che il file system root del nodo o un punto di montaggio dello spazio di archiviazione critico sta riscontrando un utilizzo elevato del disco, che si avvicina alla sua capacità.

Quando descrivi un nodo utilizzando il comando kubectl describe node NODE_NAME, potresti visualizzare un evento simile al seguente:

Events:
  Type     Reason                      Age   From                     Message
  ----     ------                      ----  ----                     -------
  ...
  Warning  StoragePressureDetected     46m   device-capacity-monitor  Node condition StoragePressureRootFileSystem is now: True, reason: StoragePressureDetected, message: "Disk /dev/nvme0n1 usage 89% exceeds threshold 85%"

Causa:

Il motivo StoragePressureDetected indica che l'utilizzo del disco nel file system root del nodo (spesso mnt/stateful_partition o montaggi correlati) ha superato una soglia predefinita (ad esempio, 85%). Ciò può essere dovuto a quanto segue:

  • Workload che scrivono dati eccessivi in volumi emptyDir non supportati da SSD locali.
  • Immagini container di grandi dimensioni che vengono estratte nel nodo.
  • File di log che si accumulano sul nodo.
  • Altri processi che consumano spazio su disco.

Un utilizzo elevato del disco può causare instabilità dei nodi, espulsioni dei pod ed errori delle applicazioni.

Debug e risoluzione:

Identifica l'utilizzo del disco: utilizza SSH per connetterti al nodo interessato e utilizza comandi come df -h per controllare l'utilizzo del disco su vari punti di montaggio, prestando particolare attenzione a /mnt/stateful_partition e a eventuali montaggi di archiviazione temporanea.

Analizza i pattern di archiviazione dei workload: esamina le richieste di archiviazione e i pattern di utilizzo dei pod in esecuzione sul nodo. Identifica se workload specifici consumano una quantità sproporzionata di spazio di archiviazione temporaneo.

Aumenta la capacità di archiviazione dei nodi: tieni presente che la soluzione principale è spesso quella di assicurarti che i nodi abbiano una capacità di archiviazione adeguata per i tuoi workload. Considera quanto segue:

  • Utilizza dischi di avvio più grandi: quando crei i node pool, seleziona una dimensione del disco di avvio più grande se i tuoi workload richiedono più spazio di archiviazione temporaneo sul file system root.
  • Utilizza SSD locali più grandi per l'archiviazione temporanea: per i workload che richiedono un'archiviazione temporanea ad alte prestazioni e a bassa latenza, configura i node pool in modo che utilizzino SSD locali. In questo modo, viene fornita una capacità separata e maggiore per i volumi emptyDir.
  • Regola le richieste o i limiti dei workload: assicurati che le specifiche dei pod includano richieste e limiti di archiviazione temporanea appropriati per aiutare lo scheduler a posizionare i pod su nodi con spazio sufficiente e per evitare un utilizzo eccessivo del disco.
  • Elimina le risorse inutilizzate: rimuovi dal nodo eventuali file non necessari, immagini container obsolete o log se contribuiscono all'utilizzo elevato del disco.

Se gestisci la capacità di archiviazione e l'utilizzo sul nodo, puoi mitigare i problemi relativi a StoragePressureDetected e facilitare il funzionamento del nodo.

Risolvi i problemi relativi agli eventi di memoria esaurita (OOM) di Cloud Storage FUSE

Se i pod registrano un utilizzo elevato della memoria o eventi di memoria esaurita (OOM) correlati al driver CSI di Cloud Storage FUSE, puoi raccogliere e analizzare gli snapshot della CPU e della memoria utilizzando Cloud Profiler. Configura queste opzioni in Configura il container sidecar del driver CSI di Cloud Storage FUSE.

Quando un pod subisce un arresto per OOM, puoi correlare l'evento allo snapshot di Cloud Profiler corretto utilizzando il seguente flusso di lavoro:

  1. Controlla Cloud Logging: vai a Cloud Logging per trovare l'evento OOM di Kubernetes.

  2. Filtra per nome del pod: esegui la seguente query per individuare i log eventi per il tuo pod specifico, sostituendo POD_NAME con il nome del pod del workload:

    jsonPayload.involvedObject.name="POD_NAME"
jsonPayload.involvedObject.kind="Pod"
OOMKilled

  3. Estrai l'UID del pod: espandi il log eventi OOM pertinente e prendi nota del timestamp e dell'UID esatto del pod che si trova in jsonPayload.involvedObject.uid.

  4. Analizza in Cloud Profiler: vai a Cloud Profiler, filtra la versione del servizio utilizzando il formato POD_NAME_POD_UID e regola l'intervallo di tempo in modo che corrisponda al timestamp OOM. In questo modo, puoi assicurarti di esaminare il profilo di memoria esatto dell'istanza di container specifica subito prima che venisse terminata.

Workload stateful bloccati nello stato Pending a causa di capacità di computing insufficiente

Se hai workload stateful bloccati in uno stato Pending con messaggi di errore come ZONE_RESOURCE_POOL_EXHAUSTED o GCE_STOCKOUT, una zona specifica potrebbe avere una capacità di computing limitata.

Quando un nodo di computing va offline in una zona con capacità insufficiente, la sostituzione del nodo potrebbe non riuscire. I pod stateful che si basano su PersistentVolume a livello di zona preesistenti (come un disco pd-ssd o pd-balanced standard) sono limitati alla zona in cui è stato creato il volume. Poiché il pod deve essere pianificato in quella zona specifica per montare il volume, il pod rimane Pending finché non diventa disponibile la capacità di computing in quella zona.

Per mitigare questo problema per i futuri workload stateful, considera quanto segue:

  • Evita i fallback nella stessa zona tra pd-ssd e pd-balanced: poiché i volumi pd-ssd e pd-balanced condividono gli stessi limiti di capacità e pool di disponibilità in una zona, la modifica della StorageClass da pd-ssd a pd-balanced nella stessa zona non risolverà la mancanza di capacità. Non tentare di farlo come alternativa.
  • Utilizza forme compatibili con Hyperdisk: alcune serie di macchine supportano Hyperdisk. Valuta la possibilità di utilizzare una forma compatibile con Hyperdisk, perché potrebbe avere vincoli di disponibilità diversi che aiutano quando una zona non ha capacità sufficiente. Prima di eseguire la migrazione dei workload, assicurati di avere quote disco sufficienti.
  • Attiva l'associazione dinamica della topologia (WaitForFirstConsumer): quando crei nuovi workload stateful, configura la definizione di StorageClass con la coppia campo-valore volumeBindingMode: WaitForFirstConsumer. Questa impostazione rimanda la creazione del volume fino a quando un pod non viene pianificato su un nodo integro in una zona con capacità di calcolo sufficiente, il che aiuta a evitare che la creazione prematura del volume blocchi il pod in una zona offline o esaurita.
  • Configura la selezione automatica del tipo di disco per i fallback delle VM: in GKE versione 1.35.3-gke.1290000 e successive, puoi configurare ComputeClass personalizzate per i workload che eseguono il fallback tra generazioni di VM (ad esempio, da N4 a N2 o da C4 a C2). Utilizzando la selezione automatica del tipo di disco, puoi configurare una definizione StorageClass con le coppie campo-valore parameters.type: dynamic e use-allowed-disk-topology: "true". Questa configurazione consente a GKE di eseguire automaticamente il provisioning dei dischi hyperdisk-balanced sulle generazioni di macchine più recenti e di utilizzare i dischi pd-balanced sulle generazioni precedenti.

Passaggi successivi