Translate

середа, 23 лютого 2022 р.

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 був розроблений інженерами компанії Google і вперше був анонсований в 2014 році. Великий вплив на його архітектуру та розробку мала система Google Borg, багато розробників якої наразі працюють над Kubernetes. У 2015 році було представлено Kubernetes v1.0. Протягом роботи над першою версією продукту, Google в партнерстві з Linux Foundation cформували Cloud Native Computing Foundation (CNCF) і запропонували Kubernetes як одну із перших технологій, щодо якої буде опікуватись щойно створена організація. Наразі до CNCF входить багато програмних продуктів, серед яких в тому числі Fluentd, PrometeusCoreDNS та інші. Всі вони в тій чи іншій мірі інтегруються з Kubernetes.

Kubernetes вже використовується у продуктах третіх компаній, наприклад, Rancher від Rancher Labs, OpenShift, розробкою якої займається Red Hat.

Перша стаття циклу буде про базові концепції Kubernetes, не вдаючись в практичні подробиці. У наступних же ми розглянемо як встановити Kubernetes на власні вузли та запустити додатки.

Отже, кластер Kubernetes наслідує master-slave архітектуру і складається із наступних частин:

CONTROL PLANE (MASTER)


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

- kube-apiserver - як не складно здогадатись із назви, API-сервер Kubernetes. Всі інші сервіси працюють через нього. Фронт-енд для web панелі kubernetes-dashboard, CLI-інтерфейсу kubectl, авторизації, автентифікації, валідації даних, що надсилають інші підсистеми, тощо.

- etcd - сховище параметрів конфігурації у формі ключ-значення. Kube-apiserver записує сюди всю необхідну сервісну інформацію: метрики, конфігурацію компонентів, різні метадані щодо подів, сервісів, деплойментів та ін. Вміє кластеризуватись, підтримує високу доступність (High Availability) і розроблений з прицілом на максимальну узгодженість даних.

- kube-controller-manager - група контролерів в межах одного процесу, що працюють як треди:

  • Node Controller: реагує на підняття та падіння вузлів (нод) Kubernetes.
  • Replication Controller: слідкує за кількістю працюючих подів (pod) кожного контролеру реплікацій в системі
  • Endpoints Controller: відповідальний за точки входу до подів (endpoints)
  • Service Account & Token Controllers: створює облікові записи та токени для нових просторів імен (namespaces)
  • Job, DeamonSet, Deployment, StatefulSet Controllers та інші

 
- cloud-controller-manager - група тредів-контролерів, що працюють як один процес, задля взаємодії з хмарними платформами. Відповідно потреби в цьому процесі немає, якщо Kubernetes працює на cloud-платформах, що ним не підтримуються, чи на звичайних залізних серверах. Цей процес було анонсовано в версії Kubernetes 1.6. Наступні контролери входять до cloud-controller-manager:

  • Node Controller: контролер, що допомагає визначити специфічними засобами cloud-провайдера, чи Kubernetes вузол, що перестав відповідати, був насправді видалений
  • Route Controller: відповідає за налаштування маршрутів засобами cloud-провайдера (API-запитами та ін.)
  • Service Controller: відповідальний за створення, оновлення та видалення балансувальників навантаження, IP-адрес, хелсчеків та ін. cloud-провайдера.
 
- kube-scheduler - відповідальний за розміщення нових подів між вузлами кластера Kubernetes


