Como crio e soluciono problemas de provisionamento de volume com reconhecimento de topologia que usa um driver CSI do EBS no Amazon EKS?

Breve descrição

Para configurar e solucionar problemas de uma topologia de infraestrutura de nuvem no Amazon EKS que usa componentes do Amazon EBS, conclua as seguintes etapas:

1. Verifique se o complemento EBS CSI está configurado corretamente.
2. Configure a classe de armazenamento com implementação com reconhecimento de topologia.
3. Crie um pod e uma workload e, em seguida, teste um cenário com reconhecimento de topologia.
4. Solucione erros do controlador EBS CSI.

Resolução

Observação: Se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), verifique se está usando a versão mais recente da AWS CLI.

Verifique se o complemento EBS CSI está configurado corretamente

Observação: É uma prática recomendada usar o provisionador EBS CSI ebs.csi.aws.com para provisionamento de volume do EBS. Além disso, use o provisionador EBS CSI ao implementar volumes com reconhecimento de topologia em vez do provisionador Kubernetes em árvore kubernetes.io/aws-ebs.

Para verificar se o complemento EBS CSI está configurado corretamente, conclua as seguintes etapas:

1.    Verifique se o driver CSI está instalado. Se não estiver instalado, consulte Driver CSI do Amazon EBS para instalar o driver CSI.

2.    Verifique se a função AWS Identity and Access Management (IAM) na conta de serviço tem as permissões mínimas de ação de volume do EBS.

Observação: Você deve anotar a conta de serviço com as funções do IAM para contas de serviço (IRSA). Se você não fizer anotações na conta de serviço com o IRSA, o driver CSI do Amazon EBS assumirá a função do IAM no nó de trabalho por padrão. Se o driver CSI usar como padrão o perfil do IAM no nó de trabalho, configure as permissões de perfil do IAM necessárias no Console de Gerenciamento da AWS.

Configure a classe de armazenamento com implementação com reconhecimento de topologia

1.    Execute o comando a seguir para implantar a classe de armazenamento. Edite o manifesto conforme necessário de acordo com seus requisitos específicos de implantação.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

Exemplo de manifesto:

Observação: Substitua os atributos no manifesto por aqueles específicos para seu caso de uso.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

Observação: Para uma implementação com reconhecimento de topologia, certifique-se de configurar a opção allowedTopologies. A exclusão dessa opção faz com que a zona de disponibilidade correta seja inferida e que o controlador CSI do Amazon EBS crie um volume no qual o pod está programado.

2.    Use uma das seguintes opções para criar uma declaração de PV:

(Opção 1) Crie uma declaração de pv que solicite um volume com o tipo de perfil especificado no manifesto da classe de armazenamento implantada:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(Opção 2) Crie uma declaração de pv que use um volume EBS disponível especificado no manifesto de volume persistente. Certifique-se de modificar a opção storageClassName: para uma string vazia**, “”, ** e modifique o bloco nodeAffinity conforme necessário.

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

Observação: Para a opção 1 ou a opção 2, se os nós não estiverem disponíveis na zona de disponibilidade do volume, a implantação falhará. Isso ocorre porque o agendador não pode se ajustar dinamicamente à restrição de topologia.

Crie um pod e uma carga de trabalho e teste um cenário com reconhecimento de topologia

Crie um pod

1.    Crie um pod de teste que use o pv-claim anterior:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

Observação: Quando você usa topology.ebs.csi.aws.com/zone em allowedTopologies em uma classe de armazenamento ou volume persistente, o pod é colocado na zona de disponibilidade especificada nos manifestos de configuração. Se não houver nenhum nó disponível nessa zona de disponibilidade, o pod ficará preso no estado Pendente.

2.    Execute os seguintes comandos de pod get e describe para verificar o status da implantação:

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Observação: Substitua EXAMPLE_POD_NAME pelo nome do seu pod.

Crie uma carga de trabalho

1.    Execute o comando a seguir para criar uma workload statefulSet que usa o pv-claim anterior:

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2.    Execute o seguinte comando get and describe para verificar o status da workload do StatefulSet:

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Observação: O controlador statefulSet cria algumas declarações de pv para atender à solicitação de volume dos pods para volumes nas regiões us-east-2b e us-east-2c da AWS. Não é garantido que o statefulSets na finalização limpe os volumes persistentes, o que pode fazer com que os volumes não sejam reprovisionados para os pods do statefulSet que são reprogramados para outra zona de disponibilidade.

Teste um cenário com reconhecimento de topologia

(Opcional) Para testar como a substituição de nós em outra zona de disponibilidade é tratada, simule a remodelação dos nós reduzindo a escala dos nós na AZ especificada. Em seguida, amplie novos nós em outra AZ. Quando concluído, consulte as seções Criar um pod e Criar uma workload.

Exemplo de saída sobre problema de implantação simulada:

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

Para corrigir o pod preso, aumente novamente um nó na zona de disponibilidade especificada para resolver o erro de conflito de afinidade do nó de volume.

Observação: Ao escalar um novo nó na zona de disponibilidade esperada, a implantação pode falhar devido à falha na execução do reconciliador. Para obter as etapas de solução de problemas, consulte a seção a seguir, Solucionar erros do controlador EBS CSI.

Solucionar erros do controlador EBS CSI

Exemplo de um erro CSI do EBS em que a rotatividade de pods e a reciclagem de nós foram simuladas:

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1.    Para isolar o problema, descreva o pod e revise as entradas do log de erros do evento. No exemplo de erro anterior, a mensagem mostra que quatro dos cinco nós não podem ser programados devido a manchas nos nós e à configuração de topologia ou afinidade. Além disso, o último nó em execução na zona de disponibilidade correta não encontrou um volume persistente disponível para vincular.

2.    Para isolar esse problema, verifique o status da associação pv-claim:

kubectl describe persistentvolumeclaim <PVC_NAME>

Observação: Os status do pv-claim são aguardando, vinculados, inválidos ou não encontrados. No exemplo a seguir, o pv-claim está aguardando que o driver crie um volume. Enquanto espera, o pv-claim não se vincula a um nó de destino.

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3.    Verifique os registros do contêiner csi-provisioner no pod ebs-csi-controller:

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

A saída a seguir é um exemplo de evento de erro:

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

Observação: Se ocorrerem eventos de erro semelhantes à mensagem anterior, o reconciliador pv-claim não conseguiu encontrar uma anotação do nó de destino selecionada. Remova essa anotação para que o pv-claim possa ser sincronizado com êxito.

4.    Para remover a anotação do nó de destino selecionada, execute o comando a seguir. Certifique-se de copiar e salvar a saída no manifesto pv-claim para remover a anotação do nó selecionado.

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

Se as etapas de solução de problemas em andamento não resolverem seu problema, reúna os registros da carga de trabalho do contêiner isolado e entre em contato com o AWS Support. Você também pode pesquisar problemas relacionados no repositório do GitHub.