Resolução de problemas de armazenamento no GKE

Os problemas com o armazenamento em clusters do Google Kubernetes Engine (GKE) podem manifestar-se de várias formas, desde gargalos de desempenho e falhas de montagem de volumes a erros ao usar tipos de discos específicos com determinados tipos de máquinas. Estes problemas podem afetar a capacidade de manter o estado das aplicações, a persistência dos dados e o estado geral da carga de trabalho.

Use este documento para resolver problemas comuns que afetam a funcionalidade de armazenamento nos seus clusters. Encontre orientações sobre a resolução de problemas relacionados com o aprovisionamento e a associação de volumes, o acesso aos dados e o desempenho, bem como a gestão da capacidade de armazenamento.

Estas informações são importantes para os administradores e os operadores da plataforma que gerem a infraestrutura de clusters e o armazenamento, bem como para os programadores de aplicações cujas cargas de trabalho dependem do armazenamento persistente. Para mais informações sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

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

Os discos persistentes regionais estão restritos para utilização com máquinas otimizadas para memória ou máquinas otimizadas para computação.

Considere usar uma classe de armazenamento de disco persistente não regional se usar um disco persistente regional não for um requisito obrigatório. Se a utilização de um disco persistente regional for um requisito obrigatório, considere estratégias de agendamento, como contaminações e tolerâncias para garantir que os pods que precisam de discos persistentes regionais são agendados num conjunto de nós que não são máquinas otimizadas.

Resolução de problemas com o desempenho do disco

O desempenho do disco de arranque é importante porque o disco de arranque dos nós do GKE não é usado apenas para o sistema operativo, mas também para o seguinte:

  • Imagens de Docker.
  • O sistema de ficheiros do contentor para o que não está montado como um volume (ou seja, o sistema de ficheiros de sobreposição) e isto inclui frequentemente diretórios como /tmp.
  • Volumes emptyDir baseados em disco, a menos que o nó use um SSD local.

O desempenho do disco é partilhado por todos os discos do mesmo tipo de disco num nó. Por exemplo, se tiver um disco de arranque de 100 GB pd-standard e um PersistentVolume de 100 GB pd-standard com muita atividade, o desempenho do disco de arranque é o de um disco de 200 GB. Além disso, se houver muita atividade no PersistentVolume, isso também afeta o desempenho do disco de arranque.

Se encontrar mensagens semelhantes às seguintes nos seus nós, 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 estes problemas, reveja o seguinte:

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

Um problema que pode fazer com que a montagem do PersistentVolume falhe é um pod configurado com a definição fsGroup. Normalmente, as montagens são repetidas automaticamente e a falha de montagem resolve-se sozinha. No entanto, se o PersistentVolume tiver um grande número de ficheiros, o kubelet tenta alterar a propriedade de cada ficheiro no sistema de ficheiros, o que pode aumentar a latência de montagem do volume.

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

Para confirmar se um erro de montagem com falha se deve à definição fsGroup, pode verificar os registos do pod. Se o problema estiver relacionado com a definição fsGroup, é apresentada a seguinte entrada no registo:

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 dentro de alguns minutos, experimente os seguintes passos para resolver este problema:

As operações lentas do disco causam falhas na criação de pods

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

Versões de nós 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 seguintes exemplos de erros podem ser apresentados nos registos 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 estiverem a falhar, considere usar restartPolicy:Always ou restartPolicy:OnFailure no seu PodSpec.
  2. Aumente os IOPS do disco de arranque (por exemplo, atualize o tipo de disco ou aumente o tamanho do disco).

Corrigir

Este problema foi corrigido no containerd 1.6.0 e versões posteriores. As versões do GKE com esta correção são 1.20.15-gke.2100 e versões posteriores, 1.21.9-gke.2000 e versões posteriores, 1.21.10-gke.100 e versões posteriores, 1.22.6-gke.2000 e versões posteriores, 1.22.7-gke.100 e versões posteriores, 1.23.3-gke.1700 e versões posteriores, e 1.23.4-gke.100 e versões posteriores

As alterações de expansão do volume não se refletem no sistema de ficheiros do contentor

Quando realizar a expansão do volume, certifique-se sempre de que atualiza o PersistentVolumeClaim. A alteração direta de um PersistentVolume pode impedir a expansão do volume. Isto pode levar a um dos seguintes cenários:

  • Se um objeto PersistentVolume for modificado diretamente, os valores PersistentVolume e PersistentVolumeClaim são atualizados para um novo valor, mas o tamanho do sistema de ficheiros não se reflete no contentor e continua a usar o tamanho do volume antigo.

  • Se um objeto PersistentVolume for modificado diretamente, seguido de atualizações ao PersistentVolumeClaim em que o campo status.capacity é atualizado para um novo tamanho, isto pode resultar em alterações ao PersistentVolume, mas não ao PersistentVolumeClaim nem ao sistema de ficheiros do contentor.

