Translate

середа, 23 серпня 2017 р.

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 архітектуру і складається із наступних частин:

MASTER


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

- kube-apiserver - як не складно здогадатись із назви, API-сервер Kubernetes. Фронт-енд для web панелі Kube-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-провайдера
  • Volume Controller: контролер, що може створювати, під’єднувати, монтувати дискові томи та взаємодіяти з cloud-провайдером для управління томами.

Команда Kubernetes наразі ставить собі за мету в майбутніх релізах відділити окремо специфічний код підтримки cloud-платформ, котрий вже буде підключатись за необхідності до процесу cloud-controller-manager.

- 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 - записує та зберігає метрики контейнерів в центральній базі та надає інтерфейс для їх перегляду. Як агрегатор даних від контейнерів, використовується Heapster, це власна розробка проекту. Под, з працюючим Heapster, запитує інформацію в Kubelet, що запущений на кожному вузлі Kubernetes, котрий в свою чергу отримує дані від cAdvisor. Heapster у якості бази даних для метрик використовує InfluxDB та веб-панель Grafana для відображення даних, що, так би мовити, йде по-замовчуванню. Heapster також підтримує інші бекенди для логування, такі як Google Cloud Monitoring, Kafka, Elasticsearch. З повним переліком можна ознайомитись за посиланням https://github.com/kubernetes/heapster/blob/master/docs/sink-configuration.md. Варто зауважити, що Heapster здатний логувати метрики одразу в декілька бекендів.
  • cluster-level logging - механізм відповідальний за збереження логів додатків/контейнерів в центральному сховищі. Проте сам Kubernetes не пропонує офіційних рішень для таких сховищ. У межах Kubernetes релізу є 2 інтеграції: Stackdriver Logging для інфраструктури в Google Cloud Platform та Elasticsearch. У обох варіантах fluentd використовується у якості лог-агента.
  • ingress - служба, доступна користувачам ззовні, котра відповідає за переадресацію запитів на сервіси (примітиви Kubernetes) по певним правилам (в залежності від імені хосту і/або URL-ів).


NODE/WORKER (вузол)


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

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

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

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

- docker/rkt - використовується для запуску контейнерів. В майбутньому, завдяки containerd, проект планує зробити вибір runtime опціональним.

- supervisord - процес-монітор, що слідкує за роботою kubelet та docker демонів.

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

Окрім цього під час інсталяції кластеру 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, Deis, Eldarion, у яких все це вже може бути.

Посилання:
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

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

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