AWS Elastic Kubernetes Service: – автоматизация создания кластера, часть 2 — Ansible, eksctl

Первая часть – AWS: Elastic Kubernetes Service – автоматизация создания кластера, часть 1 – CloudFormation.

Напомню, что общая идея заключается в следующем:

1. Ansible использует модуль cloudformation , создаёт инфрастуктуру
2. используя Outputs созданного стека CloudFormation – Ansible из шаблона генерирует файл настроек для eksctl
3. Ansible вызывает eksctl, передавая ему конфиг кластера, и создаёт или обновляет кластер

Запускаться всё будет из Jenkins-джоб, используя Docker с AWS CLI, Ansible и eksctl. Возможно – это будет третья часть серии.

Все получившиеся в результате написания файлы доступны в репозитории eksctl-cf-ansible – тут ссылка на бранч с результатами, получившимися именно в конце написания этого и предыдущего постов. Возможно потом будут ещё изменения.

AWS Authentification

Лучше продумать сразу, что бы потом не переделывать всё с нуля (я переделывал).

Категорически рекомендую к прочтению Kubernetes: знакомство, часть 4 — аутентификация в AWS EKS, aws-iam-authenticator и AWS IAM.

Нам потребуется какой-то продуманный механизм аутентификации в AWS, т.к. туда будут обращаться:

• Ansible для роли cloudformation
• Ansible для роли eksctl
• Ansible для вызова AWS CLI

Самая неочевидная проблема тут это то, что IAM-пользователь, который создаёт стек EKS становится его “супер-администратором” – и изменить это потом нельзя никак.

К примеру, в предыдущем посте мы создали кластер с помощью:

В CloudWatch проверяем логи аутентификатора, самые первые записи – и видим нашего корневого пользователя из группы system:masters в правами kubernetes-admin:

Что мы можем использовать для аутентифицикации в AWS?

1. ключи доступа – AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY
2. именованные профили доступа
3. AWS IAM EC2 Instance профайлы (см. также AWS: IAM AssumeRole — описание, примеры)

В целом – всё будет запускаться с EC2 с Jenkins, которому мы можем подключить IAM роль с доступами.

Пока у меня вырисовывается такая схема:

• руками создаём IAM пользователя, назовём его eks-root, ему подключаем политику EKS Admin
• Jenkins создаёт ресурсы, используя свою IAM Instance роль, к которой подключена политика EKS Admin, и становится “супер-админом” всех создаваемых кластеров
• в Ansible добавим вызов eksctl create iamidentitymapping (см. Managing IAM users and roles)

Проверяем aws-auth ConfigMap сейчас:

Или так:

Попробуем добавить руками, что бы потом в автоматизации не столкнуться с неожиданностями:

1. создаём IAM пользовалея
2. “EKS Admin”-политику с разрешением на любые действия с EKS
3. подключаем ему политику EKS Admin
4. настраиваем локальный AWS CLI на профиль этого юзера
5. настраиваем локальный kubectl на профиль этого юзера
6. выполняем eksctl create iamidentitymapping
7. выполняем kubectl get nodes

Выполняем – создаём пользователя:

Создаём ему ключи доступа:

Настраиваем локальный AWS CLI профиль:

Пробуем доступ – должно вернуть ошибку:

Создаём политику – примеры тут>>> (позже её создание можно добавить в отдельный дочерний стек CloudFormation наашей роли cloudformation, аналогично будут создаваться SecurityGroups), сохраним пока в отдельном файле ../../cloudformation/files/eks-root-policy.json:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "eks:*"
            ],
            "Resource": "*"
        }
    ]
}

Добавляем её в IAM:

Подключаем политику к пользователю:

Проверяем:

Ещё раз проверяем доступ к кластерам EKS:

И в другом регионе:

Дальше – лучше сделать с машины, на которой никаких доступов не настроено вообще, например – с сервера, на котором хостится RTFM 🙂

Устанвливаем AWS CLI:

Настраиваем дефолтный профиль:

Проверяем доступ к AWS EKS вообще – в IAM-политике: права на eks:ListClusters есть – должно сработать:

Устанавливаем eksctl:

Повторяем eks:ListClusters – тоже должна сработать, т.к. eksctl использует профили AWS CLI:

Устанавливаем kubectl:

Устанавливаем aws-iam-authenticator, что бы kubectl мог выполнить аутентифицию в AWS:

