Solução de problemas de armazenamento no GKE

Nesta página, mostramos como resolver problemas com volumes implantados nos clusters do Google Kubernetes Engine (GKE).

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 DP regional 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:

  • docker images
  • 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 o seguinte 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

Sintoma e diagnóstico

Exemplo de erro nos registros do ambiente de execução do contêiner do k8s_node:

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 e versões posteriores, e as versões do GKE com a 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. A alteração direta de um PersistentVolume pode resultar na não expansão do volume. 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.

Mitigação

  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.

Mitigação

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 sinalização count do SSD local, e o valor correto será configurado automaticamente.