Ошибка обновления кэшированных учетных данных AWS Persistent Storage

Вопрос или проблема

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: my-ns  
spec:
  accessModes:
    - ReadWriteOnce  
  resources:
    requests:
      storage: 10Gi 
  storageClassName: gp2  


apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: my-ns
spec:
  containers:
    - name: test-container
      image: busybox  
      command: ["sleep", "3600"]  
      volumeMounts:
        - mountPath: /mnt/data  
          name: my-pvc-volume 
  volumes:
    - name: my-pvc-volume  
      persistentVolumeClaim:
        claimName: my-pvc  

Ответ или решение

Проблема, с которой вы столкнулись, касается ошибки при попытке создать постоянный том в кластере Amazon EKS, в результате чего не удается обновить кешированные учетные данные для доступа к EC2. Ошибка "failed to refresh cached credentials, no EC2 IMDS role found" указывает на то, что CSI-драйвер EBS не может получить необходимые учетные данные от EC2 Instance Metadata Service (IMDS), что обычно возникает из-за отсутствия правильных IAM-ролей или прав доступа.

Вот шаги для решения данной проблемы:

1. Проверка IAM роли для узлов кластера EKS:
   Убедитесь, что IAM-роль, назначенная узлам вашего EKS-кластера, имеет необходимые разрешения для работы с EBS. Вам необходимо убедиться, что эта роль включает в себя политику, которая позволяет доступ к EC2 и создание томов EBS. Наиболее распространенные разрешения включают:

   {
    "Effect": "Allow",
    "Action": [
      "ec2:DescribeInstances",
      "ec2:DescribeVolumes",
      "ec2:CreateVolume",
      "ec2:AttachVolume",
      "ec2:ModifyVolume",
      "ec2:DeleteVolume"
    ],
    "Resource": "*"
   }

2. Проверка назначения IAM роли:
   Убедитесь, что ваша IAM-роль действительно назначена вашим узлам EKS. Это можно сделать, проверив конфигурацию узлов через консоль AWS или с помощью AWS CLI. Для узла в публичных или частных подсетях проверьте, есть ли у него внешний доступ к услугам AWS, так как это может быть причиной избежания получения заданной информации об идентификации.

3. Проверка настроек метаданных IMDS:
   Включите доступ к IMDS на уровне инстанса. Используйте следующий CLI-код, чтобы проверить параметры:

   aws ec2 describe-instances --instance-ids <ваш_instance_id> --query 'Reservations[*].Instances[*].MetadataOptions'

   Убедитесь, что HttpTokens установлено в optional или required, а HttpEndpoint установлен в enabled.

4. Перезапуск EBS-CSI Driver:
   Если проблема не решается, попробуйте перезапустить поды драйвера EBS-CSI, чтобы обновить кэшенные учетные данные. Это можно сделать через:

   kubectl delete pod -n kube-system <имя_пода_ebs_csi>

5. Проверка сетевых настроек:
   Убедитесь, что ваши узлы могут обращаться к сервисам AWS, например, EC2 и S3. Это может требовать настройки NAT Gateway или правильной конфигурации безопасности подов и узлов.

6. Просмотр логов:
   Проверьте журналы соответствующего пода CSI EBS более внимательно, если ошибка продолжает возникать после вышеуказанных шагов.

7. Соответствие компонентам:
   Убедитесь, что версия вашего EKS-кластера совместима с версией EBS-CSI драйвера. Обновите компоненты, если это необходимо.

Если после выполнения всех вышеперечисленных шагов проблема сохраняется, вам может потребоваться дополнительная поддержка от AWS или сообществ Kubernetes.