Пробуем выполнить команду на кластере – должны получить отказ авторизации:

Слава богу – хоть что-то не работает, как запланировано 🙂

Возвращаемся к рабочей машине – и подключаем юзера eks-root в aws-auth ConfigMap:

Ещё раз проверяем:

Возвращаемся к тестовой машине – проверяем доступ оттуда:

И “копнём поглубже” – посмотрим системный ConfigMap, например – тот же aws-auth:

mapUsers с нашим пользователем добавлен – замечательно.

Далее – можем использовать aws-auth для добавления новых пользователей – или добавим в Ansible задачу, которая будет выполнять eksctl create iamidentitymapping, либо – будем генерировать свой файл с ConfigMap, и загружать его в EKS.

Имеет смысл перенести дальнейшую разработку уже на Jenkins-хост – благо vim нам доступен везде.

Ansible CloudFormation

CloudFormation Parameters и Ansible переменные

Перед тем, как начинать – подумаем, какие параметры используются в CloudFormation стеке и какие потребуются в ролях Ansible.

Первым, что в голову приходит – у нас будут Dev, Stage, Production кластера + один динамический для QA (возможность из Jenkins создать новый кластер для тестирования чего-либо), значит – параметры должны быть гибкими – мочь создать в любом регионе с любыми сетями для VPC.

Следовательно:

• общие параметры для всех:
  • регион
  • AWS access/secret (или IAM EC2 Instance Profile)
• отдельные параметры для каждого из окружений:
  • ENV(dev, stage, prod)
  • VPC сеть (10.0.0.0/16, 10.1.0.0/16, etc)
  • SSH ключ для доступа на Kubernetes Worker Nodes
  • типы AWS ЕС2 инстансов для Kubernetes Worker Nodes (t3.nano, c5.9xlarge, etc)

В особенности стоит обратить внимание на имена стеков и кластеров – иначе потом будет хаос и ад перфекциониста.

У нас будут четыре имени, которые используются “глобально” и будут отображаться в AWS Console:

1. имя окружения – dev, stage, prod
2. имя CloudFromation стека, который создаём мы (рутовый и его дочерние стеки)
3. имя CloudFromation стека, который создаётся eksctl при создании кластера и стека для WorkerNodes
4. имя самого EKS кластера

eksctl, само собой, немного занимается самодеятельностью, и добавляет к именам свои префиксы-постфиксы.

Например, при создании стека для EKS к имени CloudFormation стека будет добавлен префикс eksctl- и постфикс -cluster, а для WokerNodes – префикс eksctl- и постфикс -nodegroup + имя WorkerNodes группы, как оно позже будет указано в файле настроек кластера.

При этом сам кластер будет создан с тем именем, которое мы укажем в том же eks-cluster-config.yml.

Собираем всё вместе – используем следующие имена переменных и их значения:

• env:
  • формат: строка “dev“
  • описание: используется для формирования значений для остальных переменных
  • результат – dev
• eks_cluster_name:
  • формат: bttrm-eks-${env}
  • описание: задаст metadata: name: файла настроек eks-cluster-config.yml, участвствует в формировании значений других переменных и тегов CloudFormation
  • результат – bttrm-eks-dev
• cf_stack_name:
  • формат: eksctl-${eks_cluster_name}-stack
  • описание:  последним словом обозначаем, что данный стек содержит только инфрастуктурные ресурсы AWS, без EKS
  • результат: eksctl-bttrm-eks-dev-stack
• (AUTO) eks_cluster_stack_name:
  • формат: eksctl-${cluster_name}-cluster
  • описание: формируется самим eksctl как имя CloudFormation-стека, нигде не указываем, просто имеем ввиду
  • результат: eksctl-bttrm-eks-dev-cluster
• (AUTO) eks_nodegroup_stack_name:
  • формат: eksctl-${cluster_name}-nodegroup-${worker-nodes-name}, где worker-nodes-name – значение из nodeGroups: - name: файла настроек eks-cluster-config.yml
  • описание: формируется самим eksctl как имя CloudFormation-стека, нигде не указываем, просто имеем ввиду
  • результат: eksctl-bttrm-eks-dev-cluster

По поводу разделения переменных по файлам — пока не будем ломать себе голову, используем общий group_vars/all.yml, а по ходу дела посмотрим как их лучше раскидать.

Создаём каталог:

В нём файл all.yml, и приводим его к виду:

