Solução de problemas de armazenamento no GKE

Nesta página, mostramos como resolver problemas relacionados ao armazenamento nos clusters do Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

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

Os discos permanentes regionais não podem ser usados com máquinas com otimização de memória ou com otimização para computação.

Considere usar uma classe de armazenamento em disco permanente não regional se o uso de um disco permanente regional não for um requisito absoluto. Se o uso de um disco permanente regional for um requisito difícil, programe estratégias como taints e tolerâncias para garantir que os pods que precisam de discos permanentes regionais sejam programados em um pool de nós que não sejam máquinas otimizadas.

Solução de problemas com o desempenho do disco

O desempenho do disco de inicialização é importante porque o disco de inicialização de nós do GKE não é usado apenas para o sistema operacional, mas também para:

  • Imagens Docker.
  • O sistema de arquivos de contêiner para o que não está ativado como um volume (ou seja, o sistema de arquivos de sobreposição), e isso geralmente inclui diretórios como /tmp.
  • Volumes emptyDir de suporte de disco, a menos que o nó use SSD local.

O desempenho do disco é compartilhado por todos os discos do mesmo tipo de disco em um nó. Por exemplo, se você tiver um disco de inicialização pd-standard de 100 GB e um PersistentVolume de 100 GB pd-standard com muita atividade, o desempenho do disco de inicialização será de 200 GB. Além disso, se houver muita atividade no PersistentVolume, o desempenho do disco de inicialização também será afetado.

Se você encontrar mensagens semelhantes a estas nos nós, estes 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 esses problemas, analise o seguinte:

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

Um problema que pode causar falha na montagem de PersistentVolume é um pod configurado com a configuração fsGroup. Normalmente, as montagens são repetidas automaticamente, e a falha na montagem se resolve. No entanto, se o PersistentVolume tiver um grande número de arquivos, o kubelet tentará alterar a propriedade em cada arquivo no sistema de arquivos, o que pode aumentar a latência de montagem de volume.

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

Para confirmar se um erro de ativação falhou devido à configuração fsGroup, verifique os registros do pod. Se o problema estiver relacionado à configuração fsGroup, você verá a seguinte entrada de registro:

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 em alguns minutos, tente as etapas a seguir para resolver esse problema:

Operações de disco lento causam falhas na criação de pods

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

Versões de nó 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 erros de exemplo a seguir podem ser exibidos nos registros 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 falharem, use restartPolicy:Always ou restartPolicy:OnFailure no PodSpec.
  2. Aumente as IOPS do disco de inicialização. Por exemplo, faça upgrade do tipo de disco ou aumente o tamanho dele.

Corrigir

Esse problema foi corrigido no containerd 1.6.0+. As versões do GKE com essa 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 de volume não são refletidas no sistema de arquivos do contêiner

Ao executar a expansão de volume, sempre atualize o PersistentVolumeClaim. Alterar um PersistentVolume diretamente pode fazer com que a expansão de volume não aconteça. Isso pode levar a um dos seguintes cenários:

  • Se um objeto PersistentVolume for modificado diretamente, os valores PersistentVolume e PersistentVolumeClaim serão atualizados para um novo valor, mas o tamanho do sistema de arquivos não será refletido no contêiner e ainda usará o tamanho antigo do volume.

  • Se um objeto PersistentVolume for modificado diretamente, seguido por atualizações no PersistentVolumeClaim em que o campo status.capacity foi atualizado para um novo tamanho, isso poderá resultar em mudanças no PersistentVolume, mas não no PersistentVolumeClaim ou no sistema de arquivos do contêiner.

Para resolver esse problema, siga estas etapas:

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

Depois dessas alterações, o PersistentVolume, o PersistentVolumeClaim e o sistema de arquivos do contêiner precisam ser redimensionados automaticamente pelo kubelet.

Verifique se as alterações estão refletidas no pod.

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

Substitua POD_NAME pelo pod anexado ao PersistentVolumeClaim.

O tipo de máquina selecionado precisa ter SSDs locais

Talvez você encontre o seguinte erro ao criar um cluster ou pool de nós que usa o 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, você pode ver LocalNvmeSsdBlockConfig em vez de EphemeralStorageLocalSsdConfig, dependendo do que foi especificado.

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

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

Pools de armazenamento do Hyperdisk: falha na criação de cluster ou pool de nós

Você pode encontrar o erro ZONE_RESOURCE_POOL_EXHAUSTED ou erros de recurso do Compute Engine semelhantes ao tentar provisionar discos Hyperdisk Balanced como discos de inicialização ou anexados do nó em um Hyperdisk Storage Pool.

Isso acontece quando você tenta criar um cluster ou pool de nós do GKE em uma zona com poucos recursos, por exemplo:

  • A zona pode não ter discos do Hyperdisk equilibrado 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 o 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 balanceado de hiperdisco estão disponíveis.
  2. Exclua o pool de armazenamento e recrie-o na nova zona. Isso ocorre porque os pools de armazenamento são recursos zonais.
  3. Crie o cluster ou o pool de nós na nova zona.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.