Docker Swarm, Kubernetes та Mesos є найбільш популярними фреймворками для оркестрування контейнерів. У своєму виступі Арун Гупта порівнює наступні аспекти роботи Docker, Swarm та Kubernetes:
- Локальний девелопмент.
- Функції розгортання.
- Мультиконтейнерні програми.
- Виявлення служби обслуговування.
- Масштабування сервісу.
- Run-once завдання.
- Інтеграція з Maven.
- «Ковзне» оновлення.
- Створення кластера БД Couchbase.
В результаті ви отримаєте чітке уявлення про те, що може запропонувати кожен інструмент оркестрування, та вивчіть методи ефективного використання цих платформ.
Арун Гупта - головний технолог open-source продуктів Amazon Web Services, який вже понад 10 років розвиває спільноти розробників Sun, Oracle, Red Hat та Couchbase. Має великий досвід роботи у провідних крос-функціональних командах, які займаються розробкою та реалізацією стратегії маркетингових кампаній та програм. Керував групами інженерів Sun, є одним із засновників команди Java EE та творцем американського відділення Devoxx4Kids. Аруна Гупта є автором понад 2 тисяч постів в IT-блогах і виступив з доповідями більш ніж у 40 країнах.
У рядку 55 міститься COUCHBASE_URI, що вказує на обслуговування цієї бази даних, який теж створений за допомогою файлу конфігурації Kubernetes. Якщо подивитися на рядок 2, можна побачити kind: Service – це сервіс, який я створюю під ім'ям couchbase-service, і це ім'я вказано в рядку 4. Нижче наводяться кілька портів.
Ключовими рядками є 6 і 7. У service я кажу: «Гей, ось ці мітки, які я шукаю!», і ці labels не що інше, як імена пар змінних, а рядок 7 вказує на мою програму couchbase-rs-pod. Далі перераховані порти, що дають доступ до цих самих labels.
У рядку 19 я створюю новий тип ReplicaSet, у рядку 31 міститься ім'я образу, а рядки 24-27 вказують на метадані, асоційовані з моїм подом. Це саме те, що шукає service та з чим має бути встановлене з'єднання. Наприкінці файлу розташований певний вид зв'язку рядків 55-56 і 4, який каже: «використовуй цей service!».
Отже, я запускаю свій service за наявності набору реплік, і оскільки кожен набір реплік має свій порт із відповідною міткою, він включається до складу service. З погляду розробника, ви просто звертаєтеся до сервісу, який потім задіє потрібний вам набір реплік.
У результаті я маю під WildFly, який спілкується з бекендом бази даних через Couchbase Service. Я можу використовувати фронтенд з декількома подами WildFly, котрий також через couchbase service зв'язується з бекендом couchbase.
Пізніше ми розглянемо, як service, розташований поза кластером, через свою IP-адресу спілкується з елементами, які розташовані всередині кластера і мають внутрішню IP-адресу.
Отже, stateless-контейнери – це добре, але наскільки гарна ідея використовувати stateful-контейнери? Давайте розглянемо параметри системи для stateful, або постійних контейнерів. У Docker існує 4 різні підходи до розташування сховища даних, на які слід звернути увагу. Перший - це Implicit Per-Container, що означає, що при використанні satateful-контейнерів couchbase, MySQL або MyDB, всі вони запускаються з дефолтним Sandbox. Тобто все, що зберігається у базі даних, зберігається у самому контейнері. Якщо контейнер пропадає, дані пропадають разом із ним.
Другий – це Explicit Per-Container, коли ви створюєте конкретне сховище командою docker volume create та зберігаєте у ньому дані. Третій підхід Per-Host пов'язаний з мапінг сховищ, коли все, що зберігається в контейнері, одночасно дублюється на хості. Якщо контейнер дасть збій, дані залишаться на хості. Останнє – це використання кількох хостів Multi-Host, що доцільно на стадії продакшена різних рішень. Припустимо, ваші контейнери з вашими програмами запущені на хості, але при цьому ви хочете зберігати свої дані десь в інтернеті, причому для цього використовується автоматичний мапінг для розподілених систем.
Кожен із цих методів використовує конкретне розташування сховища. Implicit та Explicit Per-Container зберігають дані на хості за адресою /var/lib/docker/volumes. При використанні методу Per-Host сховище монтується всередині контейнера, а контейнер монтується на хості. Для мультихості можуть використовуватися рішення типу Ceph, ClusterFS, NFS і т.д.
При збої постійного контейнера директорія сховища стає недоступною у перших двох випадках, а двох останніх доступ зберігається. Однак у першому випадку ви можете дістатися сховища через хост Docker, запущений на віртуальній машині. У другому випадку дані також не пропадуть, тому що ви створили Explicit-сховище.
При збої хоста директорія сховища недоступна у перших трьох випадках, у разі зв'язок із сховищем не переривається. Зрештою, функція shared повністю виключена для сховища в першому випадку і можлива в інших. У другому випадку можна поділитися сховищем залежно від того, підтримує ваша база даних розподілені сховища чи ні. У випадку Per-Host розподіл даних можливий лише на даному хості, а для мультихосту воно забезпечується розширенням кластера.
Це слід враховувати під час створення stateful-контейнерів. Ще один корисний інструмент Docker – це плагін Volume, який працює за принципом «батареї присутні, але підлягають заміні». При запуску контейнера Docker він каже: "Гей, запустивши контейнер з базою даних, ти можеш зберігати свої дані в цьому контейнері!" Ця функція за замовчуванням, але її можна змінити. Цей плагін дозволяє використовувати замість контейнерної БД мережевий диск чи щось подібне. Він включає драйвер за замовчуванням для host-based сховищ і дозволяє інтеграцію контейнерів із зовнішніми системами зберігання даних, такими як Amazon EBS, Azure Storage і постійними дисками GCE Persistent.
На наступному слайді показано архітектуру плагіна Docker Volume.
Синім кольором позначений клієнт Docker, пов'язаний із синім Docker-хостом, на якому є Local storage engine, що надає вам контейнери для зберігання даних. Зеленим кольором позначені клієнт Plugin Client та Plugin Daemon, які також приєднані до хоста. Вони надають можливість зберігати дані у мережевих сховищах потрібного вам виду Storage Backend.
Плагін Docker Volume може використовуватися із сховищем Portworx. Модуль PX-Dev власне є контейнером, що запускається, який підключається до Docker-хосту і дозволяє легко зберігати дані на Amazon EBS.
Клієнт Portworx дозволяє відстежувати стан контейнерів з різними сховищами, які приєднані до вашого хоста. Якщо ви відвідаєте мій блог, то зможете прочитати, як найефективніше використовувати Portworx з Docker.
Концепція сховищ Kubernetes схожа на Docker і представлена директоріями, які доступні вашому контейнеру в поді. Вони не залежать від часу життя будь-якого контейнера. Найбільш поширеними доступними типами сховищ є hostPath, nfs, awsElasticBlockStore і gsePersistentDisk. Розглянемо, як працюють ці сховища у Kubernetes. Зазвичай процес їхнього підключення складається з 3 кроків.
Перший полягає в тому, що хтось на стороні мережі, як правило, це адміністратор, надає вам постійне сховище. Для цього є відповідний конфігураційний файл PersistentVolume. Далі розробник програми пише файл конфігурації під назвою PersistentVolumeClaim, або запит на сховище PVC, в якому говориться: «у мене підготовлено розподілене сховище об'ємом 50Гб, але щоб інші люди теж могли використовувати його ємність, я повідомляю в цьому PVC, що зараз мені потрібно всього 10 Гб». Нарешті, третій крок полягає в тому, що ваш запит монтується як сховище, і додаток, в якому є під, або набір реплік, або щось подібне починає ним користуватися. Важливо пам'ятати, що цей процес складається з трьох згаданих етапів і дозволяє масштабування.
Наступний слайд показує постійний контейнер Kubernetes Persistence Container архітектури AWS.
Усередині коричневого прямокутника, який зображує кластер Kubernetes, розташований один майстер-нід і два робочі ноди, позначені жовтим кольором. В одному з worker node знаходиться помаранчевий під сховище, контролер реплік і зелений контейнер Docker Couchbase. Усередині кластера над нодами прямокутником лілового кольору позначений доступний ззовні Service. Ця архітектура рекомендується для збереження даних на пристрої. При необхідності я можу зберігати свої дані в EBS за межами кластера, як показано на наступному слайді. Це типова модель для масштабування, проте при її застосуванні потрібно враховувати фінансовий аспект – зберігати дані десь у мережі може бути дорожче, ніж на хості. При виборі рішень контейнеризації це один із вагомих аргументів.
Так само, як у випадку з Docker, можна використовувати постійні контейнери Kubernetes разом з Portworx.
Це те, що в нинішній термінології Kubernetes 1.6 називається "StatefulSet" - спосіб роботи зі Stateful-додатками, яким обробляються події про зупинення роботи Pod та здійснення Graceful Shutdown. У нашому випадку такими програмами є бази даних. У моєму блозі ви можете прочитати, як створювати StatefulSet у Kubernetes за допомогою Portworx.
Поговоримо про аспект розробки. Як я сказав, Docker має 2 версії - РЄ та ЇЇ, в першому випадку йдеться про стабільну версію Community Edition, яка оновлюється раз на 3 місяці на відміну від версії ЇЇ, що щомісяця оновлюється. Ви можете завантажити Docker для Mac, Linux або Windows. Після встановлення Docker автоматично оновлюватиметься, і почати працювати з ним дуже легко.
У Kubernetes я віддаю перевагу версії Minikube - це хороший спосіб почати роботу з цією платформою шляхом створення кластера на одиночному вузлі. Для створення кластерів із кількох нодів вибір версій ширший: це kops, kube-aws (CoreOS+AWS), kube-up (застаріла). Якщо ви збираєтеся використовувати Kubernetes на основі AWS, рекомендую приєднатися до групи AWS SIG, яка зустрічається в мережі щоп'ятниці і публікує різні цікаві матеріали для роботи з Kubernetes AWS.
Розглянемо, як у цих платформах виконується ковзне оновлення Rolling Update. Якщо є кластер із кількох нодів, то ньому використовується конкретна версія образу, наприклад, WildFly:1. Ковзне оновлення означає, що версія образу послідовно замінюється новою на кожному ноді, один за одним.
Для цього використовується команда docker service update (ім'я сервісу), в якій я вказую нову версію образу WildFly:2 і метод оновлення update-parallelism 2. Цифра 2 означає, що система буде оновлювати по 2 образи програми одночасно, потім настане 10 секунд затримка update delay 10s, після чого будуть оновлені 2 наступні образи ще на 2-х нодах, і т.д. Цей простий механізм ковзного оновлення надається вам як складова Docker.
У Kubernetes ковзне оновлення відбувається таким чином. Контролер реплікації rc створює набір реплік однієї версії, і кожен у цьому webapp-rc забезпечений міткою label, що у etcd. Коли мені потрібен якийсь під, я через Application Service звертаюся до сховища etcd, яке за вказаною міткою надає мені цей під.
У даному випадку у нас в Replication controller є 3 пода, в яких запущено програму WildFly версії 1. При оновленні у фоновому режимі створюється ще один контролер реплікації з тим же ім'ям та індексом в кінці - xxxxx, де х - випадкові числа, і з тими ж мітками labels. Тепер Application Service має в своєму розпорядженні три поди з додатком старої версії і три поди з новою версією в новому Replication controller. Після цього старі поди видаляються, контролер реплікації з новими подами перейменовується і входить у роботу.
Перейдемо до розгляду моніторингу. У Docker є багато вбудованих команд для моніторингу. Наприклад, інтерфейс командного рядка docker container stats дозволяє щомиті виводити в консоль дані про стан контейнерів - використання процесора, диска, завантаження мережі. Інструмент Docker Remote API надає дані про те, як клієнт спілкується із сервером. Він використовує прості команди, але в основі лежить Docker REST API. У разі слова REST, Flash, Remote позначають те саме. Коли ви спілкуєтесь з хостом, це REST API. Docker Remote API дозволяє отримати більше відомостей про запущені контейнери. У моєму блозі викладено деталі використання цього моніторингу з Windows Server.
Моніторинг системних подій docker system events при запуску мультихостового кластера дає можливість отримати дані про падіння хоста або падіння контейнера на конкретному хості, масштабування сервісів тощо. Починаючи з версії Docker 1.20, до нього входить Prometheus, який здійснює вбудовування endpoints в існуючі програми. Це дозволяє отримувати метрики через HTTP та відображати їх на панелях моніторингу.
Ще одна функція моніторингу - це Advisor (скорочення від container Advisor). Він аналізує та надає дані про використання ресурсів та продуктивності із запущених контейнерів, надаючи метрики Prometheus «прямо з коробки». Особливість цього інструменту полягає в тому, що він надає дані лише за останні 60 секунд. Тому вам потрібно передбачити можливість збирати ці дані та поміщати до бази даних, щоб мати можливість моніторингу тривалого за часом процесу. Його також можна використовувати для відображення метрик на панелі моніторингу у графічному вигляді за допомогою Grafana або Kibana. У моєму блозі є докладний опис того, як використовувати cAdvisor для моніторингу контейнерів за допомогою панелі Kibana.
На наступному слайді показано, як виглядає результат роботи Prometheus endpoint та доступні для відображення метрики.
Зліва внизу ви бачите метрики HTTP-запитів, відповідей тощо, праворуч – їхнє графічне відображення.
Kubernetes також містить інтегровані інструменти моніторингу. На цьому слайді показаний типовий кластер, що містить один майстер і три робочі вузли.
У кожному з робочих нодів розташований cAdvisor, що автоматично запускається. Крім цього, тут є Heapster - система моніторингу продуктивності та збору метрик, сумісна з Kubernetes версії 1.0.6 та вище. Heapster дозволяє збирати як показники продуктивності робочих навантажень, модулів і контейнерів, а й події та інші сигнали, генеровані цілим кластером. Для збору даних він спілкується з Kubelet кожного пода, автоматично зберігає інформацію в базі даних InfluxDB та виводить у вигляді метрик на панель моніторингу Grafana. Проте врахуйте – якщо ви використовуєте miniKube, ця функція за промовчанням недоступна, тому для моніторингу доведеться використовувати аддони. Так що все залежить від того, де ви запускаєте контейнери і які інструменти моніторингу можете скористатися за замовчуванням, а які потрібно встановити у вигляді окремих доповнень.
На наступному слайді зображено панелі моніторингу Grafana, які показують робочий стан моїх контейнерів. Тут чимало цікавих даних. Звичайно, існує безліч комерційних інструментів моніторингу процесів Docker та Kubernetes, наприклад, SysDig, DataDog, NewRelic. Деякі з них мають 30-ти безкоштовний пробний період, тому можна спробувати і підібрати собі найбільш підходящий. Особисто я віддаю перевагу використанню SysDig і NewRelic, які відмінно інтегруються в Kubernetes. Існують інструменти, які однаково добре інтегруються в обидві платформи і Docker, і Kubernetes.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com