###################
# ANSIBLE globals #
###################

ansible_connection: local

#####################
# ENV-specific vars #
#####################

env: "dev"

#################
# ROLES globals #
#################

region: "eu-west-2"

# (THIS) eks_cluster_name: used for EKS service to set an exactly cluster's name - "{{ eks_cluster_name }}"
# (AUTO) eks_cluster_stack_name: used for CloudFormation service to format a stack's name as "eksctl-{{ eks_cluster_name }}-cluster"
# (AUTO) eks_nodegroup_stack_name: used for CloudFormation service to format a stack's name as "eksctl-{{ eks_cluster_name }}-nodegroup-{{ worker-nodes-name }}"
eks_cluster_name: "bttrm-eks-{{ env }}"

# used bythe cloudformation role to st a stack's name
cf_stack_name: "eksctl-{{ eks_cluster_name }}-stack"

##################
# ROLES specific #
##################

# cloudforation role
vpc_cidr_block: "10.0.0.0/16"

Заодно сразу сюда вносим общие переменные – region будет использоваться ролями и cloudformation, и eksctl, а vpc_cidr_block – только в cloudformation.

CloudFormation роль

После окончания написания шаблонов из предыдущего поста у нас получилась такая структура каталогов и файлов:

В корне репозитория создаём файл eks-cluster.yml – это будет наш основной Ansible-плейбук.

В нём добавляем вызов роли cloudformation:

- hosts:
  - all
  become:
    true
  roles:
    - role: cloudformation
      tags: infra

Сразу добавляем tags, что бы иметь возможность запускать роли независимо – пригодится, когда будем писать вторую роль, для eksctl.

Создаём файл roles/cloudformation/tasks/main.yml – добавляем вызов модуля cloudformation, задаём необходимые переменные для доступа и через template_parameters модуля передаём ему значение для параметра VPCCIDRBlock из переменной vpc_cidr_block:

- name: "Create EKS {{ cf_stack_name | upper }} CloudFormation stack"
  cloudformation:
    region: "{{ region }}"
    stack_name: "{{ cf_stack_name }}"
    state: "present"
    disable_rollback: true
    template: "/tmp/packed-eks-stacks.json"
    template_parameters:
      VPCCIDRBlock: "{{ vpc_cidr_block }}"
      EKSClusterName: {{ eks_cluster_name }},
    tags:
      Stack: "{{ cf_stack_name }}"
      Env: "{{ env }}"
      EKS-cluster: "{{ eks_cluster_name }}"

С полгода не трогал Ansible — всё забыл, на самом деле(

Погуглим “ansible inventory” – почитаем Best Practices

В корне репозитория создаём ansible.cfg с различными своими дефолтными настройками:

[defaults]
gather_facts = no
inventory = hosts.yml

Там же создаём inventory-файл — hosts.yml:

all:
  hosts:
    "localhost"

Используем только localhost, т.к. по сути Ansible никуда по SSH ходить и не будет — все задачи выполняются локально.

Проверяем синтаксис:

Вроде ОК? Генерируем файл шаблона (в Jenkins нужен будет отдельный pipeline stage для этого):

И запускаем создание стека:

Проверяем:

Имя стека eksctl-bttrm-eks-dev-stack – всё хорошо.

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

Ansible eksctl

Файл шаблона у нас уже есть – переименуем его в .j2:

Из CloudFormation стека, который создаётся в первой роли, нам надо в этот шаблон передать пачку значений – VPC ID, ID подсетей и т.д, что бы потом сгенерировать файл настроек для eksctl.

Используем Ansible модуль cloudformation_info, что бы получить информацию о только что созданном стеке.

Добавим, сохраним всё в переменную stack_info, и потом глянем её содержимое.

Создаём файл roles/eksctl/tasks/main.yml:

- cloudformation_info:
    region: "{{ region }}"
    stack_name: "cf_stack_name"
  register: stack_info

- debug:
    msg: "{{ stack_info }}"

Добавляем вызов роли eksctl в плейбук eks-cluster.yml, добавляем tags, что бы иметь возможность запускать роли независимо:

- hosts:
  - all
  become:
    true
  roles:
    - role: cloudformation
      tags: infra
    - role: eksctl
      tags: eks

Запускаем, передавая --tags eks, что бы вызвать только роль eksctl:

Отлично.

Теперь — вырежем из всего этого только блок { "outputs" }.

Обновляем таску – из stack_info в msg выведем только stack_outputs:

- cloudformation_info:
    region: "{{ region }}"
    stack_name: "{{ cf_stack_name }}"
  register: stack_info

- debug:
    msg: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs }}"

