Risoluzione dei problemi di archiviazione in GKE

Questa pagina mostra come risolvere i problemi relativi allo spazio di archiviazione nei cluster Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Errore 400: impossibile collegare RePD a una VM ottimizzata

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

Valuta la possibilità di utilizzare una classe di archiviazione dei dischi permanenti non regionale se l'utilizzo di un disco permanente regionale non è un requisito obbligatorio. Se l'utilizzo di un disco permanente a livello di area geografica è un requisito obbligatorio, valuta strategie di pianificazione come incompatibilità e tolleranze per assicurarti che i pod che richiedono dischi permanenti a livello di area geografica vengano pianificati in un pool di nodi che non sono macchine ottimizzate.

Risolvere i problemi relativi alle prestazioni del disco

Le prestazioni del disco di avvio sono importanti perché per I nodi GKE non vengono utilizzati solo per il sistema operativo, ma anche le seguenti:

  • immagini Docker.
  • Il file system del contenitore per ciò che non è montato come volume (ovvero il file system overlay), che spesso include directory come /tmp.
  • Volumi emptyDir basati su disco, a meno che il nodo non utilizzi un'unità SSD locale.

Le prestazioni del disco sono condivise per tutti i dischi dello stesso disco su un nodo. Ad esempio, se disponi di una Disco di avvio da 100 GB pd-standard e pd-standard da 100 GB da un PersistentVolume con molta attività, le prestazioni del disco di avvio di un disco da 200 GB. Inoltre, se c'è molta attività sul volume permanente, le prestazioni del disco di avvio ne risentono.

Se nei nodi ricevi messaggi simili al seguente, questi potrebbero essere sintomi di scarse prestazioni del disco:

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, controlla quanto segue:

  • Assicurati di aver consultato la sezione Confronti dei tipi di disco di archiviazione e abbiamo scelto un tipo di disco permanente adatto alle tue esigenze.
  • Questo problema si verifica spesso per i nodi che utilizzano dischi permanenti standard con un inferiori a 200 GB. Valuta la possibilità di aumentare le dimensioni dei dischi o di passare a unità SSD, in particolare per i cluster utilizzati in produzione.
  • Valuta la possibilità di abilitare gli SSD locali per l'archiviazione temporanea nei tuoi pool di nodi. Questa operazione è particolarmente efficace se hai container che utilizzano spesso i volumi emptyDir.

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

Un problema che può causare il mancato montaggio di PersistentVolume è un pod che configurate con l'impostazione fsGroup. In genere, i montaggi vengono riprovati automaticamente e l'errore di montaggio si risolve da solo. Tuttavia, se PersistentVolume ha un numero elevato di file, kubelet tenterà di modificare la proprietà di ogni file sul 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 si monta entro pochi minuti, prova a svolgere i seguenti passaggi per risolvere il problema:

Operazioni sul disco lente causano errori di creazione dei pod

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

Nei log dik8s_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"

Attenuazione

  1. Se i pod non funzionano, ti consigliamo 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 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 il PersistentVolumeClaim. La modifica diretta di un volume permanente può comportare l'espansione del volume. Ciò potrebbe comportare uno dei seguenti scenari:

  • Se un oggetto PersistentVolume viene modificato direttamente, sia i valori PersistentVolume che PersistentVolumeClaim vengono aggiornati a un nuovo valore, ma le dimensioni del file system non vengono applicate al contenitore e vengono ancora utilizzate le dimensioni del volume precedente.

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

Per risolvere il problema, completa i seguenti passaggi:

  1. Mantieni l'oggetto PersistentVolume modificato invariato.
  2. Modifica l'oggetto PersistentVolumeClaim e imposta spec.resources.requests.storage a un valore superiore a quello utilizzato in e il PersistentVolume.
  3. Verifica se il PersistentVolume viene ridimensionato al nuovo valore.

Dopo queste modifiche, PersistentVolume, PersistentVolumeClaim e container deve essere ridimensionato automaticamente dal kubelet.

Verifica se le modifiche sono riportate 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 l'SSD locale, 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 vedere LocalNvmeSsdBlockConfig anziché EphemeralStorageLocalSsdConfig in base al criterio da te 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 3ª generazione, devi omettere il flag count SSD locale e il valore corretto verrà configurato automaticamente.

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

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

Questo accade quando stai tentando di creare un cluster o un pool di nodi GKE in una zona in cui le risorse stanno per esaurirsi, ad esempio:

  • Nella zona potrebbero non essere disponibili abbastanza dischi Hyperdisk bilanciati.
  • La zona potrebbe non avere una 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 l'opzione selezionata e dove sono disponibili i pool di archiviazione bilanciati Hyperdisk.
  2. Elimina il pool di archiviazione esistente e ricréalo nella nuova zona. Questo accade perché i pool di archiviazione sono risorse a livello di zona.
  3. Crea il tuo cluster o pool di nodi nella nuova zona.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.