Karpenter. Just-in-time Nodes for EKS Cluster

Karpenter - це аддон EKS, котрий забезпечує підняття нових вузлів у відповідь на присутність подів, для яких відсутні місця на нинішніх потужностях. Він це робить спостерігаючи за подіями в кластері і за потреби відправляє запити до API хмарного провайдера, на котрому працює.

Karpenter виконує схожу роботу із Cluster Autoscaler проте реагує значно швидше на потреби скейлінгу, не має обмежень по типам інстансів в межах одного пулу, працює і логікою вартості вузлів тощо. Karpenter не потребує Node та Autoscaling груп і працює напряму із API без традиційних абстракцій AWS необхідних для цього. Окрім цього він може виконувати безпекові функції: забезпечує автоматичне перестворення нод після проходження певного часу чи після виходу нової AMI.

Уперше Karpenter було представлено в 2021 році у якості продукту із відкритим кодом. У 2024 році була вже представлена версія 1.0, котра була оголошена Амазоном як готова до використання в prod-середовищах на AWS. Karpenter було cпроектовано для використання на різних хмарних середовищах, тому є сторонні імплементації Karpenter для Azure, Alibaba Cloud і можливо інші. На практиці ж він перш за все розвивається для AWS, інші його версії можуть бути не достатньо стабільними, а офіційна докуменація для розробників відсутня.

Ця стаття буде умовно поділена на 3 частини. Перша буде про установку Karpenter на вже діючий EKS кластер, для чого вже традиційно скористаємось Тераформом. А в другій та третій поговоримо про його роботу та особливості.

Джерело: https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/

Перед інсталяцією Karpenter варто звернути увагу на функціонал EKS Auto Mode, що з'явився відносно нещодавно. Він перекладає відповідальність на установку та підтримку базових AWS-аддонів, серед яких AWS LB Contoller, Karpenter, EBS CSI та інші на хмарний сервіс Amazon. Не бачу причин не спробувати спершу саме його.

Kubernetes. Part IX: EKS Addons/Controllers

Минулого разу ми підняли Kubernetes кластер в AWS із LB контролером, а сьогодні поговоримо про те, як зробити досвід роботи із EKS ще більш повноцінним. Виконаємо установку контролерів/аддонів, що надають додаткові зручності та спрощують обслуговування кластеру. Як і минулого разу, код буде доступний у моєму репозиторію і описаний на останньому, на момент написання статті, Тераформі версії 1.9. Окрім того потрібно мати працюючий EKS кластер, хоч самі контролери (окрім спеціальних) в більшості випадків працюватимуть і на інших реалізаціях Kubernetes в cloud чи навіть bare-metal. Для простоти розуміння надалі будемо вважати, що кластер перебуває у стані, що описаний в попередній статті, тобто присутні працюючі awscli, EKS, AWS LB Controller.

Ця стаття не про те як потрібно організовувати код Terraform і якими правильними враперами його потрібно обкласти, а лише представлений якомога простіший опис інсталяції всіх необхідних ресурсів.  

1. EXTERNAL DNS

Контролер, що слідкує за K8s сервісами та інгресами, та у разі необхідності створює записи на стороні DNS-провайдера. У нашому випадку це буде AWS Route53, проте ExternalDNS також підтримує роботу із багатьма іншими рішеннями як cloud-hosted (AzureDNS, CloudFlare чи DigitalOcean), так і з деякими self-hosted (CoreDNS, PowerDNS, Bind, Windows DNS). Із повним переліком можна ознайомитись за цим посиланням. Перейдемо до опису його установки:

$ cd ../addons/external-dns
$ cat main.tf

Kubernetes. Part VIII: EKS Cluster With Terraform, AWS LB Controller

Цього разу подивимось на установку Elastic Kubernetes Service (EKS), версії Kubernetes, що керується cloud-платформою Amazon. Він з'явився у 2018 році і є кращим способом установки Kubernetes в цьому середовищі. Також поглянемо на AWS Load Balancer Controller, що самостійно імплементує Ingress та Service (type: LoadBalancer) абстракції.

Раніше я вже писав про Kops, 3rd-party спосіб інсталяції Kubernetes, що в деякому сенсі нагадує k0s. Це чудовий варіант установки, що підтримує не лише AWS, а і інші cloud-платформи, проте із появою EKS він дещо втратив свою актуальність.

У цій статті опишемо створення мережі, EKS-кластеру, що буде працювати у цій мережі, AWS LB контролера та протестуємо його роботу. Описувати все будемо в Terraform, адже для нього вже створені всі необхідні модулі.

1. CREATING VPC/SUBNETS FOR EKS

Створимо необхідне дерево директорій, де і буде описаний проект:

$ git clone git@github.com:ipeacocks/terraform-aws-example.git
$ mv terraform-aws-example/eks-infra infrastructure
$ rm -rf terraform-aws-example

