EKS AWS: не удается подключить рабочий узел

#amazon-web-services #kubernetes #amazon-eks

#amazon-web-services #kubernetes #amazon-eks

Вопрос:

Я немного застрял на этапе запуска рабочего узла в руководстве AWS EKS. И, честно говоря, на данный момент я не знаю, что не так. Когда я выполняю kubectl get svc, я получаю свой кластер, так что это хорошая новость. У меня есть это в моем aws-auth-cm.yaml

 apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::Account:role/rolename
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  

Вот моя конфигурация в .kube

 apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: CERTIFICATE
    server: server
  name: arn:aws:eks:region:account:cluster/clustername
contexts:
- context:
    cluster: arn:aws:eks:region:account:cluster/clustername
    user: arn:aws:eks:region:account:cluster/clustername
  name: arn:aws:eks:region:account:cluster/clustername
current-context: arn:aws:eks:region:account:cluster/clustername
kind: Config
preferences: {}
users:
- name: arn:aws:eks:region:account:cluster/clustername
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - clustername
      command: aws-iam-authenticator.exe
  

Я запустил экземпляр EC2 с рекомендованным AMI.

Некоторые моменты, на которые следует обратить внимание :

  • Я запустил свой кластер с помощью командной строки,
  • Я создал некоторую пару ключей,
  • Я не использую стек Cloudformation,
  • Я прикрепил эти политики к роли моего EC2: AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly, AmazonEKSWorkerNodePolicy.

Это моя первая попытка использовать kubernetes и EKS, поэтому, пожалуйста, имейте это в виду :). Спасибо за вашу помощь!

Ответ №1:

Ваш файл конфигурации и файл аутентификации выглядят правильно. Возможно, есть какая-то проблема с назначениями групп безопасности? Можете ли вы рассказать о точных шагах, которые вы выполнили для создания кластера и рабочих узлов? И есть ли какая-то особая причина, по которой вам пришлось использовать CLI вместо консоли? Я имею в виду, что если это ваша первая попытка использовать EKS, то вам, вероятно, следует попытаться настроить кластер с помощью консоли хотя бы один раз.

Комментарии:

1. Спасибо за ваш ответ! Итак, причина, по которой я не воспользовался консолью, заключается в том, что она не сработала, когда я попытался. У меня есть пользователь AD и пользователь IAM, я создал с помощью консоли кластер и так и не смог ничего получить обратно от kubectl get svc. Поэтому я прибегнул к использованию другой учетной записи пользователя IAM, но у нее нет доступа к консоли (из того, что мне сказали), и она работала с CLI …. Я думаю, что я мог что-то пропустить с разрешениями…

2. К моей учетной записи пользователя IAM прикреплены политики, связанные с материалами EKS: EC2 Limited: Список, полный доступ к реестру контейнеров Elastic, полный доступ EKS. Я использую ADFS CloudAdmin, у меня нет права на полный доступ, поэтому каждый раз, когда мне нужно что-то сделать IAM, мне нужно попросить кого-то другого (и я не думаю, что у меня получится это правильно)

3. Я посмотрел на этого пользователя IAM, у них подключены политики AmazonEKSClusterPolicy и AmazonEKSServicePolicy, поэтому, возможно, именно поэтому они могут подключаться к кластеру …? Хотя это работает с помощью cli, но не консоли (поскольку нет доступа к консоли, как я упоминал ранее)

4. Одна из возможных причин, по которой рабочие узлы не отображаются в вашем cli, возможно, связана с отсутствием разрешений. По умолчанию доступ к кластеру имеет пользователь, создавший кластер, и никто другой. Кроме того, проверьте, соответствует ли используемый вами AMI версии K8s, запущенной в вашем кластере.

5. Итак, это решило проблему? И если вы хотите сохранить конфиденциальность своих рабочих нагрузок, разверните рабочие узлы в частных подсетях и прикрепите gw или экземпляр NAT gw, чтобы разрешить доступ к ним через Интернет.

Ответ №2:

Иногда по какой-либо причине aws_auth configmap не применяется автоматически. Поэтому нам нужно добавить их вручную. У меня возникла эта проблема, поэтому оставляю ее здесь на случай, если это кому-то поможет.

  1. Проверьте, применяли ли вы уже конфигурационную карту aws-auth.

    kubectl describe configmap -n kube-system aws-auth

Если вы получаете сообщение об ошибке «Ошибка с сервера (не найдена): configmaps»aws-auth «не найден», продолжайте

  1. Загрузите карту конфигурации.

    curl -o aws-auth-cm.yaml https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml

  2. Откройте файл с помощью вашего любимого текстового редактора. Замените <ARN роли экземпляра (не профиля экземпляра)> на имя ресурса Amazon (ARN) роли IAM, связанной с вашими узлами, и сохраните файл.

  3. Примените конфигурацию.

    kubectl apply -f aws-auth-cm.yaml

  4. Следите за состоянием своих узлов и дождитесь, пока они перейдут в состояние готовности.

    kubectl get nodes --watch

Вы также можете зайти в консоль aws и найти добавляемый рабочий узел.

Дополнительную информацию можно найти здесь