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.

Cloud Foundry. Part III: BOSH 2 Lite/Cloud Foundry (Diego)

Декілька тижнів тому я опублікував другу статтю про PAAS-платформу Cloud Foundry, а цього разу мова піде про установку нового Cloud Foundry з Diego runtime. Нагадаю, що Diego має купу вдосконалень в порівнянні з DEA, а саме нова система менеджменту контейнерів Garden, що підтримує деплой Docker-контейнерів, новий алгоритм розміщення задач Diego Auction та інші оптимізації.

Підтримка DEA буде припинена 22 травня 2017 року, останні релізи stemcell вже не працюють з DEA, тому практичне знайомство з Cloud Foundry ліпше починати з цієї статті. Цього разу буде описана установка BOSH2 Lite (так, існує ще і друга версія), Cloud Foundry з Diego runtime.

1. BOSH 2 LITE INSTALLATION (BOSH 2 DIRECTOR)

BOSH Lite - це реліз системи виливки Cloud Foundry для системи VirtualBox. Тож останній має бути встановлений в хост-системі:

$ VBoxManage --version
5.1.22r115126

Для інсталяції BOSH 2 Lite більше не потрібен Vagrant, адже його установочні скрипти вміють працювати з VirtualBox напряму.

BOSH 2 CLI написаний на мові Go і його установка для macOS заключається в завантаженні готового бінарного файлу:

$ cd ~/Downloads
$ wget https://s3.amazonaws.com/bosh-cli-artifacts/bosh-cli-2.0.16-darwin-amd64
$ chmod +x bosh-cli-*
# mv bosh-cli-* /usr/local/bin/bosh2

$ bosh2 -v
version 2.0.16-88aa790-2017-05-02T01:12:20Z

За релізами версій BOSH2 CLI можна слідкувати за наступним посиланням https://bosh.io/docs/cli-v2.html. Там же можна завантажити останню версію BOSH2 CLI для ОС Linux.

Cloud Foundry. Part II: BOSH Lite/Cloud Foundry (DEA)

Зовсім нещодавно я написав першу ввідну статтю про PAAS-платформу Cloud Foundry , а зараз я пропоную локально встановити та на практиці оцінити цю платформу.

Є 2 найпростіші способи спробувати Cloud Foundry на локальній системі: PCF Dev та BOSH Lite. У цій статті буде розглянуто останній варіант, як більш гнучкий, проте і складніший. У якості хост-системи буде використано macOS, але звісно з установкою на інших операційних системах проблем не має бути. У кінцевому рахунку це все рівно буде віртуальна машина VirtualBox з Ubuntu 14.04 всередині. Головне - це мати систему з мінімальною кількістю оперативної пам'яті, що рівна 8ГБ.

1. BOSH LITE INSTALLATION (BOSH DIRECTOR)

Отже, до діла. Перш за все установимо BOSH, систему, котра розгортає вузли Cloud Foundry. У випадку Lite-версії, BOSH розповсюджується у вигляді готового образу віртуальної машини, тому Vagrant та VirtualBox мають бути установлені:

$ vagrant --version
Vagrant 1.9.1

$ VBoxManage --version
5.1.18r114002

Для VirtualBox варто також проінсталювати Oracle VM VirtualBox Extension Pack, адже інакше можливі проблеми з мережею між майбутніми компонентами.

Установимо BOSH CLI клієнт, котрий розповсюджується як ruby gem-пакет:

# gem install bosh_cli --no-ri --no-rdoc

$ bosh --version
BOSH 1.3215.4.0

Cloud Foundry. Part I: Basics

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

Наступний малюнок відображає рівень абстракцій, з якими необхідно буде працювати конкретному розробнику. Всі інші рівні будуть обслуговуватись власним відділом адміністрування (якщо cloud платформа встановлена на власному залізі) або ж третьою стороною, на зразок IAAS-провайдера Amazon Web Services чи Google Cloud Platform.

Одного разу я вже писав про IAAS/PAAS-платформу Mesos/Marathon, про її особливості та переваги, а цього разу я пропоную познайомитись з хмарною платформою Cloud Foundry.

Cloud Foundry - вільне програмне забезпечення, розробкою якого з 2009 року займалась компанія VMware, а наразі - Pivotal. Код Cloud Foundry був відкритий в 2011 році і на сьогодній час курується організацією Cloud Foundry Foundation (Linux Foundation Collaborative Project).

Сloud Foundry можна встановити на одну із IAAS-платформ, що офіційно підтримується: AWS, VMware vSphere, OpenStack та ін. Власні комерційні PAAS-рішення на основі Cloud Foundry пропонують HPE (Stackato), IBM (Bluemix), Huawei (FusionStage), Pivotal та ін. Для потреб розробників можна звісно встановити увесь стек локально, використавши напрацювання Bosh Lite чи PCF Dev.

Mesos. Cluster Management

Apache Mesos - це централізована відмовостійка система управління кластером. Вона розроблена для розподілених комп’ютерних середовищ задля забезпечення ізоляції ресурсів та зручного управління кластерами підлеглих вузлів (mesos slaves). Це новий ефективніший спосіб управління серверною інфраструктурою.

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

Mesos розподіляє ресурси CPU та пам’яті в кластері для задач в схожій манері як ядро Linux виділяє ресурси заліза між локальними процесами. По-суті, у випадку Mesos, це і є мікросервісами.

Уявімо собі, що є необхідність виконати різні типи задач. Для цього можна виділити окремі віртуальні машини (окремий кластер) для кожного типу. Ці віртуальні машини ймовірно не будуть повністю завантаженими і певний час будуть простоювати, тобто не працюватимуть з максимальною ефективністю. Якщо ж всі віртуальні машини для всіх задач об’єднати в єдиний кластер, ми можемо підвищити ефективність використання ресурсів і паралельно з тим підвищити швидкість їх виконання (у разі якщо задачі короткострокові чи віртуальні машини не завантажені повністю увесь час). Наступний малюнок, надіюсь, прояснить сказане:

Але це далеко не все. Кластер Mesos (із фреймворком до нього) здатен перестворювати окремі ресурси, у разі їх падіння, масштабувати ресурси вручну чи автоматично за певних умов і т.п.