Узлы кластера EKS переходят из состояния готовности в состояние NotReady примерно через 30 минут с ошибками авторизации.

Вот шаги, которые я выполнил, чтобы решить эту проблему ...

1. Подключитесь к отказавшему экземпляру через SSH.

2. Выполните "aws sts get-caller-identity"

3. Обратите внимание на ARN пользователя, вероятно, это будет что-то вроде этого arn: aws: sts :: 999999999999: loaded-role / AmazonSSMRoleForInstancesQuickSetup / i-00000000000ffffff

Обратите внимание на роль здесь AmazonSSMRoleForInstancesQuickSetup, мне это кажется неправильным, но, как мне кажется, я строго следовал руководствам при создании кластера.

Проблемы на данный момент:

а) Почему эта роль используется для идентификации AWS?

б) Если это правильная роль, почему она сначала успешна, а терпит неудачу только через 30 минут после создания кластера?

c) Если это правильная роль, какие права доступа отсутствуют?

Лично мне кажется, что это неправильная роль, но я решил свою проблему, обратившись к пункту (c).

Продолжая шаги ...

4. Если эту роль проверить через службу IAM в консоли AWS, можно увидеть, что у нее нет всех необходимых разрешений, по умолчанию у нее есть:

• AmazonSSMManagedInstanceCore

5. Если предположить, что эта роль является правильной для использования, тогда к ней необходимо добавить как минимум следующую политику:

• AmazonEC2ContainerRegistryPowerUser

Прикрепите эту политику обычным способом, я допускаю, что это может предоставить больше привилегий, чем необходимо, но это на другой день.

На этом этапе конфигурация безопасности AWS должна быть правильной, но это еще не конец истории.

6. Kubernetes через процесс kubelet имеет свои собственные сопоставления ролей безопасности, которые необходимо учитывать - это сопоставление пользователей Kubernetes с пользователями IAM или ролями в AWS.

Эта конфигурация поддерживается путем редактирования карты конфигурации Kubernetes.

Отредактируйте конфигурационную карту с помощью «kubectl edit -n kube-system configmap / aws-auth».

Это конфигурация сразу после создания кластера, до внесения каких-либо изменений:

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::999999999999:role/eksctl-my-demo-nodegroup-my-demo-NodeInstanceRole-AAAAAAAAAAAAA
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
  [...whatever...]

Единственная роль, отображаемая здесь, - это роль экземпляра узла - эта роль была создана автоматически во время подготовки кластера через eksctl.

7. Измените конфигурационную карту:

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::999999999999:role/eksctl-my-demo-nodegroup-my-demo-NodeInstanceRole-AAAAAAAAAAAAA
      username: system:node:{{EC2PrivateDNSName}}
      groups:
      - system:bootstrappers
      - system:nodes
    - rolearn: arn:aws:iam::999999999999:role/AmazonSSMRoleForInstancesQuickSetup
      username: MyDemoEKSRole
      groups:
      - system:masters
    - rolearn: arn:aws:iam::999999999999:role/MyDemoEKSRole
      username: CodeBuild
      groups:
      - system:masters
      - system:bootstrappers
      - system:nodes
kind: ConfigMap
metadata:
  [...whatever...]

Я сопоставил роль AmazonSSMRoleForInstancesQuickSetup как ведущую роль Kubernetes.

Я также нанес на карту MyDemoEKSRole роль безопасности кластера, ранее созданная для подготовки кластера к различным ролям Kubernetes, для случая, когда Kubernetes вызывается конвейером CodeBuild.

8. Сохраните эту конфигурационную карту, и в конечном итоге кластер восстановит себя и будет готов отчет.

Вывод:

После выполнения всех этих шагов после создания кластера мои сбои аутентификации прекратились, и кластер снова начал сообщать об успешном статусе, очищая проверку работоспособности и возвращая узел в Ready положение дел.

Я открыто признаю, что это может быть не «правильный» способ решения моей проблемы, и мне определенно кажется, что я открыл путь безопасности больше, чем должен был, но это определенно сработало и решило мою проблему.

Как упоминалось вскоре после этого, мы перешли на Azure вместо AWS, поэтому я больше не пошел в этом направлении, но в итоге у меня получился полностью рабочий кластер без устаревших учетных данных.

Наивно полагаю, я ожидал, что инструменты создадут для меня рабочий кластер. Ни в одном найденном мной руководстве нигде не было упоминания об этой проблеме или этих шагах.

Похоже, ваша роль истекает.

Вы можете получить помощь от Amazon EKS Устранение неполадок раздел Unauthorized or Access Denied (kubectl).

Если вы получаете одну из следующих ошибок во время работы kubectl команды, тогда ваш kubectl неправильно настроен для Amazon EKS или учетные данные пользователя или роли IAM, которые вы используете, не сопоставлены с пользователем Kubernetes RBAC с достаточными разрешениями в вашем кластере Amazon EKS.

• could not get token: AccessDenied: Access denied

• error: You must be logged in to the server (Unauthorized)

• error: the server doesn't have a resource type "svc"

Это может быть связано с тем, что кластер был создан с одним набором учетных данных AWS (от пользователя или роли IAM), и kubectl использует другой набор учетных данных.

При создании кластера Amazon EKS объект IAM (пользователь или роль), который создает кластер, добавляется в таблицу авторизации Kubernetes RBAC в качестве администратора (с system:master разрешения). Изначально только этот пользователь IAM может звонить на сервер Kubernetes API, используя kubectl. Для получения дополнительной информации см. Управление пользователями или ролями IAM для вашего кластера. Так же AWS IAM Authenticator для Kubernetes использует AWS SDK для Go для аутентификации в вашем кластере Amazon EKS. Если вы используете консоль для создания кластера, вы должны убедиться, что те же учетные данные пользователя IAM находятся в цепочке учетных данных AWS SDK при запуске kubectl команды в вашем кластере.

Если вы устанавливаете и настраиваете интерфейс командной строки AWS, вы можете настроить учетные данные IAM для своего пользователя. Если интерфейс командной строки AWS настроен для вашего пользователя правильно, то AWS IAM Authenticator для Kubernetes также можно найти эти учетные данные. Для получения дополнительной информации см. Настройка AWS CLI в Руководство пользователя интерфейса командной строки AWS.

Если вы взяли на себя роль для создания кластера Amazon EKS, вы должны убедиться, что kubectl настроен на выполнение той же роли. Используйте следующую команду, чтобы обновить файл kubeconfig для использования роли IAM. Для получения дополнительной информации см. Создайте kubeconfig для Amazon EKS.

aws --region `region-code` eks update-kubeconfig --name `cluster_name` --role-arn arn:aws:iam::`aws_account_id`:role/`role_name

Чтобы сопоставить пользователя IAM с пользователем Kubernetes RBAC, см. Управление пользователями или ролями IAM для вашего кластера или смотреть видео о том, как отобразить пользователя.

Вы должны прочитать о Управление аутентификацией кластера для AWS и Создайте kubeconfig для Amazon EKS.

Имейте в виду, что вам следует использовать aws-iam-authenticator процесс установки доступен Вот.

Когда вы развертываете группу узлов, вы должны предоставить роль группы узлов, как описано в документе (AWS-auth-cm.yaml)

Мои узлы перешли в NotReady с ошибками, как в вопросе выше, через ~ 7 минут после запуска, несмотря на то, что все модули выглядели нормально.

Причина: роль группы узлов не была такой же, как роль в этом yaml из-за опечатки.