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 de montagem de volume até erros ao usar tipos de disco específicos com determinados tipos de máquina. Esses problemas podem afetar 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 anexo de volumes, ao acesso e desempenho de 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 e para desenvolvedores de aplicativos cujas cargas de trabalho dependem de armazenamento permanente. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Cloud de Confiance by S3NS , consulte Papéis 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 pool de armazenamento do Hyperdisk.

Isso acontece quando você tenta criar um cluster do GKE ou pool de nós 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, se aproximando da capacidade.

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 que não têm suporte de SSDs locais.
  • Imagens de contêiner grandes sendo extraídas para o nó.
  • Arquivos de registro acumulados no nó.
  • Outros processos que consomem espaço em disco.

O uso contínuo de disco pode causar instabilidade de nós, remoções de pods e falhas de aplicativos.

Depuração e resolução:

Identificar o uso do disco: use o 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 muita atenção a /mnt/stateful_partition e a todas as montagens de armazenamento temporário.

Analisar padrões de armazenamento de cargas de trabalho: analise 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.

Aumentar a capacidade de armazenamento do nó: a principal resolução 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 de disco de inicialização maior 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 os pools de nós para usar SSDs locais. Isso fornece uma capacidade maior e separada para volumes emptyDir.
  • Ajustar solicitações ou 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 excessivo de disco.
  • Limpar 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 de armazenamento e o uso no nó, é possível mitigar problemas relacionados a StoragePressureDetected e ajudar na operação do nó.

Resolver problemas de eventos de falta de memória (OOM) do Cloud Storage FUSE

Se os pods tiverem alto uso de memória ou eventos de falta de memória (OOM) relacionados ao driver CSI do Cloud Storage FUSE, use o Cloud Profiler para coletar e analisar snapshots de CPU e memória. Configure essas opções em Configurar o contêiner secundário do driver CSI do Cloud Storage FUSE.

Quando um pod é encerrado por OOM, é possível correlacionar o evento ao snapshot correto do Cloud Profiler usando o seguinte fluxo de trabalho:

  1. Verifique o Cloud Logging:acesse o Cloud Logging para encontrar o evento de OOM do Kubernetes.

  2. Filtrar por nome do pod:execute a consulta a seguir para localizar os registros de eventos do pod específico, substituindo POD_NAME pelo nome do pod da carga de trabalho:

    jsonPayload.involvedObject.name="POD_NAME"
jsonPayload.involvedObject.kind="Pod"
OOMKilled

  3. Extraia o UID do pod:expanda o log de eventos de OOM relevante e anote o carimbo de data/hora e o UID exato do pod localizado em jsonPayload.involvedObject.uid.

  4. Analisar no Cloud Profiler:acesse o Cloud Profiler, filtre a Versão do serviço usando o formato POD_NAME_POD_UID e ajuste o período para corresponder ao carimbo de data/hora da OOM. Isso ajuda a garantir que você esteja analisando o perfil de memória exato da instância de contêiner específica logo antes de ela ser encerrada.

Cargas de trabalho com estado travadas no estado Pending devido à capacidade de computação insuficiente

Se você tiver cargas de trabalho com estado que estão travadas em um estado Pending com mensagens de erro como ZONE_RESOURCE_POOL_EXHAUSTED ou GCE_STOCKOUT, uma zona específica pode ter capacidade de computação limitada.

Quando um nó de computação fica off-line em uma zona sem capacidade suficiente, a substituição desse nó pode falhar. Os pods com estado que dependem de PersistentVolumes zonais preexistentes (como um disco pd-ssd ou pd-balanced padrão) são limitados à zona em que esse volume foi criado. Como o pod precisa ser programado nessa zona específica para montar o volume, ele permanece Pending até que a capacidade de computação nessa zona esteja disponível.

Para reduzir esse problema em futuras cargas de trabalho com estado, considere o seguinte:

  • Evite fallbacks na mesma zona entre pd-ssd e pd-balanced:como os volumes pd-ssd e pd-balanced compartilham os mesmos limites de capacidade e pools de disponibilidade em uma zona, mudar o StorageClass de pd-ssd para pd-balanced na mesma zona não vai resolver a falta de capacidade. Não tente fazer isso como um substituto.
  • Use formatos compatíveis com o Hyperdisk:algumas séries de máquinas são compatíveis com Hyperdisks. Considere usar um formato compatível com o Hyperdisk, porque eles podem ter restrições de disponibilidade diferentes que ajudam quando uma zona não tem capacidade suficiente. Antes de migrar cargas de trabalho, verifique se você tem cotas de disco suficientes.
  • Ativar a vinculação de topologia dinâmica (WaitForFirstConsumer): ao criar novas cargas de trabalho com estado, configure a definição de StorageClass com o par de campo-valor volumeBindingMode: WaitForFirstConsumer. Essa configuração adia a criação do volume até que um pod seja programado para um nó íntegro em uma zona com capacidade de computação suficiente, o que ajuda a evitar que a criação prematura de volume bloqueie o pod em uma zona off-line ou esgotada.
  • Configurar a seleção automática do tipo de disco para fallbacks de VM:no GKE versão 1.35.3-gke.1290000 e posterior, é possível configurar ComputeClasses personalizadas para cargas de trabalho que fazem fallback entre gerações de VM (por exemplo, N4 para N2 ou C4 para C2). Ao usar a seleção automática de tipo de disco, é possível configurar uma definição de StorageClass com os pares de campo-valor parameters.type: dynamic e use-allowed-disk-topology: "true". Essa configuração permite que o GKE provisione automaticamente discos hyperdisk-balanced em gerações de máquinas mais recentes e use discos pd-balanced em gerações mais antigas.

A seguir