Запускаем:

Атлична.

А теперь попробуем сделать их переменными, и использовать шаблонизатор Ansible, что бы сгенерировать файл настроек eksctl.

Обновляем roles/eksctl/tasks/main.yml, создаём переменную vpc_id, и выведем её через debug, что бы проверить значение:

- cloudformation_info:
    region: "{{ region }}"
    stack_name: "{{ cf_stack_name }}"
  register: stack_info

- debug:
    msg: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs }}"

- set_fact:
    vpc_id: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.VPCID }}"

- debug:
    msg: "{{ vpc_id }}"

- name: "Check template's content"
  debug:
    msg: "{{ lookup('template', './eks-cluster-config.yml.j2') }}"

В «Check the template content» — с помощью прямого вызова модуля template проверим, что у нас будет получаться из файла шаблона.

Редактируем получившийся roles/eksctl/templates/eks-cluster-config.yml.j2 — вписываем {{ vpc_id }}, остальное пока не трогаем:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: eks-dev
  region: eu-west-2
  version: "1.15"
nodeGroups:
  - name: worker-nodes
    instanceType: t3.medium
    desiredCapacity: 2
    privateNetworking: true
vpc:
  id: "{{ vpc_id }}"
  subnets:
    public:
      eu-west-2a:
...

Проверяем:

vpc:\n id: \”vpc-vpc-042082cd2d011f44d\” – отлично, наша VPC в шаблоне появилась.

Добавляем остальные переменные вместо харкода, приводим шаблон к такому виду:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: "{{ eks_cluster_name }}"
  region: "{{ region }}"
  version: "{{ k8s_version }}"
nodeGroups:
  - name: "{{ k8s_worker_nodes_group_name }}"
    instanceType: "{{ k8s_worker_nodes_instance_type }}"
    desiredCapacity: {{ k8s_worker_nodes_capacity }}
    privateNetworking: true
vpc:
  id: "{{ vpc_id }}"
  subnets:
    public:
      {{ a_stack_az }}:
        id: "{{ a_stack_pub_subnet }}"
      {{ b_stack_az }}:
        id: "{{ b_stack_pub_subnet }}"
    private:
      {{ a_stack_az }}:
        id: "{{ a_stack_priv_subnet }}"
      {{ b_stack_az }}:
        id: "{{ b_stack_priv_subnet }}"
  nat:
    gateway: Disable
cloudWatch:
  clusterLogging:
    enableTypes: ["*"]

Теперь надо добавить в Ansbile пачку переменных, которые мы используем в этом шаблоне:

• eks_cluster_name – уже добавили
• vpc_id – уже добавили
• для стека в AvailablityZone-А добавить:
  • a_stack_pub_subnet
  • a_stack_priv_subnet
• для стека в AvailablityZone-В добавить:
  • a_stack_pub_subnet
  • a_stack_priv_subnet
• region — уже есть, будет переопределяться из параметров Jenkins
• kubernetes_version
• kubernetes_worker_nodes_group_name
• kubernetes_worker_nodes_instance_type
• kubernetes_worker_nodes_capacity

Добавляем set_facts в файл roles/eksctl/tasks/main.yml, приводим его к виду:

- cloudformation_info:
    region: "{{ region }}"
    stack_name: "{{ cf_stack_name }}"
  register: stack_info

- debug:
    msg: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs }}"

- set_fact:
    vpc_id: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.VPCID }}"
    a_stack_az: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.AStackAZ }}"
    a_stack_pub_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.APublicSubnetID }}"
    a_stack_priv_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.APrivateSubnetID }}"
    b_stack_az: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BStackAZ }}"
    b_stack_pub_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BPublicSubnetID }}"
    b_stack_priv_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BPrivateSubnetID }}"

- name: "Check the template's content"
  debug:
    msg: "{{ lookup('template', './eks-cluster-config.yml.j2') }}"

В файл group_vars/all.yml добавляем переменные для роли eksctl:

...
##################
# ROLES specific #
##################

# cloudforation role
vpc_cidr_block: "10.0.0.0/16"

