Kubernetes. Part II: Setup Cluster With Kubeadm. Plugins

Після ознайомлення з теорією можна перейти і до практичної частини. Цього разу установимо кластер Kubernetes на bare-metal, тобто звичайні віртуальні машини чи залізні сервера, що не входять до існуючих IAAS платформ.

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

Kubernetes. Part I: Overview

Яка ж мета існування всіх сучасних PaaS платформ? Які додатки варто на них запускати? Далеко не всі існуючі рішення є сенс запускати на таких платформах. Перш за все додаток має бути відповідно написаний, а точніше відповідати 12 вимогам (twelve-factor app методологія). Слідування цим вимогам може надати такі переваги вашому додатку:

- Зменшить час на входження нових розробників до проекту. Мається на увазі, що розробник працюватиме лише над окремою частиною/частинами додатку (мікросервісом), без необхідності розуміння одразу всього коду продукту.

- Збільшить переносимість частин коду між різними середовищами виконання.

- Підніме якість та зручність процесів CI/CD. Кожна частина продукту (мікросервіс) може оновлюватись окремо, головне - не пошкодити інтерфейс взаємодії (REST API і т.п.).

- Дозволить зручно горизонтально масштабувати додатки без значних змін архітектури.

Бажано також мінімізувати вагу додатків до хоча б 1ГБ, інакше завантаження та старт великих контейнерів (у випадку використання контейнерів як середовища, як зазвичай і є) може зайняти пристойну кількість часу. Якщо ж засунути в контейнер купу пакетів, компіляторів і т.п. - то це вже буде такий собі мікросервіс.

Я вже робив огляд та базову конфігурацію кластерних систем управління контейнерами, серед яких:

Mesos/Marathon (вже не підтримується)
Bosh/Cloud Foundry (туманне майбутнє)

А цього разу мова піде про Kubernetes (це ім'я часто пишуть як K8s, адже звучить схоже). Kubernetes - це система з відкритим вихідним кодом для автоматизації розгортання, масштабування та управління додатками (мікросервісами) в контейнерах. У якості системи контейнеризації (container runtime) використовує в основному containerd/cri-o, але є і інші, менш популярні. Все завдяки CRI-інтерфейсу, що зробив можливим відв'язку Kubernetes від Docker-у. Його і досі можна використовувати, але не варто. На низькому рівні, не залежно від того, яку імплементацію CRI було обрано, все рівно працює низькорівневий runC.

Redis Cluster

Я вже якось писав про базові можливості Redis і про способи забезпечення вищої доступності. Але цей цикл статей не був би повний без статті про 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 утиліту.

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 запустимо в Докері.

1. BASIC ATLANTIS USAGE

1.1. BASIC TERRAFORM CODE PREPARATION

Створимо тестовий репозиторій в GitHub для розміщення тестового Terraform коду. Не буду довго на цьому зупинятись, адже в даному процесі немає нічого особливого.

Опишемо створення звичайного EC2 інстансу за допомогою мови HCL останньої версії Terraform. На момент написання статті остання версія - це v1.0.1 

Pulumi. Part II: AWS Subnets and Fargate

Минулого разу  ми торкнулись причин появи нового IaС продукту Pulumi та спробували розібратись із базовими принципами його роботи на прикладі створення простого AWS S3 buсket-у. Наразі ж спробуємо описати на Python-інтерфейсі Pulumi власний VPC із підмережами та ECS Fargate кластер, тобто значно ближчий до реального життя випадок. Також побачимо як користуватись S3-бекендом для збереження стейтів (checkpoints в термінології Pulumi), та що робити із відсутністю lock-ів на паралельний запуск того ж коду. У кінці спробуємо поговорити про нинішній стан речей та перспективи Pulumi. Всі описані нижче приклади можна буде знайти у наступному github-проекті https://github.com/ipeacocks/pulumi-aws-example

Отже для подальших дій необхідні:

• обліковий запис 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

Pulumi. Part I: Overview

Загальні практики вказують на те, що зберігати налаштування як код корисно навіть для будь-яких відносно простих систем. Тобто усі параметри, їх зміни та авторів досить легко переглядати і відслідковувати в системі контролю версій, а за необхідності їх можна повертати до попередніх значень, якщо щось пішло не за планом. У разі якщо стан системи описаний як код, дуже легко та швидко підняти аналогічну копію такої системи. Це чудова тенденція і вона прослідковується у всіх популярних продуктах для різних команд: наприклад у Jenkins є Pipelines, для побудови інфраструктур в основному використовується Terraform, а система моніторингу Prometheus взагалі розроблялась без відповідних GUI інтерфейсів і всі налаштування відбуваються через код. Загалом будь-який новий продукт розробляється із розрахунку на те, його налаштування буде зберігатись як код.

Часто кожний продукт пропонує свою специфічну мову (DSL, Domain-specific language) для опису логіки роботи систем. Наприклад, у Puppet є свій DSL для опису стану, котрий хоче набути ресурс, а у Terraform-a свій власний HCL (HashiCorp Domain Language) для опису ресурсів. DSL загалом використовується для декларативного підходу - цікавить саме ресурс, котрий буде побудовано, а не те як він буде побудовано і з якими етапами. В силу своєї специфічності DSL мови мають багато недоліків і якісь відносно складні речі на DSL виглядають просто жахливо. Модулі Terraform, що описують хоча б дещо комплексну систему, аж занадто не елегантні і їх часто соромно переглядати чи показувати комусь: те що в мові загального користування виглядає лаконічно - в Terraform-і це ж саме перетворюється на рядок в 100 символів і більше, який ще до того не можна розірвати! Тому не раджу нікому дивитись в чужі модулі Terraform, це може вплинути на психічний стан. Вже згаданий Puppet також далеко прорвався вперед і страждає від тих самих проблем, коли читабельно виглядають лише нескладні стандартні ресурси.

Я, як активний користувач Terraform, часто приходив до висновку, що Terraform-у складно виконувати всі покладені на нього завдання конфігурації інфраструктури та виливки додатків. Із однієї сторони в нього є купа різних провайдерів і автори його позиціонують як "швейцарський ніж" сучасного інженера, а із іншої сторони в Teraform-і у якості if використовують count. Із Terraform наприклад не можна реалізувати щось на зразок перевірки існування змінної чи запустити декілька раз той самий модуль (count недоступний під час запуску модуля), чи обійти два списки водночас (адже count лише один) і тому подібне.

Знову ж, я не хочу сказати, що Terraform поганий і з ним неможливо жити. Але варто одразу розуміти, що це DSL, і з однієї сторони його код досить простий і декларативний, а з іншої, по причинам описаними вище, із ним варто звикати до постійного copy-paste. Але може не потрібно? Можливо існує щось інше? Так існує, це Pulumi.

Перший публічний реліз Pulumi з'явився в 2018 році, завдяки зусиллям однойменного стартапу, що базується в Сіетлі. За ідею проекту було взято написання системи, що полишить практики використання специфічних DSL мов та буде ближчим для розробників, таким чином скоротивши розрив між ними та devops/operation командами, котрі займаються їх підтримкою. Хоча це досить контроверсійні аргументи, але не будемо наразі на цьому зупинятись. Перейдемо до більш конкретних речей.

WireGuard VPN. Part II: Setup And Usage

Минулого разу ми говорили про ідеї, що підштовхнули до створення мережевого тунелю WireGuard, та алгоритми, що лежать в його основі. Цього ж разу спробуємо налаштувати WireGuard і пересвідчимось, що VPN is fun again.

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