Amazon випустив нову функцію для EKS під назвою EKS Auto Mode, і я вирішив попрацювати з цією новинкою. У цій статті я поділюся своїми знаннями і розгляну такі питання:
- Що таке Cluster Autoscaler
- EKS AutoMode??
- Перехід з Cluster Autoscaler до EKS Auto Mode
- Створення кастомних nodepool і nodeclass для EKS AutoMode
Що таке ClusterAutoscaler?
Коротко кажучи, cluster autoscaler реалізований для автоматичного налаштування розміру вузлів у кластері (у нашому випадку EKS) вгору або вниз (горизонтальне масштабування) на основі вимог до планування. Цей інструмент можна встановити на ваш кластер за допомогою Helm; приклад установки можна знайти тут (за допомогою Terraform).
EKS AutoMode
EKS AutoMode — це нова функція, яка повністю автоматизує управління обчислювальними потужностями, сховищем і мережею для Kubernetes-кластеру. Вона спрощує операції з кластером, передаючи управління інфраструктурою AWS, одночасно зберігаючи відповідність Kubernetes. Деякі з її основних компонентів є хмарними можливостями AWS, які зазвичай доводиться управляти як додатковими модулями. Це включає вбудовану підтримку призначення IP-адрес для Pod, політики мережі для Pod, локальні DNS-сервіси, GPU-плагіни, перевірки здоров’я, зберігання EBS CSI і Karpenter для управління обчислювальними потужностями.
EKS AutoMode управляє інфраструктурою вашого кластера, автоматично обираючи оптимальні EC2 інстанси для ваших робочих навантажень, динамічно масштабуючи вузли на основі вимог застосунків, керуючи життєвим циклом і оновленнями вузлів, обробляючи патчі ОС і оновлення безпеки, інтегруючи основні додатки і сервіси AWS та забезпечуючи тимчасові обчислювальні потужності для підвищеної безпеки. Це зменшує операційні витрати і необхідність ручного управління вузлами.
Перехід з Cluster Autoscaler до EKS AutoMode
Нижче наведені деякі з вимог, необхідних для цього переходу:
- EKS кластер, який працює з Kubernetes версії 1.29 або пізнішої
- Підтримується у всіх AWS регіонах, окрім AWS GovCloud (US) і Китайських регіонів
Я створив кластер за допомогою Terraform, який встановлює необхідні додатки, такі як Cluster Autoscaler, EBS CSI драйвер, ALB контролер балансувальника навантаження, VPC CNI, які доступні як модулі в цьому репозиторії.
Аутентифікаційний режим, на якому працює кластер, був створений за допомогою aws-auth ConfigMap для аутентифікації та авторизації.
EKS AutoMode вимагає використання EKS API та ConfigMap для авторизації, але залежно від нашої конфігурації потрібно додати ще декілька необхідних політик до ролі кластера, як показано на скріншоті нижче.
Останній крок — це додавання sts:TagSession до політики довіри ролі кластера. Це дає AWS Security Token Service (STS) можливість тегувати сесії, що є важливим для деяких операцій EKS.
Оновлена довірча політика виглядатиме наступним чином
Після того як це буде оновлено і збережено, ви можете повернутися до консолі EKS та увімкнути Automode
На скріншоті вище показано, як увімкнути EKS Automode, а також створити його з вбудованими node pools. Останнім кроком я створив роль за замовчуванням, яка вимагає лише дві політики доступу, як показано на скріншоті нижче
Після цього ви можете видалити дефолтну групу вузлів, яку ми створили в конфігурації Terraform. Після її повного видалення разом з вузлами нові вузли будуть створені з їхнім типом обчислень як Automode.
Як показано на скріншоті вище, EKS AutoMode тепер управляє вузлами в нашому кластері, тому ми можемо також видалити cluster autoscaler з нашого кластера, а також інші додатки, такі як EBS CSI драйвер, ALB Load balancer controller, VPC CNI.
З цим ми успішно перейшли від Cluster Autoscaler до EKS Automode. Наступним кроком буде створення кастомних nodepool і nodeclass.
Створення кастомного NodePool і NodeClass для EKS AutoMode
Створення кастомного nodepool і nodeclass тісно пов'язане з тим, як Karpenter створює nodepool і nodeclass, але з деякими змінами в деяких ключах. Нам потрібні кастомні nodepool і nodeclass для управління категорією інстансів, сім’єю інстансів, поколінням інстансів, типом потужності (SPOT/ON-DEMAND), і гіпервізором інстансів (Xen і Nitro). Нижче наведено приклад створення кастомного nodepool і nodeclass. Не забудьте оновити змінну ${CLUSTERNAME}_ значенням вашого кластера.
GitHub gist вище створює кастомний nodepool, використовуючи спотові інстанси, операційну систему на базі Linux, тип інстансів r і гіпервізор на основі Nitro, також ми створюємо nodeclass, і тут потрібно оновити змінну ${CLUSTERNAME}_ значенням вашого імені кластера.
Застосуйте ці зміни до вашого кластера, потім поверніться до консолі EKS, і в управлінні EKS AutoMode зніміть вибір з general-purpose і system під вбудованими node pools, збережіть зміни, і ваша нова конфігурація EKS AutoMode повинна виглядати наступним чином
Після того як ці зміни будуть збережені, керовані nodepool і nodeclass почнуть звільнятися, ставати незапланованими і зрештою видалятися, а кастомні nodepool і nodeclass, які ми створили, повинні створювати нові вузли в нашому кластері, як показано нижче
З цього ми завершили перехід від Cluster Autoscaler до EKS AutoMode. Якщо ви коли-небудь задумувалися, чому ми маємо переходити на EKS AutoMode, ця стаття від nops розкриває все, хоча вони говорять про Karpenter, у AutoMode також обчислювальні потужності управляються за допомогою Karpenter.
Коротке резюме того, що було вивчено:
- Ми обговорили, що таке cluster autoscaler і для чого він потрібен
- Ми розглянули, що таке EKS AutoMode і чому це важливо
- Ми подивилися, як правильно здійснити перехід на EKS AutoMode
- Нарешті, ми створили кастомний nodepool і nodeclass для EKS AutoMode
І з цим, друзі, побачимося в наступній статті😉.
Перекладено з: Migrating your EKS Cluster from Cluster Autoscaler to EKS Auto Mode