# eksctl role
k8s_version: 1.15
k8s_worker_nodes_group_name: "worker-nodes"
k8s_worker_nodes_instance_type: "t3.medium"
k8s_worker_nodes_capacity: 2

Попробуем?

Пока просто тем же образом — через печать содержимого шаблона:

Работает.

Пришло время запускать сам eksctl.

Создание eks-cluster-config.yml

Перед тем, как вызывать eksctl — надо сгенерировать файл конфига кластера из шаблона.

В конце roles/eksctl/tasks/main.yml добавляем вызов template, и используя шаблон role/eksctl/templates/eks-cluster-config.yml.j2 генерируем файл eks-cluster-config.yml в /tmp:

...
- name: "Generate eks-cluster-config.yml"
  template:
    src: "eks-cluster-config.yml.j2"
    dest: /tmp/eks-cluster-config.yml

eksctl create vs update

Кстати, вопрос — а если кластер уже есть? Джоба сфейлится, т.к. мы тут явно передаём create.

Можно добавить проверку существует ли уже кластер, а затем создать переменную, которая будет хранить значение create или update, по аналогии с bash-скриптом из поста BASH: скрипт создания AWS CloudFormation стека.

Значит, надо:

1. получить список уже имеющихся кластеров EKS в регионе
2. найти имя создаваемого кластера в списке существующих кластеров
3. если не найдено — то задаём create
4. если найдено — задаём update

Пробуем так:

# populate a clusters_exist list with names of clusters devided by TAB "\t"
- name: "Getting existing clusters list"
  shell: "aws --region {{ region }} eks list-clusters --query '[clusters'] --output text"
  register: clusters_exist

- debug:
    msg: "{{ clusters_exist.stdout }}"

# create a list from the clusters_exist
- set_fact:
    found_clusters_list: "{{ clusters_exist.stdout.split('\t') }}"

- debug:
    msg: "{{ found_clusters_list }}"

# check if a cluster's name is found in the existing clusters  list
- fail:
    msg: "{{ eks_cluster_name }} already exist in the {{ region }}"
  when: eks_cluster_name not in found_clusters_list

- meta: end_play
...

Эти таски на время проверки добавляем в начало файла roles/eksctl/tasks/main.yml, а что бы не дёргать следующие задачи — на время тестирования завершаем выполнение задач с помощью - meta: end_play.

В условии fail сейчас для проверки и наглядности сделаем “not in“, т.к. нашего кластера ещё нет (мы ведь переопределили переменные – и у нас теперь новый стек, и будет новый кластер):

Отлично.

Теперь добавим создание переменной eksctl_action со значением «create» или «update«, в зависимости от того — найдено ли имя кластера в уже существующих кластерах региона.

# populate a clusters_exist list with names of clusters devided by TAB "\t"
- name: "Getting existing clusters list"
  shell: "aws --region {{ region }} eks list-clusters --query '[clusters'] --output text"
  register: clusters_exist

- debug:
    msg: "{{ clusters_exist.stdout }}"

# create a list from the clusters_exist
- set_fact:
    found_clusters_list: "{{ clusters_exist.stdout.split('\t') }}"

- debug:
    msg: "{{ found_clusters_list }}"

- set_fact:
    eksctl_action: "{{ 'create' if (eks_cluster_name not in found_clusters_list) else 'update' }}"
   
- debug:
    var: eksctl_action

# check if a cluster's name is found in the existing clusters  list
- fail:
    msg: "{{ eks_cluster_name }} already exist in the {{ region }}"
  when: eks_cluster_name not in found_clusters_list

...

Проверяем:

А теперь — надо прикрутить это к задаче с вызовом eksctl — добавляем туда {{ eksctl_action }}.

Приводим файл к виду:

- cloudformation_info:
    region: "{{ region }}"
    stack_name: "{{ cf_stack_name }}"
  register: stack_info

- set_fact:
    vpc_id: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.VPCID }}"
    a_stack_az: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.AStackAZ }}"
    a_stack_pub_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.APublicSubnetID }}"
    a_stack_priv_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.APrivateSubnetID }}"
    b_stack_az: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BStackAZ }}"
    b_stack_pub_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BPublicSubnetID }}"
    b_stack_priv_subnet: "{{ stack_info.cloudformation[cf_stack_name].stack_outputs.BPrivateSubnetID }}"
 
- name: "Generate eks-cluster-config.yml"
  template:
    src: "eks-cluster-config.yml.j2"
    dest: /tmp/eks-cluster-config.yml

