Solução de problemas de armazenamento no GKE

Autopilot Standard

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:

Consulte as comparações de tipo de disco de armazenamento e escolha um tipo de disco permanente que atenda às suas necessidades.
Esse problema geralmente ocorre em nós que usam discos permanentes padrão com um tamanho menor que 200 GB. Considere aumentar o tamanho dos discos ou alternar para SSDs, especialmente para clusters usados na produção.
Considere ativar o SSD local para o armazenamento temporário nos pools de nós. Isso é particularmente eficaz se você tem contêineres que usam volumes emptyDir com frequência.

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:

Reduza o número de arquivos no volume.
Pare de usar a configuração [fsGroup].
Altere o aplicativo fsGroupChangePolicy para OnRootMismatch.

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

Se os pods falharem, use restartPolicy:Always ou restartPolicy:OnFailure no PodSpec.
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:

Mantenha o objeto PersistentVolume modificado.
Edite o objeto PersistentVolumeClaim e defina spec.resources.requests.storage com um valor superior ao usado no PersistentVolume.
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.

A seguir