- addons - додатки, що представлені у вигляді подів та сервісів, що реалізують додаткові функції кластеру. Поди в свою чергу можуть входити до деплойментів, контролерів реплікації і т.п. Працюють в просторі імен (namespace) kube-system. Основні аддони такі:

  • DNS - сервер, що працює в контейнері, обслуговує запити Kubernetes сервісів (в т.ч. мається на увазі service, одиниця Kubernetes). Контейнери, запущені в Kubernetes, автоматично додають адресу цього DNS-серверу до налаштувань.
  • user interface (інтерфейс користувача) - веб-панель, що надає зручний спосіб управління кластером та виливки додатків. Раніше для цього використовувалась kubernetes-ui, проте наразі його розробка згорнута на користь kubernetes-dashboard. Як альтернативу можна спробувати Weave Cloud, котрий вміє працювати не лише з Kubernetes.
  • container resource monitoring - записує та зберігає метрики контейнерів в центральній базі та надає інтерфейс для їх перегляду. Наразі це metrics-server (CPU/Memory метрик для потреб масштабування), Prometheus (для довготривалого зберігання) і т.п.
  • cluster-level logging - механізм відповідальний за збереження логів додатків/контейнерів в центральному сховищі.
  • ingress - служба, що відповідає за переадресацію запитів на сервіси (примітиви Kubernetes) по певним правилам (в залежності від імені хосту і/або URL-ів). Її також можна віднести і до об'єктів, мова про яких піде далі. Ingress-у також присвячена окрема стаття в цьому блозі.


NODE/WORKER (вузол)


Фізичний чи віртуальний сервер, що запускає контейнери (Docker, rkt і т.п.) на своїх потужностях, у яких запущені додатки. Раніше ці вузли називались minion. Наступні компоненти працюють на кожному вузлі:

- kubelet - головний агент вузла, підтримує зв’язок з майстром (kube-apiserver компонентом) і виконує його інструкції:

  • Монтує томи диску для подів.
  • Завантажує секретні дані подів.
  • Запускає контейнери, що входять до подів за допомогою containerd, CRI-O чи іншими, менш популярними, CRI-компонентами.
  • Запускає хелсчеки, що були описані під час створення контейнерів.
  • Рапортує про стан подів та створює їх копії за необхідності.
  • Рапортує про стан роботи вузла в цілому.

- kube-proxy - реалізує service абстракцію Kubernetes, підтримуючи мережеві правила на вузлі і виконуючи переадресацію з’єднань. Переадресація виконується за допомогою iptables.

- containerd/CRI-O - імплементація рантайму для запуску контейнерів. До появи CRI це був лише docker.

- cluster-level logging - один із процесів, що надає логування на рівні кластера, наприклад fluentd.

Окрім цього під час інсталяції кластеру Kubernetes потребує плагін для реалізації оверлейної мережі для зв'язку pod-to-pod чи pod-to-services. Всі доступні варіанти перераховані в офіційній документації Kubernetes.