# populate a clusters_exist list with names of clusters devided by TAB "\t"
- name: "Getting existing clusters list"
  command: "aws --region {{ region }} eks list-clusters --query '[clusters'] --output text"
  register: clusters_exist

# create a list from the clusters_exist
- set_fact:
    found_clusters_list: "{{ clusters_exist.stdout.split('\t') }}"

- name: "Setting eksctl action to either Create or Update"
  set_fact:
    eksctl_action: "{{ 'create' if (eks_cluster_name not in found_clusters_list) else 'update' }}"

- name: "Running eksctl eksctl_action {{ eksctl_action | upper }} cluster with name {{ eks_cluster_name | upper }}"
  command: "eksctl {{ eksctl_action }} cluster -f /tmp/eks-cluster-config.yml"

Момент истины 🙂

Запускаем:

Стек и кластер создаются, имя стека – eksctl-bttrm-dev-cluser – как мы хотели:

Ура.

Осталась ещё одна проверка.

TEST: CloudFormation && EKS Custom parameters

Последнее, что надо проверить – это “гибкость” всего, что написали.

Например – QA захотят развернуть свой кластер с именем qa-test и VPC 10.1.0.0/16.

В group_vars/all.yml меняем:

• env: “dev” > “qa-test”
• region: “eu-west-2” > “eu-west-3“
• vpc_cidr_block: “10.0.0.0/16” > “10.1.0.0/16“

...
env: "qa-test"
...
region: "eu-west-3"
...
vpc_cidr_block: "10.1.0.0/16"

Упаковываем шаблон в корзину в этом регионе, что бы перегенерировать шаблон packed-eks-stack.json:

Запускаем Ansible – без --tags, так как нам надо создать и CloudFormation стеки, и EKS кластер:

Ждём, проверяем:

Бимба!

В целом – на этом всё.

Осталось создать Jenkins-джобу – это уже завтра, возможно – будет третьим постом, если будет время писать.

Блин. ConfigMap жеж)

P.S. aws-auth ConfigMap

Как не старайся – что-то всё-равно забудешь.

Последний штрих – добавить подключение юзера eks-root, которого мы создали в самом начале, к создаваемому кластеру.

Делается одной командой и максимум двумя переменными.

В group_vars/all.yml добавим ARN юзера:

...
eks_root_user_name: "eks-root"
eks_root_user_arn: "arn:aws:iam::534***385:user/eks-root"

И в roles/eksctl/tasks/main.yml – его добавление к кластеру:

...
- name: "Update aws-auth ConfigMap with the EKS root user {{ eks_root_user_name | upper }}"
  command: "eksctl create iamidentitymapping --cluster {{ eks_cluster_name }} --arn {{ eks_root_user_arn }} --group system:masters --username {{  eks_root_user_name }}"

Запускаем:

Возвращаемся к серверу RTFM, на котором у нас настроен “голый” доступ только для юзера eks-root, обновляем ~/.kube/config:

Проверяем ноды:

И поды:

Готово.

Ссылки по теме

Kubernetes

• Introduction to Kubernetes Pod Networking
• Kubernetes on AWS: Tutorial and Best Practices for Deployment
• How to Manage Kubernetes With Kubectl
• Building large clusters
• Kubernetes production best practices

Ansible

• Best Practices
• Ansible & CloudFormation for Complex Workflows

AWS

EKS

• kubernetes cluster on AWS EKS
• EKS vs GKE vs AKS — Evaluating Kubernetes in the Cloud
• Modular and Scalable Amazon EKS Architecture
• Build a kubernetes cluster with eksctl
• Amazon EKS Security Group Considerations

CloudFormation

• Managing AWS Infrastructure as Code using Ansible, CloudFormation, and CodeBuild
• Nested CloudFormation Stack: a guide for developers and system administrators
• Walkthrough with Nested CloudFormation Stacks
• How do I pass CommaDelimitedList parameters to nested stacks in AWS CloudFormation?
• How do I use multiple values for individual parameters in an AWS CloudFormation template?
• Two years with CloudFormation: lessons learned
• Shrinking Bloated CloudFormation Templates With Nested Stack
• CloudFormation Best-Practices
• 7 Awesome CloudFormation Hacks
• AWS CloudFormation Best Practices – Certification
• Defining Resource Properties Conditionally Using AWS::NoValue on CloudFormation