Argo Rollouts. Part I: Intro And BlueGreen Strategy In Kubernetes

За замовчуванням Kubernetes управляє стратегією виливки нового коду за допомогою Deployment об'єкта. Він забезпечує доволі простий функціонал, котрий, тим не менш, задовільнить більшість потреб: rolling update чи recreate стратегії виливки; наявність історії, котра може забезпечити безпечний rollback на попередні версії та інші. Deployment забезпечує поступову заміну старіших подів на новіші, перевіривши проходження readiness-проби кожного перед включенням його в трафік, або ж, у випадку recreate стратегії, видаляє старі поди і водночас за раз замінює їх на нові.

Будь-який новий реліз йде із додатковими ризиками, що можуть вплинути на доступність сервісу. І тому простих стратегій, що з коробки надає Kubernetes, буває недостатньо. Скажімо, може бути бажання перемкнути на нову версію (тег імеджа) лише певний відсоток трафіку чи протестувати нову версію прямо перед перемиканням на неї. Тож такі прогресивні стратегії виливки потенційно зменшать ризики та допоможуть заздалегідь знайти критичні недоліки, не вплинувши на значну кількість запитів.

Увесь подальший код доступний за посиланням.

1. PROGRESSIVE DELIVERY

Як вже було сказано, progressive delivery - це набір технік доставки коду, що зменшують ймовірність простою роботи сервісу чи його некоректну роботу. Найпопулярнішими варіантами таких доставок є:

• Blue-Green. Виливається додаткова версія коду, після чого працює одночасно дві: blue (стара) та green (нова). Перемикання production трафіку на новий код зазвичай не миттєве, а лиш в тому разі, коли є впевненість у коректності його роботи, наприклад після прогону додаткових тестів. Дуже часто це робиться на рівні DNS, коли на нову версію прив'язують основне доменне ім'я сервісу. У разі проблем є швидка можливість повернення на попередню версію, адже старий сервіс про всяк випадок не вимикають одразу.
• Canary. На нову версію коду спрямовується лише якийсь відсоток трафіку. У разі відсутності помилок цей відсоток збільшується і доходить до 100. Є різні варіації цієї техніки: наприклад може виливатись якась частина сервісу на новій версії без включення його в трафік, для того щоб додатково прогнати на ній тести. Такий собі варіант Blue-Green іn Canary. Ця техніка також зменшує ризики виливки проблемного коду, адже є ймовірність, що клієнти на новій версії повідомлять, що щось пішло не так допоки цю версію отримають всі користувачі сервісу. Немає якихось чітких часових рамок того як швидко має бути досягнуто завершення виливки нової версії. Для деяких компаній це години, а для інших - дні чи навіть тижні.
• Feature Flags/Toggles. Способи активації додаткового (нового) функціоналу для групи користувачів у межах однієї версії коду, що імплементується додатковими змінними в межах самого коду чи окремих систем із якими він інтегрується. Все заради поступової виливки цих змін.
• A/B Тестування. У межах однієї версії коду клієнтам буде продемонстровано різний функціонал чи різний вигляд елементів сторінки. Якщо у разі такого "експерименту" над користувачами буде підтверджено бажаний результат - ці зміни можуть бути активовані для всієї бази користувачів.

У цій серії статей ми зосередимось на розгортанні коду, а саме на Canary та Blue-Green як техніках, котрі безпосередньо імплементуються на рівні інфраструктури, а не особливостях роботи кодової бази.

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