Como soluciono problemas com minhas montagens de volumes do Amazon EBS no Amazon EKS?

7 minuto de leitura
0

Quero montar volumes do Amazon Elastic Block Store (Amazon EBS) no meu cluster do Amazon Elastic Kubernetes Service (Amazon EKS). No entanto, recebo o erro “Tempo limite expirado aguardando a conexão dos volumes ou a montagem do pod”.

Resolução

Antes de começar as etapas de solução de problemas, verifique se você tem os seguintes pré-requisitos:

  • As permissões necessárias do AWS Identity and Access Management (IAM) para seu perfil do IAM da conta de serviço ebs-csi-controller-sa.
    Observação: para solucionar problemas com sua conta de serviço, consulte a seção Verificar o perfil do IAM da conta de serviço do controlador de driver CSI do Amazon EBS e as permissões do perfil.
  • Um PersistentVolumeClaim (PVC) válido (do site do GitHub) no mesmo namespace do pod.
  • Uma definição de classe de armazenamento EBS válida que usa o provisionador em árvore kubernetes.io/aws-ebs (do site do Kubernetes). Ou uma definição de classe de armazenamento que usa o provisionador de driver Container Storage Interface (CSI) do EBS ebs.csi.aws.com (do site do GitHub).

Verifique se o controlador de driver CSI do Amazon EBS e os pods de nós estão em execução

O driver CSI do EBS consiste em pods de controlador que são executados como uma implantação e pods de nós que são executados como um conjunto de daemon. Para verificar se seu cluster executa esses pods, execute o seguinte comando:

kubectl get all -l app.kubernetes.io/name=aws-ebs-csi-driver -n kube-system

Observação: os nós de processamento do Windows e o AWS Fargate não oferecem suporte ao driver CSI do EBS.

Certifique-se de que a versão do driver CSI do EBS instalada seja compatível com a versão Kubernetes do seu cluster (no site do GitHub).

Verifique se o PVC encontrou problemas ao se vincular ao volume persistente do EBS

Para verificar se o PVC encontra problemas, execute o comando a seguir para visualizar os eventos. No comando de exemplo a seguir, substitua PVC_NAME e NAMESPACE pelos valores corretos para seu ambiente:

kubectl describe pvc PVC_NAME -n NAMESPACE

Se você usa o provisionamento dinâmico de volume, analise os eventos retornados para determinar se o provisionamento de volume foi bem-sucedido ou falhou. Você também pode ver o nome do volume persistente correspondente ao qual o PVC está vinculado, conforme mostrado no exemplo a seguir:

Name:          ebs-claim
Namespace:     default
StorageClass:  ebs-sc
Status:        Bound
Volume:        pvc-5cbd76de-6f15-41e4-9948-2bba2574e205
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com
               volume.kubernetes.io/selected-node: ip-10-0-2-57.ec2.internal
. . . . .
. . . . .
Events:
  Type    Reason                 Age                    From                                                                                      Message
  ----    ------                 ----                   ----                                                                                      -------
. . . . .
  Normal  Provisioning           5m22s                  ebs.csi.aws.com_ebs-csi-controller-57d4cbb9cc-dr9cd_8f0373e8-4e58-4dd0-b83c-da6f9ad5d5ce  External provisioner is provisioning volume for claim "default/ebs-claim"
  Normal  ProvisioningSucceeded  5m18s                  ebs.csi.aws.com_ebs-csi-controller-57d4cbb9cc-dr9cd_8f0373e8-4e58-4dd0-b83c-da6f9ad5d5ce  Successfully provisioned volume pvc-5cbd76de-6f15-41e4-9948-2bba2574e205

Se o provisionamento falhar, encontre a mensagem de erro em eventos.

Revisar os logs dos pods do controlador CSI do Amazon EBS

Para ver a causa das falhas de montagem, verifique os logs do pod do controlador. Se o volume falhar durante a criação, consulte os logs ebs-plugin e csi-provisioner. Para recuperar os logs de contêiner de ebs-plugin, execute os seguintes comandos:

kubectl logs deployment/ebs-csi-controller -n kube-system -c ebs-plugin
kubectl logs daemonset/ebs-csi-node -n kube-system -c ebs-plugin

Para recuperar os logs do contêiner csi-provisioner, execute o seguinte comando:

kubectl logs deployment/ebs-csi-controller -n kube-system -c csi-provisioner

Se os volumes do EBS não conseguirem se conectar ao pod, revise os logs do csi-attacher. Para recuperar os logs do contêiner csi-attacher, execute o seguinte comando:

