В Руководстве пользователя Amazon EKS есть страница , посвященная созданию контроллеров входа ALB с помощью одноименного стороннего инструмента AWS Контроллер входа ALB для Kubernetes .
Как в руководстве пользователя EKS, так и в документации к контроллеру есть свои пошаговые инструкции по настройке контроллера.
Пошаговое руководство , предоставляемое контроллером , предполагает, что вы либо жестко закодируете свой секретный ключ AWS в манифесте Deployment
, либо установите еще один сторонний инструмент под названием Kube2iam .
Пошаговое руководство в руководстве пользователя AWS EKS содержит точно такой же манифест Deployment
, но вам совсем не нужно его изменять. Вместо этого вы создаете и роль IAM (шаг 5), и учетную запись службы Kubernetes (шаг 4) для контроллера, а затем связываете их вместе, аннотируя учетную запись службы с помощью ARN для роли IAM. Prima fa cie, похоже, это то, для чего предназначен Kube2iam.
Это приводит меня к одному из трех выводов, которые я оцениваю в грубом порядке правдоподобия:
- EKS содержит функциональность Kube2iam в качестве одной из своих функций (возможно, путем включения Kube2iam в его кодовую базу), поэтому установка Kube2iam излишняя.
eksctl
устанавливает Kube2iam за кулисами как часть associate-iam-oidc-provider
. - Документация к контроллеру была написана для более ранней версии Kubernetes, и теперь эта функциональность встроена в стандартную плоскость управления.
Кто-нибудь знает, что это такое? Почему для прохождения AWS я не нужен для установки Kube2iam?