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, котра працює на майстрах.

Kubernetes. Part III: Objects And How To Use Them

Отже у нас вже є готовий налаштований кластер і, озброївшись необхідним теоретичним мінімумом, ми можемо переходити до подальшого вивчення Kubernetes. Цього разу ми поговоримо детальніше про основні примітиви (objects) Kubernetes, як вони взаємодіють між собою та як реалізовані.

Забігаючи наперед, основні команд для отримання даних про роботу об'єктів є наступні:

• kubectl get object_type - перерахунок всіх об'єктів даного типу, котрі знаходяться в межах одного неймспейсу
• kubectl describe object_type - детальна інформація про всі об'єкт даного типу, що також знаходяться в одному неймспейсі

Всі основні об'єкти перераховані нижче. Якщо замість object_type вказати all, то буде виведено все, що знаходиться в неймспейсі.

ПОД (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:

IP:   10.34.0.25

Отже, в межах кластеру под працює за адресою 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 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.

Kubernetes. Part IV: Setup HA Cluster With Kubespray

Kubespray (раніше Kargo) - це набір Ansible ролей для установки та конфігурації системи оркестрації контейнерами Kubernetes. У якості IaaS-у в цьому випадку може виступати AWS, GCE, Azure, OpenStack чи звичайні віртуальні машини. Це проект з відкритим вихідним кодом та відкритою моделлю розробки, тому за бажанням кожен може вплинути на його життєвий цикл.
Нещодавно я писав про інсталяцію Kubernetes за допомогою Kubeadm, але в цьому способі є значні недоліки: він і досі не підтримує мультимайстер конфігурацій та, часом, є не дуже гнучким. Kubespray, хоч і використовує Kubeadm під капотом, вже має функціонал забезпечення високої доступності як для майстра, так і для etcd на етапі інсталяції. Про його порівняння із іншими методами установки Kubernetes можна почитати за наступним посиланням https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md

У цій статті ми створимо 5 серверів на ОС Ubuntu 16.04. У моєму випадку їх перелік наступний:

192.168.20.10  k8s-m1.me
192.168.20.11  k8s-m2.me
192.168.20.12  k8s-m3.me
192.168.20.13  k8s-s1.me
192.168.20.14  k8s-s2.me

Додаємо їх до /etc/hosts всіх вузлів, в тому числі локальної системи, або ж до dns-серверу. Фаерволи та інші обмеження в мережі цих вузлів мають бути деактивовані. Окрім цього, має бути дозволений IPv4 forwarding та кожен із хостів повинен мати вільний доступ до мережі Інтернет задля завантаження docker-образів.

Копіюємо публічний rsa-ключ до кожного серверу зі списку:

$ ssh-copy-id ubuntu@server.me

Вказуємо необхідного користувача та ключ для підключення з локальної машини:

$ vim ~/.ssh/config
...
Host *.me
    User ubuntu
    ServerAliveInterval 60
    IdentityFile ~/.ssh/id_rsa

Де ubuntu - користувач, від імені якого буде відбуватись підключення до сервера, id_rsa - приватний ключ. Більш того, цей користувач потребує можливості виконувати команди sudo без паролю.

Клонуємо репозиторій Kubespray:

$ git clone https://github.com/kubernetes-incubator/kubespray.git

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.

LXC Сontainers. Part II: Network Configuration

У попередній статті я описав, що таке LXC та чому ця технологія може вас зацікавити.

Перед прочитанням тексту нижче, бажано звісно розуміти базові речі про LXC чи просто про контейнеризацію, тому дуже раджу хоча б переглянути статтю, згадану вище.
У цій статті спробуємо розібратись які можливості надає LXC для конфігурації мережевого стеку та і що власне ОС Linux може запропонувати для цього.

Конфігурація з'єднання з мережею описується окремо для кожного контейнера в /var/lib/lxc/<container_name>/config. По замовчуванню, мережевий зв’язок для контейнерів LXC налаштовується за рахунок додаткової приватної мережі 10.0.3.0/24, що NAT-иться на хост машині: всі пакети, що приходять на інтерфейс lxcbr0 (10.0.3.1, gateway) за допомогою маскарадингу динамічно транслюються в публічний айпі і навпаки. Видає IP-адреси dnsmasq, що працює на LXC-хості, а діапазон можливих адрес описаний в /etc/default/lxc-net. На практиці це виглядає так:

# vim /etc/default/lxc-net
...
USE_LXC_BRIDGE="true"

LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
...

Налаштування Iptables на хості, одразу після установки lxc, мають такий вигляд:

# iptables-save
...
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
...
COMMIT

LXC Сontainers. Part I: Overview

LXC (англ. LinuX Containers) — система віртуалізації на рівні операційної системи для запуску декількох ізольованих примірників ОС Linux на одному комп'ютері. LXC не використовує віртуальні машини, а створює віртуальне оточення (контейнер) з власним простором процесів і мережевим стеком. Тобто у разі контейнеризації хост-ситема не емулює хардову частину (відсутній гіпервізор), а просто обмежує процеси та ресурси гостей внутрішніми підсистемами.

У разі LXC, ці підсистеми - це cgroups (додана у версії 2.6.29), namespaces (для ізоляції процесів, мережевого стека і т.д.); для обмеження доступу задіяні такі можливості ядра, як профілі Apparmor і SELinux, політики Seccomp, Chroots (pivot_root) і capabilities. Усі контейнери LXC використовують один примірник ядра ОС.

Ця система схожа на системи OpenVZ (LXC прийняв багато патчів та ідей з цього проекту) і Linux-VServer для ОС Linux, jail для FreeBSD, Solaris Containers для Solaris. Проте на відміну від OpenVZ, LXC не потребує окремого ядра для своєї роботи: необхідні для роботи LXC підсистеми одразу знаходяться в основній вітці ядра.

До складу інструментарію LXC входить бібліотека liblxc, набір утиліт (lxc-create, lxc-start, lxc-stop, lxc-ls і тому подібне), шаблони для побудови контейнерів і набір біндінгів для різних мов програмування.

Docker. Setup and configuration

Останнім часом дуже часто пишуть про Docker та його можливості, дехто навіть приписує йому мало не магічні вміння. Тож у цій статті спробуємо розібратись, що таке Docker і чи потрібно все кидати та мігрувати на нього.

Docker - це один із різновидів контейнерної віртуалізації. Контейнерна віртуалізація не використовує віртуальні машини, як у випадку з повною віртуалізацією, а створює віртуальне середовище з власним простором процесів та мережевим стеком. Всі контейнери хосту використовують один екземпляр ядра хостової системи.

Головними перевагами контейнерної віртуалізації є: зручність у адмініструванні, щільніше розміщення віртуальних контейнерів в хост-системі, дещо краща продуктивність в порівнянні з технологіями повної віртуалізації та економніше використання місця на дисковій системі.

OpenVZ Web Panel

Зовсім нещодавно я писав про OpenVZ віртуалізацію. І не те щоб мені було дуже потрібно, проте я випадково наткнувся на досить симпатичну веб-панель для управління контейнерами і вирішив її спробувати. Тож поділюсь рецептом налаштування OpenVZ Web Panel.

OpenVZ Web Panel - досить непоганий варіант управління OpenVZ-контейнерами, адже з ним відпадає потреба кожен раз логінитись по ssh задля створення нового контейнеру чи зміни параметрів існуючого. У OpenVZ Web Panel також є можливість клонувати чи бекапити діючу віртуальну машину в пару кліків, тобто управління сервером стає справді зручним і швидким.

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

# yum install ruby-devel sqlite sqlite-devel ruby-rdoc

# yum install make gcc

# yum install lsb_release

# gem install sqlite3-ruby

Скачуємо і запускаємо скрипт інсталяції:

# wget -O - http://ovz-web-panel.googlecode.com/svn/installer/ai.sh | sh

Віртуалізація з OpenVZ

Віртуалізація дуже актуальна тема, адже дозволяє більш раціонально використовувати ресурси серверу. Дещо раніше я писав про віртуалізацію на базі KVM, що власне є технологією повної віртуалізації, на відміну від OpenVZ, про яку і піде далі мова.

OpenVZ — це реалізація технології віртуалізації на рівні операційної системи, яка базується на ядрі Linux. OpenVZ дозволяє на одному фізичному сервері запускати безліч ізольованих копій операційної системи, так званих контейнерів (Virtual Environments, VE).

Оскільки OpenVZ базується на ядрі Linux, в ролі «гостьових» систем можуть виступати тільки дистрибутиви GNU/Linux. Проте віртуалізація на рівні операційної системи у OpenVZ дає також і певні переваги, а саме: зручність у адмініструванні, щільніше розміщення віртуальних контейнерів в хост-системі (що зазвичай позитивно відображено на вартості VPS-хостингу), і дещо кращу продуктивність в порівнянні з технологіями повної віртуалізації.

Звісно, що і недоліків достатньо. Головний із них, що на відміну від KVM, модулі OpenVZ не входять у ванільне ядро, тому для фунціонування останнього необхідне окреме ядро і версія його далеко не остання. На момент публікації цієї статті, остальна стабільна версія - 2.6.32-042stab084.14. Із цього по-суті випливає, що хост-системою на OpenVZ може виступати не кожен дистрибутив, а лише з ядром біля 2.6.32 версії. Тому скажімо OpenVZ-ядро під Ubuntu 12.04 LTS навряд заведеться (що я вже спробував), адже ядро тут версії 3.8.0. Але не все так погано, адже для RedHat 6 (CentOS 6, Scientific Linux 6) та Debian 7 "Wheezy" все просто інсталюється і ці дистрибутиви офіційно підтримуюються Parallels.

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

Про певні інші недоліки та переваги можна прочитати тут.

Теорія без практики – мертва, тож самий час описати установку і налаштування хост-системи для OpenVZ. У якості хост-системи я обрав CentOS 6.5 (необхідно лиш попередньо не забути перевірити наявність правил iptables). Додаємо репозиторії для установки ядра OpenVZ та утиліт для роботи із контейнерами:

# wget -P /etc/yum.repos.d/ http://ftp.openvz.org/openvz.repo
# rpm --import http://ftp.openvz.org/RPM-GPG-Key-OpenVZ