KUBERNETES CONCEPTS (об'єкти/примітиви)


Окрім основних процесів/демонів хотілось би згадати про основні об’єкти Kubernetes, рівні абстракції, які забезпечують роботу та виливку додатків.

- Контейнер (Container). Представляє собою середовище, що формується технологіями ядра Linux namespaces, cgroups та ізольована від хост-системи. Якраз тут і запускаються додатки (код, бібліотеки для його роботи, конфігурація та ін.).

- Под (Pod, дослівно перекладається як "стручок"). Мінімальна одиниця Kubernetes. Складається з одного і більше контейнерів (група docker контейнерів), що працюють як одне ціле, тобто у своїй підмережі. Може ділити один дисковий том (volume) між різними контейнерами. Контейнери одного поду можуть перебувати лише на одному вузлі.
- ReplicaSet - об’єкт, що покликаний слідкувати за кількістю працюючих подів. У разі падіння одного із них - буде створено новий для підтримки заданого значення подів.

- StatefulSet - множина подів, проте, на відміну від ReplicaSet, має чітко визначені назви/хостнейми, щоб ці поди могли завжди спілкуватись між собою по постійним адресам і мають окремі томи (а не один на всіх як у випадку з ReplicaSet). На момент Kubernetes v1.7 перебуває у статусі бета.

- Деплоймент (Deployment) - одиниця, що описує рівень реплікації (об’єкт ReplicaSet входить до цього поняття) та поди, що мають входити до його складу. Деплоймент дозволяє зручно оновлювати версії вилитого програмного забезпечення чи повертати їх назад у разі проблем з новими релізами.

- Том (Volume) - сховище даних, котре може підключатись до Подів, ReplicaSet-ів чи Деплойментів із вказанням параметрів розміру, доступу (ReadWrite Once, ReadOnly Many, ReadWrite Many), типу сховища (наразі їх існує біля 24: залізні, програмні, хмарні). Їхнє призначення полягає в умінні зберігати дані після перестворення того ж контейнера (том буде перемонтований в ту ж директорію) та наданні доступу до тих же даних декільком контейнерам в поді одночасно.

- Сервіс (Service) - рівень абстракції для подів, що надає їм постійну віртуальну IP-адресу (VIP) та балансування трафіку. Поди вочевидь можуть перестворюватись у разі проблем чи нових релізів і, завдяки сервісам, адреса доступу до них не зміниться. Якраз процес kube-proxy, що працює на нодах Kubernetes, і піклується про це. Він опитує api-server майстра, щоб дізнатись про нові сервіси в кластері. Окрім того завдяки хелсчекам сервіс припиняє подачу трафіка на поди, що не працюють чи змінює правила балансування, якщо були підняті нові поди.
- Мітка та селектор (Label, Selector) - механізм, що дозволяє організовувати об’єкти Kubernetes. Це пара ключ-значення, яка може бути додана до подів, сервісів, деплойментів та ін. Мітки можуть використовуватись як значення для фільтрів для отримання імен об’єктів чи прив’язки певної логіки.

- Простір імен (Namespace) - одиниця, що забезпечує унікальний простір імен для об’єктів. Деяким об’єктам, наприклад, фізичним вузлам, призначити окремий простір імен неможливо. До просторів імен також можна при’язати необхідні обмеження чи квоти. Починаючи з Kuberenetes версії 1.7 у межах неймспейсу з’явилася можливість створювати томи (volume) з паролями, котрі за необхідності можна монтувати до подів і зберігаються в зашифрованому вигляді на etcd.

- Завдання/Регулярне завдання (Job/Cron Job) - завдання, котре потрібно запускати одноразово/по графіку, щось на кшталт різноманітних бекап-процедур і т.п.

Kubernetes, на відміну від Cloud Foundry, не являється PaaS в традиційному розумінні, про що також згадано і в офіційній документації. Він не обмежує запуск додатків, в залежності від мови програмування чи фреймворку на якому вони написані, не має вбудованого магазину додатків, у ньому відсутні багато речей, що часто йдуть по замовчуванню в інших PaaS платформах: вбудованих систем безперервоної інтеграції (CI), компіляції, деплою, служб для обміну повідомленнями, логування, обробки даних, СУБД та ін. Проте Kubernetes часто слугує основою для інших PaaS платформ, на зразок Openshift, у яких все це вже може бути.

Посилання:
https://www.tutorialworks.com/difference-docker-containerd-runc-crio-oci/
https://kubernetes.io/docs/home/
http://kubernetesbyexample.com/
https://kubernetesbootcamp.github.io/kubernetes-bootcamp/index.html
https://habrahabr.ru/company/flant/blog/331188/
https://habrahabr.ru/company/southbridge/blog/334846/
https://blog.alexellis.io/kubernetes-in-10-minutes/
https://www.xenonstack.com/blog/kubernetes-overview-monitoring-security
https://en.wikipedia.org/wiki/Kubernetes
https://platform9.com/blog/kubernetes-vs-mesos-marathon/
https://blog.netsil.com/kubernetes-vs-openshift-vs-tectonic-comparing-enterprise-options-e3a34dc60519
https://blog.netsil.com/kubernetes-vs-openshift-vs-tectonic-comparing-enterprise-options-part-ii-ad6697c54ac2
https://www.digitalocean.com/community/tutorials/architecting-applications-for-kubernetes

Немає коментарів:

Дописати коментар