Створимо virtualenv для Python в який встановимо aws-cli:

$ cd infrastructure
$ python3 -m venv venv
$ source venv/bin/activate

$ pip install awscli
$ aws --version
aws-cli/1.34.19 Python/3.12.3 Linux/6.8.0-44-generic botocore/1.35.19

Terraform. Managing AWS Infrastructure

Terraform - це програма для побудови та безпечного обслуговування інфраструктури. Його основний розробник, компанія HashiCorp, представила перший реліз Terraform в 2012 році і наразі будь-хто може приєднатись до його розробки.

Ресурси в Terraform описуються як код на власній декларативній мові HCL (Hashicorp Common Language), тому він з легкістю може бути доданий до системи контролю версій на зразок Git (Infrastructure as Code). Ця особливість забезпечує зручне відслідковування змін коду, його рецензування, можливість налаштування якісного CI/CD та інше.

Terraform складається із двох основних частин: Core та Plugins. Terraform Core відповідальний за побудову графів залежності ресурсів, плану їх створення чи зміни та, за допомогою протоколу RPC, комунікує із плагінами. У свою чергу Terraform Plugins - це різноманітні реалізації API специфічних сервісів, на кшталт SDN (AWS, Azure, Google Cloud, OpenStack і інші), PaaS-платформ (Heroku), SaaS сервісів (наприклад, DNSimple, CloudFlare, Gitlab), self-hosted програмного забезпечення (Docker, MySQL, RabbitMQ) і неймовірної кількість іншого софту.

Далі буде розглянуто роботу Terraform з cloud-провайдером Amazon Web Services. Забігаючи наперед скажу, що Terraform не cloud-agnostic, тобто для побудови схожої інфраструктури, наприклад, у Google Cloud необхідно буде переписувати всі темплейти.

1. PREREQUIREMENTS

Terraform і його плагіни написані на мові Go зі статичним лінкуванням бібліотек і розповсюджується як готовий бінарний файли для всіх популярних і не дуже ОС. У якості клієнта я буду використовувати Ubuntu та архітектуру amd64, тож завантажу відповідний архів:

$ wget https://releases.hashicorp.com/terraform/1.5.0/terraform_1.5.0_linux_amd64.zip
$ unzip terraform_1.5.0_linux_amd64.zip
$ chmod +x terraform
$ sudo mv terraform /usr/local/bin/

$ terraform -v
Terraform v1.5.0

on linux_amd64

Надалі нам також знадобиться aws-cli, хоч він не обов'язковий і Terraform не потребує його присутності:

$ python3 -m venv venv
$ source venv/bin/activate

$ pip install awscli
$ aws --version
aws-cli/1.27.143 Python/3.11.2 Linux/6.2.0-20-generic botocore/1.29.143 

Kubernetes. Part VII: Setup Cluster With K0s

Kubernetes - це скоріше фреймворк для побудови кластеру, тому способів його розгортання є дуже багато, хоч вони і різні за актуальністю. Останнім часом з'явилось багато managed-рішень від cloud-платформ і менших хостерів на зразок DigitalOcean чи Scaleway. Установка ж на bare-metal інсталяції часто буває складнішою, адже потрібно наперед продумати деякі додаткові аспекти.

Раніше я вже описував створення кластеру Kubernetes за допомогою Kubespray і, виходячи із комітів до його репозиторію, він і досі лишається актуальним. Але цього разу я хочу приділити час іншому проекту по розгортанню K8s - k0s.

k0s - опенсорс проект, головним розробником якого є компанія Mirantis. Код проекту написаний на мові Go і для опису кластеру k0s використовує YAML конфігураційний файл. Має наступні ключові особливості:

• різні методи інсталяцій:  single-node, multi-node (в тому числі HA майстрів), airgap (установка в середовище із обмеженим інтернет доступом) та Docker (щось на зразок kind)
• уміє керувати повним життєвим циклом кластеру за допомогою k0sctl: оновлення, бекап чи відновлення
• у якості CNI із коробки підтримує Kube-Router (за замовчуванням) та Calico. Інші екстеншени також підтримуються, але це вже ручна робота, яка надалі ймовірно дасть про себе знати
• CRI лише containerd. Історія із custom варіантами аналогічна custom CNI
  
• OpenEBS представлений у якості CSI (Container Storage Interface)
  
• інші, менш помітні особливості: скромніші системні вимоги, ванільний K8s тощо

На відміну від KubeSpray знання Ansible не потрібні, хоч налаштування, як не дивно, також відбуваються по ssh. Цього разу будемо будувати Kubernetes кластер високої доступності, тобто із 3-ма майстрами, а надалі додамо ще один воркер. Три майстри необхідні для того, щоб запобігти Split-brain процесу, точніше ця вимога необхідна лише для бази etcd, котра працює на майстрах.

Prometheus. Setup And Monitoring In Kubernetes

