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 я писав неодноразово, про це можна прочитати наприклад тут. Перейти до його використання можна за лічені хвилини.

Istio. Part I: Service Mesh. Intro And Installation

Це вступна перша стаття про Istio і основи його роботи. У ній також торкнемось основ Service Mesh, його призначення та бонусів, що він надає.


1. WHAT IS SERVICE MESH

Отже почнемо із Service Mesh. Однією із причин її появи стало збільшення кількості різноманітних мікросервісів в інфраструктурах великих компаній після ділення монолітних додатків. Як наслідок цього процесу зросла кількість внутрішнього мережевого трафіку, котрий потрібно було якось "приборкувати". 

Разом із тим була необхідність в розмежуванні коду додатків та коду-обв'язки на кшталт балансування трафіку на рівні запитів (request-level load balancing), circuit-breaking (мережевий розрив інтеграції сервісів після досягнень певних показників запитів), дзеркалювання трафіку (mirroring, тобто повторення трафіку на декілька сервісів, наприклад, для тестування), трейсінгу тощо. Попередньо цей функціонал реалізовувався в окремих, іноді закритих, бібліотеках великих компаній (Hysterix в Netflix, Finagle в компанії Twitter тощо). У сучасному світі розгорнути додатковий проксі значно простіше ніж інтегрувати додаткову бібліотеку в кожне програмне рішення. До того ж вони можуть бути написані на різних мовах програмування, що ще більше підвищує вартість розробки.

Підсумовуючи все вищесказане, Service Mesh - це додатковий шар програмної інфраструктури для забезпечення більшого контролю внутрішньої взаємодії сервісів на мережевому рівні та їх моніторингу. Сама ідея досить молода, проте швидко набирає обертів та кількість її реалізацій стає дедалі більшою. В основі роботи Service Mesh, як правило, присутній додатковий сервіс-проксі, на котрий кожен додаток відправляє трафік, і власне вже потім проксі перенаправляє увесь трафік за необхідною адресою. Також він може реалізувати деякі вищезгадані патерни програмування, шифрування та моніторингу всього, що відбувається між мікросервісами, телеметрію тощо. Звісно все опціонально, тобто може вмикатись і вимикатись за потреби.

Найбільш популярні реалізації Service Mesh, що не прив'язані до cloud-платформ:

• Consul Connect. Продукт відомої HashiCorp. Розроблювався як рішення для власної платформи Nomad, проте наразі доступний і для Kubernetes. У його основі також Envoy.
• Linkerd. Проект входить до CNCF і фокусується більше на простоті ніж гнучкості.
• Traefik Mesh. Також основна ціль - простота інсталяції і підтримки. На відміну від більшості конкурентів, у якості проксі виступає Traefik
  
• Kuma. Platform-agnostic рішення, що може обслуговувати не лише Kubernetes сервіси, а також звичайні віртуальних машини. Основним мейтейнером Kuma є Kong, виробник популярного шлюзу Kong Gateway з відкритим кодом. Має статус CNCF Sandbox проєкту.
  
• OSM (Open Service Mesh). Імплементація від Microsoft, тож ймовірно це непогане рішення для Azure. Використовує всі ті ж популярні дизайн-принципи що і конкуренти: Data/Control plane, Envoy, а також реалізує SMI (Service Mesh Interface)
  
• Istio. Мабуть найбільш функціональний і як наслідок дещо складніший за інші рішення. Про нього, як я вже обіцяв надалі і піде мова.