- Зменшить час на входження нових розробників до проекту. Мається на увазі, що розробник працюватиме лише над окремою частиною/частинами додатку (мікросервісом), без необхідності розуміння одразу всього коду продукту.
- Збільшить переносимість частин коду між різними середовищами виконання.
- Підніме якість та зручність процесів 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, Prometeus, CoreDNS та інші. Всі вони в тій чи іншій мірі інтегруються з 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) між різними контейнерами. Контейнери одного поду можуть перебувати лише на одному вузлі.
- 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 майстра, щоб дізнатись про нові сервіси в кластері. Окрім того завдяки хелсчекам сервіс припиняє подачу трафіка на поди, що не працюють чи змінює правила балансування, якщо були підняті нові поди.
- Завдання/Регулярне завдання (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
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
Немає коментарів:
Дописати коментар