Цього разу я не буду починати статтю із історії появи та особливості Prometheus, адже раніше вже опублікував подібну. У ній ми також зупинились на складових частинах моніторингової системи та її конфігурації для звичайних вузлів. Цього разу поговоримо про місце, яке займає Prometheus в моніторингу Kubernetes, його додатків та підсистем.


WHAT IS PROMETHEUS OPERATOR

Prometheus реалізований як оператор Kubernetes. Цю концепцію вперше запропонувала компанія CoreOS, яка була поглинута RedHat-ом. Оператор - це додаткова абстракція, що допомагає менеджити сервіси, які можуть бути дещо "нерідними" для Kubernetes і надає додатковий рівень автоматизації такому програмному продукту. Оператор вводить додаткові типи об'єктів, котрі включають в себе об'єкти більш низького рівня (native resources). Скажімо використавши "kind: Prometeus", оператор (додатковий постійний сервіс) автоматично створить та налаштує StatefulSet, а в його поди буде змонтовано необхідний Secret, що містить конфігураційний файл для старту Прометеуса. Цей контролер також буде слідкувати за подальшою ситуацією щодо ресурсів, створених ним же, і буде їх змінювати за необхідності: скейлити, даунскейлити, видаляти і т.п.

Такі типи об'єктів реалізовуються за допомогою CRD (custom resource definition), що є розширенням до Kubernetes API. Існує велика множина операторів, для деяких продуктів - це офіційний спосіб їх установки і менеджменту, для інших - опціональний чи навіть неофіційний. Ніщо не заважає запакувати оператор в Helm-чарт чи просто виливати його як набір yaml-файлів.

Є декілька варіантів установки Prometheus оператора, і це варто усвідомлювати перед вибором способу інсталяції:

• prometheus-operator. Основний та офіційний репозиторій, де відбувається розробка. Після його установки  всі ресурси (Prometheus, Alertmanager та ін.) необхідно буде створити власноруч, він описує лише створення оператору та CRDs, якими і маніпулює. Prometheus Operator не тягне за собою купи дашбордів для графани чи щось подібне, як наступний проект в списку.
• kube-prometheus. Також офіційний спосіб інсталяції, який вже включає приклад конфігурації для повного моніторингу Kubernetes кластеру, створює Prometheus та Alertmanager в HA режимі і навіть активізує нотифікації у разі критичних проблем. Так би мовити мінімальний набір Kubernetes-користувача.
• kube-prometheus-stack helm chart надає схожі з kube-prometheus  можливості, проте не є офіційним рішенням від проекту.

Із питаннями по першим двом можна звертатись в офіційний Kubernetes slack-канал. Community helm чарт може мати інакшу конфігугацію, інші Grafana-дашборди та навіть інші лейбли для додавання сервісів до моніторингу. Однак всередині все ті ж CRDs та оператор.

У статті буде розглянуто лише два перші способи установки. Основна ціль статті - показати як працювати із примітивами оператора, а не просто встановити Prometheus.

Istio. Part II: Concepts And Traffic Management

Минулого разу ми познайомились із Service Mesh, поговорили про історичні передумови його появи та встановили Istio. Про особливості його використання згадали лише мимохіть, тож в цій частині спробуємо це виправити.

Для того щоб рухатись далі необхідні робочі Kubernetes та Istio. Версії, котрими я користуюсь, можна знайти в попередніх статтях. Для зручності також можна встановити MetalLB, що реалізує програмний LoadBalancer, хоч він і не обов'язковий в цьому випадку.

Основні додаткові абстракції, котрі привносить Istio в Kubernetes, реалізовані через CRD-розширення:

• Gateway. Направляє трафік на відповідний VirtualService в залежності від доменного імені. У деякому приближенні про Gateway можна думати як про балансувальник, котрий стоїть перед всіма ресурсами. Разом із VirtualService виступає як більш гнучка заміна Kubernetes Ingress.
• VirtualService. Абстракція Istio, котра описує, як запити мають потрапляти до кінцевого K8s сервісу. На відміну від Gateway працює із внутрішнім трафіком.
• DestinationRule. Описує підмножини можливих сервісів та їх мапінги. Їх використовує VirtualService для розрізнення на яку саме версію сервісу має піти трафік. Окрім цього тут також описуються опції Сircuit Вreaker логіки.
• ServiceEntry. Абстракція, що відповідає за додавання записів до внутрішнього реєстру сервісів Istio (service registry). Після чого Envoy може відправляти трафік на таку адресу, як ніби вона всередині mesh-мережі.
  

Одразу складно зрозуміти їх призначення, проте далі має бути зрозуміліше.


1. KUBERNETES ISTIO INGRESS

Default профіль Istio вже має встановлений Ingress-контролер, тож необхідності встановлювати іншу реалізацію немає. Що таке Ingress я писав неодноразово, про це можна прочитати наприклад тут. Перейти до його використання можна за лічені хвилини.