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 quando si utilizzano tipi di dischi specifici con determinati tipi di macchine. Questi problemi possono influire sulla statefulness delle applicazioni, sulla persistenza dei dati e sull'integrità complessiva dei workload.

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

Queste informazioni sono importanti sia per gli amministratori della piattaforma e gli operatori che gestiscono l'infrastruttura e l'archiviazione dei cluster sia per gli sviluppatori di applicazioni i cui workload si basano sull'archiviazione permanente. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud

Errore 400: impossibile collegare RePD a una VM ottimizzata

L'utilizzo dei dischi permanenti regionali è limitato con le macchine ottimizzate per la memoria o per il calcolo.

Se l'utilizzo di un disco permanente regionale non è un requisito rigido, valuta la possibilità di utilizzare una classe di archiviazione di dischi permanenti non regionali. Se l'utilizzo di un disco permanente regionale è un requisito rigido, valuta le strategie di pianificazione come incompatibilità e tolleranze per assicurarti che i pod che richiedono dischi permanenti regionali vengano pianificati su un pool di nodi di macchine non ottimizzate.

Risolvere i problemi di 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 quanto segue:

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

Le prestazioni del disco sono condivise per tutti i dischi dello stesso tipo 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 c'è molta attività sul PersistentVolume, ciò influisce anche sulle prestazioni del disco di avvio.

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

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 dischi permanenti standard con una dimensione inferiore a 200 GB. Valuta la possibilità di aumentare le dimensioni dei dischi o di passare agli SSD, soprattutto per i cluster utilizzati in produzione.
  • Valuta la possibilità di abilitare gli SSD locali per l'archiviazione temporanea nei node pool. Questa soluzione è particolarmente efficace se hai container che utilizzano spesso i volumi emptyDir.

Il montaggio di un volume smette di rispondere a causa dell'impostazione fsGroup

Un problema che può causare il mancato montaggio di PersistentVolume è un pod configurato con l'impostazione fsGroup. In genere, i montaggi vengono ritentati 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 è correlato all'impostazione fsGroup, vedrai 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 a seguire questi passaggi per risolvere il problema:

Le operazioni sui dischi lente causano errori di creazione dei pod

Per ulteriori informazioni, consulta il problema n. 4604 di containerd.

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

Nei log 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 la possibilità di utilizzare 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 successive, 1.21.9-gke.2000 e successive, 1.21.10-gke.100 e successive, 1.22.6-gke.2000 e successive, 1.22.7-gke.100 e successive, 1.23.3-gke.1700 e successive e 1.23.4-gke.100 e successive.

Le modifiche all'espansione del volume non vengono applicate nel file system del container

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

  • Se un oggetto PersistentVolume viene modificato direttamente, sia i valori di PersistentVolume sia quelli di PersistentVolumeClaim vengono aggiornati a un nuovo valore, ma le dimensioni del file system non vengono applicate nel container e continuano a utilizzare le dimensioni del volume precedenti.

  • Se un oggetto PersistentVolume viene modificato direttamente, seguito da aggiornamenti a PersistentVolumeClaim in cui il campo status.capacity viene aggiornato a una nuova dimensione, le modifiche potrebbero essere applicate a PersistentVolume, ma non a 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 in PersistentVolume.
  3. Verifica se le dimensioni di PersistentVolume sono state modificate al nuovo valore.

Dopo queste modifiche, le dimensioni di PersistentVolume, PersistentVolumeClaim e del file system del container dovrebbero essere modificate automaticamente da kubelet.

Verifica se le modifiche sono state applicate al 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 visualizzare 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 vedere LocalNvmeSsdBlockConfig anziché EphemeralStorageLocalSsdConfig, a seconda di quale 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 questo problema, specifica un numero di dischi SSD locali che corrisponda al tipo di macchina che vuoi. Per la serie di macchine di terza generazione, devi omettere il flag count degli SSD locali e il valore corretto verrà configurato automaticamente.

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

Quando provi a eseguire il provisioning dei dischi Hyperdisk bilanciati come dischi di avvio o collegati del nodo in un pool di archiviazione Hyperdisk, potresti visualizzare l'errore ZONE_RESOURCE_POOL_EXHAUSTED o errori simili relativi alle risorse di Compute Engine.

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

  • La zona potrebbe non avere a disposizione un numero sufficiente di dischi Hyperdisk bilanciati.
  • 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 bilanciati.
  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 elevata pressione di archiviazione dei nodi

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 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 vedere un evento simile a questo:

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%). Questo può essere causato da:

  • Workload che scrivono dati eccessivi nei volumi emptyDir non supportati da SSD locali.
  • Immagini container di grandi dimensioni di cui viene eseguito il pull nel nodo.
  • File di log che si accumulano sul nodo.
  • Altri processi che consumano spazio su disco.

L'utilizzo elevato e continuo del disco può causare instabilità dei nodi, eliminazione 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 temporanea.

Aumenta la capacità di archiviazione dei nodi: tieni presente che la risoluzione principale consiste spesso nel garantire che i nodi abbiano una capacità di archiviazione adeguata per i 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 temporanea nel file system root.
  • Utilizza SSD locali più grandi per l'archiviazione temporanea: per i workload che richiedono spazio di archiviazione temporanea ad alte prestazioni e a bassa latenza, configura i node pool in modo che utilizzino gli SSD locali. In questo modo, viene fornita una capacità separata e maggiore per i volumi emptyDir.
  • Modifica le richieste o i limiti dei workload: assicurati che le specifiche dei pod includano richieste e limiti di archiviazione temporanea appropriati per consentire allo scheduler di posizionare i pod sui nodi con spazio sufficiente e per impedire l'utilizzo eccessivo del disco.
  • Libera spazio dalle risorse inutilizzate: rimuovi eventuali file, immagini container o log obsoleti dal nodo se contribuiscono all'utilizzo elevato del disco.

Se risolvi il problema di capacità e utilizzo dello spazio di archiviazione sul nodo, puoi attenuare i problemi relativi a StoragePressureDetected e migliorare il funzionamento del nodo.

Passaggi successivi