kubectl logs deployment/ebs-csi-controller -n kube-system -c csi-attacher

Verificar o perfil do IAM da conta de serviço do controlador de driver CSI do Amazon EBS e as permissões do perfil

Observação: para aumentar a eficiência de depuração do driver CSI do EBS, defina as opções do log de depuração (no site do GitHub).

Certifique-se de que a conta de serviço do controlador de driver CSI do EBS esteja anotada com o perfil do IAM correto. Além disso, certifique-se de que o perfil do IAM tenha as permissões necessárias.

Os seguintes problemas resultam em erros não autorizados em seus eventos de PVC ou em seus logs do ebs-csi-controller:

1.    Para determinar se a conta de serviço do pod ebs-csi-controller tem a anotação correta, execute o seguinte comando:

kubectl describe sa ebs-csi-controller-sa -n kube-system

2.    Verifique se a seguinte anotação está presente:

eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/AmazonEKS_EBS_CSI_DriverRole

3.    Verifique se você criou o provedor IAM OpenID Connect (OIDC) para o cluster. Além disso, verifique se o perfil do IAM tem as permissões necessárias para realizar chamadas de API do EBS. Certifique-se de que a política de confiança do perfil do IAM confie na conta de serviço ebs-csi-controller-sa.

3.    Verifique se o AWS CloudTrail faz as chamadas CreateVolume, AttachVolume e DetachVolume. Para fazer isso, revise os logs do CloudTrail. Além disso, revise os logs para determinar qual entidade principal faz as chamadas. Isso ajuda a determinar se o controlador ou o perfil do IAM do nó de processamento usa o perfil do IAM da conta de serviço.

Verificar a afinidade de nós do volume persistente

Cada volume persistente tem uma afinidade de nós que limita a conexão de volumes persistentes aos nós em uma única zona de disponibilidade. Isso ocorre porque você pode conectar volumes do EBS somente a pods ou nós executados na mesma zona de disponibilidade em que você os criou. Se os pods programados para nós em uma zona de disponibilidade usarem o volume persistente do EBS em outra zona de disponibilidade, você receberá este erro:

“FailedScheduling: 1 nó(s) teve conflito de afinidade de nós de volume”

Para evitar isso, use StatefulSets (do site do Kubernetes) em vez da implantação. Isso cria um volume EBS exclusivo para cada pod dos StatefulSets na mesma zona de disponibilidade do pod.

Para verificar a afinidade de nós do volume persistente, execute o comando a seguir. Substitua PERSISTENT_VOLUME_NAME pelo nome do seu volume:

kubectl describe pv PERSISTENT_VOLUME_NAME

Observação: você não pode montar um volume do EBS em dois pods diferentes que são executados em dois nós de processamento diferentes. Você pode conectar o volume do EBS aos pods que são executados em um nó, mas não pode conectá-lo a outro nó ao mesmo tempo. Se você tentar conectar seu volume do EBS a dois pods em nós de processamento diferentes, o pod falhará e você receberá este erro:

“Aviso FailedAttachVolume 2m38s attachdetach-controller Erro de conexão múltipla para volume “pvc-1cccsdfdc8-fsdf6-43d6-a1a9-ea837hf7h57fa” Volume já está exclusivamente conectado a um nó e não pode ser conectado a outro”

Certificar que seus pods do controlador EBS tenham conectividade com a API do Amazon Elastic Compute Cloud (Amazon EC2)

Se você vir erros de tempo limite de conexão nos logs do ebs-csi-controller, o controlador CSI do EBS pode não estar conectado à API do Amazon EC2. Se os pods do controlador tiverem problemas de conectividade ao criar seu PVC, você verá este erro:

“Aviso ProvisioningFailed persistentvolumeclaim/storage-volume-1 falhou ao provisionar volume com StorageClass “ebs-sc”: rpc error: code = DeadlineExceeded desc = context deadline exceeded”

Para resolver esse erro, verifique se as sub-redes dos pods do controlador EBS têm conectividade com a API do EC2. Se você executa um cluster privado com um proxy HTTP/HTTPS, verifique se os pods do controlador CSI do EBS podem usar o proxy HTTP/HTTPS. A instalação do helm do driver CSI do EBS tem suporte com a configuração de um proxy HTTP/HTTPS (do site do Kubernetes).

Essa mensagem também pode estar relacionada a um problema com o OIDC. Para solucionar problemas de OIDC, consulte Como soluciono problemas de um provedor de OIDC e IRSA no Amazon EKS?

AWS OFICIAL
AWS OFICIALAtualizada há um ano