Нещодавно я опублікував першу статтю про Argo Rollouts, де зупинився на прогресивних методах доставки та реалізацію BlueGreen із ALB балансувальником та без. Цього ж разу поговоримо про Canary та його імплементацію в Argo Rollouts.
Ця стаття потребує робочого EKS кластеру, AWS LB контролера і самого Argo Rollouts. Про все це можна почитати в попередніх статтях блогу, а останній Terraform-код знаходиться за наступною адресою.
1. CANARY W/O BALANCER
Офіційна документація пропонує різні варіанти, наприклад коли додаток виливається без сервіс-об'єктів взагалі, чого може бути достатньо для якихось воркерів, що працюють зі сторонньою базою та не мають входу через єдиний ендпоїнт/балансувальник. Чи варіант, коли група подів заводиться лише під один об'єкт сервісу, адже першим етапом такої виливки вже є включення відсотку нової версії коду в трафік. Існує також позиція, що першим етапом Canary має бути под/вузол нової версії, котрий ще не буде під трафіком, але його можна буде обкласти додатковими тестами. Власне варіацій багато, єдиного стандарту немає і все залежить від потреб продукту.
У цій секції ми ж розглянемо найпростіший варіант: єдиний об'єкт сервісу, за котрим будуть з'являтись лише деякі поди із новим кодом. Відсоток буде відраховуватись "вагою" нових подів: 1 пода із новим імеджом із 5 - це 20%, 2 поди - 40% тощо. Для більш просунутих варіантів буде потрібна інтеграція із AWS ALB, про яку поговоримо в наступній частині. На реальному прикладі це має бути більш зрозуміліше:
$ cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollout-canary
spec:
replicas: 5
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollout-canary
template:
metadata:
labels:
app: rollout-canary
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:blue
imagePullPolicy: Always
ports:
- containerPort: 8080
strategy:
canary:
steps:
- setWeight: 20
- pause: {}
- setWeight: 40
- pause: {duration: 10}
---
apiVersion: v1
kind: Service
metadata:
name: rollout-canary
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
selector:
app: rollout-canary
EOF
rollout.argoproj.io/rollout-canary created
service/rollout-canary created
Translate
четвер, 9 жовтня 2025 р.
Argo Rollouts. Part II: Canary and PingPong Strategy In Kubernetes
середа, 1 жовтня 2025 р.
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 як техніках, котрі безпосередньо імплементуються на рівні інфраструктури, а не особливостях роботи кодової бази.
середа, 21 травня 2025 р.
Karpenter. Just-in-time Nodes for EKS Cluster
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 кластер, для чого вже традиційно скористаємось Тераформом. А в другій та третій поговоримо про його роботу та особливості.
Перед інсталяцією Karpenter варто звернути увагу на функціонал EKS Auto Mode, що з'явився відносно нещодавно. Він перекладає відповідальність на установку та підтримку базових AWS-аддонів, серед яких AWS LB Contoller, Karpenter, EBS CSI та інші на хмарний сервіс Amazon. Не бачу причин не спробувати спершу саме його.
четвер, 10 жовтня 2024 р.
Kubernetes. Part IX: EKS Addons/Controllers
Ця стаття не про те як потрібно організовувати код 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
четвер, 19 вересня 2024 р.
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
неділя, 18 червня 2023 р.
Terraform. Managing AWS Infrastructure
Ресурси в 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
Надалі нам також знадобиться aws-cli, хоч він не обов'язковий і Terraform не потребує його присутності:
$ 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
неділя, 30 квітня 2023 р.
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, котра працює на майстрах.
вівторок, 21 червня 2022 р.
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.
середа, 27 квітня 2022 р.
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 я писав неодноразово, про це можна прочитати наприклад тут. Перейти до його використання можна за лічені хвилини.
субота, 16 квітня 2022 р.
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. Мабуть найбільш функціональний і як наслідок дещо складніший за інші рішення. Про нього, як я вже обіцяв надалі і піде мова.
середа, 9 березня 2022 р.
Kubernetes. Part V: Configure And Use Ingress. MetalLB
Сервіси Kubernetes надають можливість створення постійних точок входу до контейнерів додатків, що працюють в подах, проте IP адреси сервісів обираються з діапазону оверлейної мережі, і тому є видимими лише в межах кластеру. Тож у разі необхідності доступу до таких додатків ззовні існують наступні варіанти:
• hostNetwork: true. Под, створений із такою опцією, матиме можливість бачити мережеві інтерфейси Kubernetes хосту, де його було запущено.
Порт такого додатку буде прослуховуватись на всіх інтерфейсах вузла. Використання цієї опції не рекомендовано, адже в цьому випадку вичерпується простір портів хост-машини, що зі зростанням кількості працюючих додатків може з легкістю призвести до конфліктів. Більш того, у разі перестворення поду, він може "переселитись" на інший вузол, що додасть складності в його пошуках. Виключенням можуть слугувати поди утиліт, котрим дійсно необхідний вищезгаданий доступ задля управлінням мережею і т.п.
influxdb 1/1 Running 0 38h 10.30.0.141 k8s-s-a
NAME STATUS ROLES AGE VERSION INTERNAL-IP
...
k8s-s-a Ready <none> 4d16h v1.23.4 192.168.1.48
tcp 0 0 127.0.0.1:4222 0.0.0.0:* LISTEN 949214/influxd
tcp6 0 0 :::8086 :::* LISTEN 949214/influxd
• hostPort: integer. Ця опція дозволяє поду активувати лише один порт на всіх інтерфейсах вузла Kubernetes. Yaml для створення такого поду буде виглядати наступним чином:
Його, як і попередній варіант, дуже не рекомендовано використовувати по тим же причинам.
вівторок, 8 березня 2022 р.
Kubernetes. Part III: Objects And How To Use Them
Забігаючи наперед, основні команд для отримання даних про роботу об'єктів є наступні:
- kubectl get object_type - перерахунок всіх об'єктів даного типу, котрі знаходяться в межах одного неймспейсу
- kubectl describe object_type - детальна інформація про всі об'єкт даного типу, що також знаходяться в одному неймспейсі
ПОД (POD). Створимо под, що буде складатись з одного docker-контейнера і буде доступний на порту 9876. Для цього використаємо образ з dockerhub mhausenblas/simpleservice:0.5.0:
$ kubectl run first-pod --image=mhausenblas/simpleservice:0.5.0 --port=9876
deployment "first-pod" created
Перевіримо чи новий под працює:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
first-pod-2257828502-l6z96 1/1 Running 0 23s
$ kubectl describe pod first-pod-2257828502-l6z96 | grep IP:
Отже, в межах кластеру под працює за адресою 10.34.0.25. Із будь-якого вузла кластеру пересвідчимось в цьому, зробивши запит до додатку:
[cluster]$ curl 10.34.0.25:9876/info
{"host": "10.34.0.25:9876", "version": "0.5.0", "from": "10.32.0.1"}
Kubernetes. Part II: Setup Cluster With Kubeadm. Plugins
Способів установки Kubernetes кластеру існує дуже багато. Всі ці перераховані варіанти різної актуальності, необхідно дивитись і перевіряти все уважно, щоб не витратити зайвого часу на марні спроби. Найбільш популярні способи:
- minikube чи kind. Найпростіший спосіб установки Kubernetes на власний локальний PC. Буде корисний людям, котрі хочуть приступити до вивчення Kubernetes, не втрачаючи купу часу на його більш повноцінну установку, чи локального тестування роботи додатків, що потреують цього середовища.
- kubeadm. Офіційний, доволі мануальний спосіб. Підтримує установку на звичайні bare-metal сервера чи віртуальні машини, що працюють під управлінням OS Linux. Наразі kubeadm також підтримує створення HA (High Availability) Master інсталяцій.
- kops. Призначений для розгортання Kubernetes на AWS, для чого використовує API-виклики платформи. Написаний на мові Go. Як зазначено на github сторінці проекту, робота kops з GCE, OpenStack та DigitalOcean перебуває в статусі бета, а в майбутньому також планується підтримка інших хмарних платформ. Також підтримує розгортання HA Master конфігурацій.
- kubespray. Це набір Ansible плейбуків для розгортання Kubernetes на платформах AWS, GCE, Azure, OpenStack, vSphere, bare-metal машинах і т.п. Має найбільш обширний список підтримки дистрибутивів Linux. Також підтримує установку HA Master конфігурацій. Це community-проект, детальніше про нього можна прочитати за посиланням.
- K0s. Установка K8s по ssh але, на відміну від Kubespray, без залучення Ansible. Написаний на мові Go компанією Mirantis. Я йому присвятив окрему статтю в блозі, де і можна ознайомитись із деталями.
- Варіанти, що пропонують провайдери хостингів чи клауди. На зразок AWS Elastic Kubernetes Service (EKS) чи Google Kubernetes Engine (GKE). Мабуть найпростіший варіант, котрий в тому числі найпростіший в обслуговуванні.
- Та багато-багато інших варіантів
У цій статті ми розгорнемо власний кластер Kubernetes за допомогою утиліти kubeadm. Це буде не HA інсталяція (тобто не production-ready варіант) на основі операційної системи Ubuntu 20.04, що в свою чергу працюватиме в системі віртуалізації VirtualBox. Перелік адрес хостів та їх доменів наступний:
k8s-m-a 192.168.1.45
k8s-s-a 192.168.1.48
k8s-s-b 192.168.1.49
Як рекомендує офіційна документація, кожній віртуальній машині варто виділити як мінімум 2ГБ оперативної пам’яті і 2 ядра, інакше може не вистачити місця для запуску додатків.
середа, 23 лютого 2022 р.
Kubernetes. Part I: Overview
- Зменшить час на входження нових розробників до проекту. Мається на увазі, що розробник працюватиме лише над окремою частиною/частинами додатку (мікросервісом), без необхідності розуміння одразу всього коду продукту.
- Збільшить переносимість частин коду між різними середовищами виконання.
- Підніме якість та зручність процесів CI/CD. Кожна частина продукту (мікросервіс) може оновлюватись окремо, головне - не пошкодити інтерфейс взаємодії (REST API і т.п.).
- Дозволить зручно горизонтально масштабувати додатки без значних змін архітектури.
Бажано також мінімізувати вагу додатків до хоча б 1ГБ, інакше завантаження та старт великих контейнерів (у випадку використання контейнерів як середовища, як зазвичай і є) може зайняти пристойну кількість часу. Якщо ж засунути в контейнер купу пакетів, компіляторів і т.п. - то це вже буде такий собі мікросервіс.
Я вже робив огляд та базову конфігурацію кластерних систем управління контейнерами, серед яких:
Mesos/Marathon (вже не підтримується)
Bosh/Cloud Foundry (туманне майбутнє)
А цього разу мова піде про Kubernetes (це ім'я часто пишуть як K8s, адже звучить схоже). Kubernetes - це система з відкритим вихідним кодом для автоматизації розгортання, масштабування та управління додатками (мікросервісами) в контейнерах. У якості системи контейнеризації (container runtime) використовує в основному containerd/cri-o, але є і інші, менш популярні. Все завдяки CRI-інтерфейсу, що зробив можливим відв'язку Kubernetes від Docker-у. Його і досі можна використовувати, але не варто. На низькому рівні, не залежно від того, яку імплементацію CRI було обрано, все рівно працює низькорівневий runC.
неділя, 9 січня 2022 р.
Redis Cluster
1. INTRO
Redis Cluster має наступні переваги/особливості:
- Висока доступність та горизонтальне масштабування до 1000 вузлів. Проте consistent hashing відсутній: при додаванні чи видаленні серверів із кластеру необхідно самому попіклуватись про рівномірний розподіл та переміщеня даних в кластері. Деякі з цих проблем вирішені в Enterprise версії.
- Асинхронна синхронізація зі слейвами. Тобто кластер не гарантує консистентності операцій, тож при певному збігу обставин (наприклад фейловер процес) деякі дані можуть бути втраченими. Але це позитивно впливає на продуктивність.
- Відсутність тразакцій/multiple-keys операцій (MULTI, EXEC, DISCARD, WATCH ), але це можна дещо пом'якшити із простановкою hash tag для ключів. Це пов'язано із самим процесом хешування (алгоритмом розміщення даних в кластері): перший ключ при записі може потрапити на перший сервер, а наступний після нього - на останній. Тож можливо код клієнта треба буде дещо змінити.
- Одна із основних переваг Redis Cluster - це шардинг. Тобто великі об'єми даних можна розділити на групи серверів. У випадку Redis Sentinel він обмежений кількістю оперативної пам'яті сервера. До речі, Enterprise версія вміє використовувати кеш SSD-диску.
- Slave-вузли не простоюють, а забезпечують операції читання для кінцевих клієнтів. Хоч звісно можливі випадки надання не найсвіжіших даних через асинхронну природу реплікації.
- Наявність replica migration. Тобто майстри, що мають декілька реплік, можуть ділитись реплікою із іншим майстром, який її потребує.
Із деталями будемо розбиратись в процесі налаштування. Cluster функціонал з'явився починаючи із версії 3, де його створенням та розподіленням даних в кластері ще займався ruby-скрипт. Наразі все інтегровано в redis-cli утиліту.
пʼятниця, 9 липня 2021 р.
Atlantis. Terraform Pull Request Automation
Цього разу піде мова про Atlantis, програму що автоматизує роботу із Terraform та в деяких випадках може значно спростити взаємодію із ним.
Atlantis - це самодостатній додаток на Golang, що слідкує за відкритими Pull Requests системи контролю версій за допомогою event-ів, що власне остання і надсилає. Під системою контролю версій мається на увазі Github, GitLab, Bitbucket чи Azure DevOps. Тобто це дещо складніше ніж просто Git, адже у неї має бути свій API, web-панель для рецензування та перегляду коду і т.п.
Із Atlantis зі змінами Terraform коду можна взаємодіяти напряму із web-панелі системи контролю версій, слідкувати за останніми змінами, перевіряти чи ці зміни були справді застосовані перед прийняттям коду в main вітку та застосовувати їх. Це справді може бути корисним та зручним, все залежить від процесів всередині команди та наскільки подібна логіка прийнятна.
У статті я розгляну 2 випадки установки та використання Atlantis. Перший, простіший, із застосуванням коду напряму через Terraform, а наступний - через, мабуть, найвідоміший wrapper Terragrunt. У якості системи контролю версій я буду використовувати Github, a сам Atlantis запустимо в Докері.
Створимо тестовий репозиторій в GitHub для розміщення тестового Terraform коду. Не буду довго на цьому зупинятись, адже в даному процесі немає нічого особливого.
Опишемо створення звичайного EC2 інстансу за допомогою мови HCL останньої версії Terraform. На момент написання статті остання версія - це v1.0.1
понеділок, 11 травня 2020 р.
Pulumi. Part II: AWS Subnets and Fargate
Отже для подальших дій необхідні:
- обліковий запис AWS та Programmatic Access до нього
- установлений і налаштований Pulumi
1. CUSTOM VPC/SUBNETS IN FEW AZs
Якою має бути мережа, котру буде не дуже соромно лишати для prod-цілей? Має бути як мінімум декілька публічний підмереж у різних зонах доступності регіону (AZ, availability zone), декілька приватних та стільки ж NAT-шлюзів для з'єднання приватних підмереж із зовнішнім світом. NAT-шлюзи зобов'язані мати постійні IP-адреси (EIP) і лежати в публічних підмережах аналогічних зон доступності. Трафік публічних підмереж має прямувати на Internet-gateway, а приватних - на відповідний NAT-гейтвей своєї ж зони доступності. Спробуємо це реалізувати.
Експортуємо значення Programmatic Access:
$ export AWS_ACCESS_KEY_ID=AKIA1234563J76A
$ export AWS_SECRET_ACCESS_KEY=/xLmpmdp1V3abcdefghklmnopabcdefg2nKRDKO
$ export AWS_REGION=us-east-1
Створимо S3-bucket для стейтів Pulumi:
$ aws s3api create-bucket \
--bucket pulumi-states-zeezpha \
--region us-east-1
$ aws s3api put-bucket-versioning \
--bucket pulumi-states-zeezpha \
--versioning-configuration Status=Enabled
Назва бакету має бути унікальною, тому необхідно обрати якусь власну назву.
Укажемо для Pulumi, що ми збираємось зберігати стейти в створеному вище бакеті S3:
$ pulumi login s3://pulumi-states-zeezpha
четвер, 7 травня 2020 р.
Pulumi. Part I: Overview
неділя, 28 липня 2019 р.
WireGuard VPN. Part II: Setup And Usage
1. SETUP
WireGuard ще не включено до кодової бази ядра Linux і наразі розповсюджується як DKMS-модуль. У якості сервера Wireguard працює лише на Linux, а у якості клієнта - під усіма популярними операційними системами, в т.ч. мобільними, в основному як userspace-імплементація на мові Go.
Для демонстрації можливостей WireGuard ми скористаємось Ubuntu 18.04. Для неї пакети розповсюджуються через ppa-репозиторій. На кожному вузлі, що буде з'єднуватись тунелем, необхідно встановити наступні пакети:
# add-apt-repository ppa:wireguard/wireguard
# apt update
# apt install wireguard
Можливо також потрібно буде встановити пакети-заголовки для ядра:
# apt install linux-headers-$(uname -r) linux-headers-generic
Кожен вузол повинен мати свою пару асиметричних ключів, тож згенеруємо їх на кожному хості:
# cd /etc/wireguard/
# umask 077
# wg genkey | tee privatekey | wg pubkey > publickey
неділя, 2 червня 2019 р.
WireGuard VPN. Part I: Intro
WireGuard розповсюджується як відкрите програмне забезпечення під ліцензією GPLv2. Хоч продукт вже і достатньо зрілий, проте, як говорить основний розробник і автор проекту Джейсон А. Доненфельд, його поки не варто використовувати в production-цілях, адже код ще не пройшов належний рівень аудиту безпеки. В майбутньому його планують повністю включити в ядро, а наразі він розповсюджується як окремий DKMS-модуль. Про WireGuard вже позитивно висловлювались Лінус Торвальдс та Грег Кроа-Хартман, порівнюючи його із витвором мистецтва.





















