Translate

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

Kubernetes. Part I: Overview

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

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

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

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

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

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

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

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

А цього разу мова піде про Kubernetes (це ім'я часто пишуть як K8s, адже звучить схоже). Kubernetes - це система з відкритим вихідним кодом для автоматизації розгортання, масштабування та управління додатками (мікросервісами) в контейнерах. У якості системи контейнеризації (container runtime) використовує Docker (і експериментально rkt). У останніх релізах Kubernetes взято курс на підтримку інших систем контейнеризації через CRI (Container Runtime Interface) інтерфейс.

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/RancherOS від Rancher Labs, OpenShift, розробкою якої займається Red Hat, Tectonic від компанії CoreOS та інші.

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

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

CONTROL PLANE (MASTER)


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

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

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

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

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

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

  • Node Controller: контролер, що допомагає визначити специфічними засобами cloud-провайдера, чи Kubernetes вузол, що перестав відповідати, був насправді видалений
  • Route Controller: відповідає за налаштування маршрутів засобами cloud-провайдера (API-запитами та ін.)
  • Service Controller: відповідальний за створення, оновлення та видалення балансувальників навантаження 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 - механізм відповідальний за збереження логів додатків/контейнерів в центральному сховищі. Проте сам Kubernetes не пропонує офіційних рішень для таких сховищ. У межах Kubernetes релізу є 2 інтеграції: Stackdriver Logging для інфраструктури в Google Cloud Platform та Elasticsearch. У обох варіантах fluentd використовується у якості лог-агента.
  • ingress - служба, що відповідає за переадресацію запитів на сервіси (примітиви Kubernetes) по певним правилам (в залежності від імені хосту і/або URL-ів). Її також можна віднести і до об'єктів, мова про яких піде далі. Ingress-у також присвячена окрема стаття в цьому блозі.


NODE/WORKER (вузол)


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

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

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

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

- docker/CRI-O - використовується для запуску контейнерів.

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

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


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


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

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

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

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

- Деплоймент (Deployment) - одиниця, що описує рівень реплікації (об’єкт ReplicaSet входить до цього поняття) та поди, що мають входити в його склад. Деплоймент дозволяє зручно оновлювати версії вилитого програмного забезпечення чи повертати їх назад у разі проблем з новими релізами чи щось на зразок цього. Власне Деплоймент - це така собі заміна Replication Controller-а, проте з 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://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

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

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