Para resolver este problema, conclua os seguintes passos:

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

Após estas alterações, o kubelet deve redimensionar automaticamente o PersistentVolume, o PersistentVolumeClaim e o sistema de ficheiros do contentor.

Verifique se as alterações são refletidas no Pod.

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

Substitua POD_NAME pelo pod associado a PersistentVolumeClaim.

O tipo de máquina selecionado deve ter SSDs locais

Pode encontrar o seguinte erro ao criar um cluster ou um conjunto de nós que usa um 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, pode ver LocalNvmeSsdBlockConfig em vez de EphemeralStorageLocalSsdConfig, consoante o que especificou.

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

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

Hyperdisk Storage Pools: a criação do cluster ou do node pool falha

Pode encontrar o erro ZONE_RESOURCE_POOL_EXHAUSTED ou erros semelhantes de recursos do Compute Engine quando tenta aprovisionar discos Hyperdisk Balanced como discos de arranque ou anexados do seu nó num Hyperdisk Storage Pool.

Isto acontece quando tenta criar um cluster ou um node pool do GKE numa zona com poucos recursos, por exemplo:

  • A zona pode não ter discos Hyperdisk Balanced 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 este 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 equilibrados do Hyperdisk estão disponíveis.
  2. Elimine o conjunto de armazenamento existente e volte a criá-lo na nova zona. Isto deve-se ao facto de os conjuntos de armazenamento serem recursos zonais.
  3. Crie o cluster ou o node pool na nova zona.

Pressão de armazenamento de nós elevada detetada

Se observar eventos ou condições de nós relacionados com StoragePressureRootFileSystem com o motivo StoragePressureDetected, indica que o sistema de ficheiros raiz do nó ou um ponto de montagem de armazenamento crítico está a registar uma utilização elevada do disco, aproximando-se da respetiva capacidade.

Quando descreve um nó através do comando kubectl describe node NODE_NAME, pode ver um evento semelhante ao seguinte:

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 a utilização do disco no sistema de ficheiros raiz do nó (frequentemente mnt/stateful_partition ou montagens relacionadas) excedeu um limite predefinido (por exemplo, 85%). Isto pode dever-se ao seguinte:

  • Cargas de trabalho que escrevem dados excessivos em volumes emptyDir que não são suportados por SSDs locais.
  • Imagens de contentores grandes a serem extraídas para o nó.
  • Ficheiros de registo acumulados no nó.
  • Outros processos que consomem espaço em disco.

A utilização elevada contínua do disco pode levar à instabilidade do nó, à remoção de pods e a falhas de aplicações.

Depuração e resolução:

Identifique a utilização do disco: use o SSH para estabelecer ligação ao nó afetado e use comandos como df -h para verificar a utilização do disco em vários pontos de montagem, prestando especial atenção a /mnt/stateful_partition e a quaisquer montagens de armazenamento efémeras.

Analise os padrões de armazenamento da carga de trabalho: reveja os pedidos de armazenamento e os padrões de utilização dos pods em execução no nó. Identifique se alguma carga de trabalho específica está a consumir uma quantidade desproporcionada de armazenamento efémero.

Aumente a capacidade de armazenamento dos nós: tenha em atenção que a resolução principal é, muitas vezes, garantir que os nós têm capacidade de armazenamento adequada para as suas cargas de trabalho. Considere o seguinte:

  • Use discos de arranque maiores: quando criar pools de nós, selecione um tamanho de disco de arranque maior se as suas cargas de trabalho exigirem mais armazenamento efémero no sistema de ficheiros raiz.
  • Use SSDs locais maiores para armazenamento efémero: para cargas de trabalho que exigem armazenamento efémero de elevado desempenho e baixa latência, configure os seus conjuntos de nós para usar SSDs locais. Isto oferece uma capacidade separada e maior para volumes emptyDir.
  • Ajuste os pedidos ou os limites de carga de trabalho: certifique-se de que as especificações do pod incluem pedidos e limites de armazenamento efémero adequados para ajudar o programador a colocar pods em nós com espaço suficiente e evitar a utilização descontrolada do disco.
  • Limpe os recursos não usados: remova ficheiros desnecessários, imagens de contentores antigas ou registos do nó se estiverem a contribuir para a elevada utilização do disco.

Ao resolver a capacidade de armazenamento e a utilização no nó, pode mitigar problemas relacionados com StoragePressureDetected e ajudar no funcionamento do nó.

O que se segue?