Resolução de problemas de armazenamento no GKE

Esta página mostra como resolver problemas relacionados com o armazenamento nos seus clusters do Google Kubernetes Engine (GKE).

Erro 400: não é possível anexar o RePD a uma VM otimizada

Os discos persistentes regionais estão restritos para utilização com máquinas otimizadas para memória ou máquinas otimizadas para computação.

Considere usar uma classe de armazenamento de disco persistente não regional se usar um disco persistente regional não for um requisito obrigatório. Se a utilização de um disco persistente regional for um requisito obrigatório, considere agendar estratégias, como contaminações e tolerâncias para garantir que os pods que precisam de discos persistentes regionais são agendados num conjunto de nós que não são máquinas otimizadas.

Resolução de problemas com o desempenho do disco

O desempenho do disco de arranque é importante porque o disco de arranque dos nós do GKE não é usado apenas para o sistema operativo, mas também para o seguinte:

  • Imagens de Docker.
  • O sistema de ficheiros do contentor para o que não está montado como um volume (ou seja, o sistema de ficheiros de sobreposição) e isto inclui frequentemente diretórios como /tmp.
  • Volumes baseados em disco emptyDir, a menos que o nó use um SSD local.

O desempenho do disco é partilhado por todos os discos do mesmo tipo de disco num nó. Por exemplo, se tiver um disco de arranque de 100 GB pd-standard e um PersistentVolume de 100 GB pd-standard com muita atividade, o desempenho do disco de arranque é o de um disco de 200 GB. Além disso, se houver muita atividade no PersistentVolume, isto também afeta o desempenho do disco de arranque.

Se encontrar mensagens semelhantes às seguintes nos seus nós, podem ser sintomas de baixo desempenho do 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

Para ajudar a resolver estes problemas, reveja o seguinte:

A montagem de um volume deixa de responder devido à definição fsGroup

Um problema que pode fazer com que a montagem do PersistentVolume falhe é um pod configurado com a definição fsGroup. Normalmente, as montagens são repetidas automaticamente e a falha de montagem resolve-se sozinha. No entanto, se o PersistentVolume tiver um grande número de ficheiros, o kubelet tenta alterar a propriedade de cada ficheiro no sistema de ficheiros, o que pode aumentar a latência de montagem do volume.

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

Para confirmar se um erro de montagem com falha se deve à definição fsGroup, pode verificar os registos do pod. Se o problema estiver relacionado com a definição fsGroup, é apresentada a seguinte entrada no registo:

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 o PersistentVolume não for montado dentro de alguns minutos, experimente os seguintes passos para resolver este problema:

As operações lentas do disco causam falhas na criação de pods

Para mais informações, consulte o problema n.º 4604 do containerd.

Versões de nós do GKE afetadas: 1.18, 1.19, 1.20.0 a 1.20.15-gke.2100, 1.21.0 a 1.21.9-gke.2000, 1.21.10 a 1.21.10-gke.100, 1.22.0 a 1.22.6-gke.2000, 1.22.7 a 1.22.7-gke.100, 1.23.0 a 1.23.3-gke.700, 1.23.4 a 1.23.4-gke.100

Os seguintes exemplos de erros podem ser apresentados nos registos de k8s_node container-runtime:

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"

Mitigação

  1. Se os pods estiverem a falhar, considere usar restartPolicy:Always ou restartPolicy:OnFailure no seu PodSpec.
  2. Aumente os IOPS do disco de arranque (por exemplo, atualize o tipo de disco ou aumente o tamanho do disco).

Corrigir

Este problema foi corrigido no containerd 1.6.0 e superior. As versões do GKE com esta correção são 1.20.15-gke.2100+, 1.21.9-gke.2000+, 1.21.10-gke.100+, 1.22.6-gke.2000+, 1.22.7-gke.100+, 1.23.3-gke.1700+ e 1.23.4-gke.100+

As alterações de expansão do volume não se refletem no sistema de ficheiros do contentor

Quando realizar a expansão do volume, certifique-se sempre de que atualiza o PersistentVolumeClaim. A alteração direta de um PersistentVolume pode impedir a expansão do volume. Isto pode levar a um dos seguintes cenários:

  • Se um objeto PersistentVolume for modificado diretamente, os valores PersistentVolume e PersistentVolumeClaim são atualizados para um novo valor, mas o tamanho do sistema de ficheiros não se reflete no contentor e continua a usar o tamanho do volume antigo.

  • Se um objeto PersistentVolume for modificado diretamente, seguido de atualizações ao PersistentVolumeClaim em que o campo status.capacity é atualizado para um novo tamanho, isto pode resultar em alterações ao PersistentVolume, mas não ao PersistentVolumeClaim nem ao sistema de ficheiros do contentor.

Para resolver este problema, conclua os seguintes passos:

  1. Manter o objeto PersistentVolume modificado tal como estava.
  2. Edite o objeto PersistentVolumeClaim e defina spec.resources.requests.storage para um valor superior ao usado no PersistentVolume.
  3. Verifique se o PersistentVolume foi redimensionado para o novo valor.

Após estas alterações, o PersistentVolume, o PersistentVolumeClaim e o sistema de ficheiros do contentor devem ser redimensionados automaticamente pelo kubelet.

Verifique se as alterações são refletidas no Pod.

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

Substitua POD_NAME pelo pod anexado a PersistentVolumeClaim.

O tipo de máquina selecionado deve ter SSDs locais

Pode encontrar o seguinte erro ao criar um cluster ou um conjunto de nós que use um SSD local:

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.

Na mensagem de erro, pode ver LocalNvmeSsdBlockConfig em vez de EphemeralStorageLocalSsdConfig, consoante o que especificou.

Este erro ocorre quando o número de discos SSD locais especificado não corresponde ao número de discos SSD locais incluídos no tipo de máquina.

Para resolver este problema, especifique um número de discos SSD local que corresponda ao tipo de máquina que quer. Para a série de máquinas de terceira geração, tem de omitir a flag count do SSD local e o valor correto é configurado automaticamente.

Grupos de armazenamento de hiperdiscos: falha na criação do cluster ou do node pool

Pode encontrar o erro ZONE_RESOURCE_POOL_EXHAUSTED ou erros semelhantes de recursos do Compute Engine ao tentar aprovisionar discos Hyperdisk Balanced como discos de arranque ou anexados do nó num Hyperdisk Storage Pool.

Isto acontece quando tenta criar um cluster ou um node pool do GKE numa zona com poucos recursos, por exemplo:

  • A zona pode não ter discos Hyperdisk Balanced suficientes disponíveis.
  • A zona pode não ter capacidade suficiente para criar os nós do tipo de máquina especificado, como c3-standard-4.

Para resolver este problema:

  1. Selecione uma nova zona na mesma região com capacidade suficiente para o tipo de máquina escolhido e onde os pools de armazenamento equilibrados do Hyperdisk estão disponíveis.
  2. Elimine o conjunto de armazenamento existente e volte a criá-lo na nova zona. Isto deve-se ao facto de os conjuntos de armazenamento serem recursos zonais.
  3. Crie o cluster ou o node pool na nova zona.

O que se segue?