Solução de problemas de armazenamento no GKE

Problemas com o armazenamento em clusters do Google Kubernetes Engine (GKE) podem se manifestar de várias maneiras, desde gargalos de desempenho e falhas na montagem de volumes até erros ao usar tipos de disco específicos com determinados tipos de máquina. Esses problemas podem afetar a capacidade de manter o estado do aplicativo, a persistência de dados e a integridade geral da carga de trabalho.

Use este documento para resolver problemas comuns que afetam a funcionalidade de armazenamento nos clusters. Encontre orientações sobre como resolver problemas relacionados ao provisionamento e à anexação de volumes, ao acesso e ao desempenho dos dados e ao gerenciamento da capacidade de armazenamento.

Essas informações são importantes para administradores e operadores de plataforma que gerenciam a infraestrutura e o armazenamento de clusters, além de desenvolvedores de aplicativos cujas cargas de trabalho dependem do armazenamento permanente. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do 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 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.

Alta pressão de armazenamento de nós detectada

Se você observar eventos ou condições de nó relacionados a StoragePressureRootFileSystem com o motivo StoragePressureDetected, isso indica que o sistema de arquivos raiz do nó ou um ponto de montagem de armazenamento crítico está com alto uso de disco, perto da capacidade máxima.

Ao descrever um nó usando o comando kubectl describe node NODE_NAME, talvez você veja um evento semelhante a este:

Events:
  Type     Reason                      Age   From                     Message
  ----     ------                      ----  ----                     -------
  ...
  Warning  StoragePressureDetected     46m   device-capacity-monitor  Node condition StoragePressureRootFileSystem is now: True, reason: StoragePressureDetected, message: "Disk /dev/nvme0n1 usage 89% exceeds threshold 85%"

Causa:

O motivo StoragePressureDetected significa que o uso do disco no sistema de arquivos raiz do nó (geralmente mnt/stateful_partition ou montagens relacionadas) excedeu um limite predefinido (por exemplo, 85%). Isso pode ser causado por:

  • Cargas de trabalho que gravam dados em excesso em volumes emptyDir sem suporte de SSDs locais.
  • Imagens de contêineres grandes sendo extraídas para o nó.
  • Arquivos de registros acumulados no nó.
  • Outros processos que consomem espaço em disco.

O uso alto e contínuo do disco pode levar à instabilidade do nó, remoções de pods e falhas de aplicativos.

Depuração e resolução:

Identifique o uso do disco: use SSH para se conectar ao nó afetado e use comandos como df -h para verificar o uso do disco em vários pontos de montagem, prestando atenção especial a /mnt/stateful_partition e a qualquer montagem de armazenamento efêmero.

Analise os padrões de armazenamento da carga de trabalho: revise as solicitações de armazenamento e os padrões de uso dos pods em execução no nó. Identifique se alguma carga de trabalho específica está consumindo uma quantidade desproporcional de armazenamento temporário.

Aumente a capacidade de armazenamento do nó: a resolução principal geralmente é garantir que os nós tenham capacidade de armazenamento adequada para as cargas de trabalho. Considere o seguinte:

  • Use discos de inicialização maiores: ao criar pools de nós, selecione um tamanho maior de disco de inicialização se as cargas de trabalho exigirem mais armazenamento temporário no sistema de arquivos raiz.
  • Use SSDs locais maiores para armazenamento temporário: para cargas de trabalho que exigem armazenamento temporário de alto desempenho e baixa latência, configure seus pools de nós para usar SSDs locais. Isso oferece uma capacidade separada e maior para volumes emptyDir.
  • Ajuste as solicitações ou os limites de carga de trabalho: verifique se as especificações do pod incluem solicitações e limites de armazenamento temporário adequados para ajudar o programador a colocar pods em nós com espaço suficiente e evitar o uso descontrolado do disco.
  • Limpe recursos não utilizados: remova arquivos desnecessários, imagens de contêiner antigas ou registros do nó se eles estiverem contribuindo para o alto uso do disco.

Ao resolver a capacidade e o uso de armazenamento no nó, é possível reduzir problemas relacionados a StoragePressureDetected e ajudar na operação do nó.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: