Kubernetes – це чудовий інструмент для запуску контейнерів Docker у кластеризованому виробничому середовищі. Однак існують завдання, які Kubernetes вирішити не в змозі. При частому розгортанні в робочому середовищі ми потребуємо повністю автоматизованого Blue/Green deployment, щоб уникнути простоїв у цьому процесі, при якому також необхідно обробляти зовнішні HTTP-запити та виконувати вивантаження SSL. Це вимагає інтеграції з балансувальником навантаження, таким як ha-proxy. Іншим завданням є напівавтоматичне масштабування самого кластера Kubernetes під час роботи у хмарному середовищі, наприклад, часткове зменшення масштабу кластера в нічний час.
Хоча Kubernetes не має цих функцій прямо «з коробки», він надає API, яким можна скористатися для вирішення подібних завдань. Інструменти для автоматизованого Blue/Green розгортання та масштабування кластера Kubernetes були розроблені у рамках проекту Cloud RTI, який створювався на основі open-source.
У цій статті, розшифровці відео, розповідається, як налаштувати Kubernetes разом з іншими компонентами з відкритим вихідним кодом для отримання готового до виробництва середовища, яке без простоїв у продакшені сприймає код із комміту змін git commit.
Отже, після того як ви отримали доступ до своїх додатків із зовнішнього світу, можна приступати до повного настроювання автоматизації, тобто довести її до стадії, на якій можна виконати git commit і переконатися, що цей git commit закінчується в продакшені. Природно, що з цих кроків, при здійсненні розгортання, ми хочемо зіштовхуватися з простоями. Отже, будь-яка автоматизація Kubernetes починається з API.
Kubernetes не той інструмент, який можна продуктивно використовувати прямо з коробки. Звичайно, ви можете так робити, використовувати kubectl і так далі, але все ж таки API є найцікавішою і корисною річчю цієї платформи. Використовуючи API як набір функцій, можна отримати доступ практично до всього, що хочете зробити в Kubernetes. Сам собою kubectl також використовує REST API.
Це REST, так що ви можете використовувати для роботи з цим API будь-які мови та інструменти, але ваше життя значно полегшать бібліотеки користувача. Моя команда написала 2 такі бібліотеки: одну для Java/OSGi та одну для Go. Друга використовується не часто, але у будь-якому випадку у вашому розпорядженні є ці корисні речі. Вони є частково ліцензійним open-source проектом. Існує безліч таких бібліотек для різних мов, так що ви можете вибрати найбільш підходящі.
Отже, перш ніж приступити до автоматизації розгортання, необхідно переконатися, що цей процес не буде підданий ніяким простоям. Наприклад, наша команда проводить продакшн-розгортання в середині дня, коли люди максимально використовують програми, тому дуже важливо уникати затримок у цьому процесі. Для того, щоб уникнути простоїв, використовуються два способи: blue/green розгортання або ковзне оновлення rolling update. В останньому випадку, якщо у вас працює 2 реплік програми, вони послідовно оновлюються одна за одною. Цей спосіб добре працює, але він не підходить, якщо в процесі розгортання у вас одночасно запущені різні версії програми. У такому разі ви можете оновити інтерфейс користувача в той час, як бекенд працюватиме зі старою версією, і роботу програми буде припинено. Тому з погляду програмування робота в таких умовах досить скрутна.
Це одна з причин, через яку ми вважаємо за краще використовувати blue/green deployment для автоматизації розгортання своїх додатків. При такому способі ви повинні переконатися, що в певний момент активна лише одна версія програми.
Механізм blue/green deployment виглядає так. Ми отримуємо трафік для своїх додатків через ha-proxy, який направляє його запущеним реплікам програми однієї версії.
Коли нове розгортання здійснюється, ми використовуємо Deployer, якому надаються нові компоненти, і він здійснює деплою нової версії. Деплой нової версії програми означає, що піднімається новий набір реплік, після чого ці репліки нової версії запускаються в окремому, новому поді. Однак ha-proxy нічого про них не знає і поки що не спрямовує їм жодного робочого навантаження.
Тому в першу чергу необхідно перевірити працездатність нових версій health cheking, щоб переконатися в готовності реплік обслуговувати навантаження.
Усі компоненти розгортання повинні підтримувати будь-яку форму health chek. Це може бути дуже проста перевірка HTTP викликом, коли ви отримуєте код зі статусом 200, або глибша перевірка, коли ви перевіряєте зв'язок реплік з базою даних та інші сервісами, стійкість зв'язків динамічного оточення, чи все запускається і працює правильно. Цей процес може бути складним.
Після того, як система переконається у працездатності всіх оновлених реплік, Deployer оновить конфігурацію та передасть правильний confd, який переналаштує ha-proxy.
Тільки після цього трафік буде направлений у під з репліками нової версії, а старий під зникне.
Цей механізм не є особливістю Kubernetes. Концепція Blue/green deployment існує досить тривалий час, і вона використовувала балансувальник навантаження. Спочатку ви направляєте весь трафік до старої версії програми, а після оновлення повністю переведіть його на нову версію. Цей принцип використовується не тільки в Kubernetes.
Зараз я представлю вам новий компонент розгортання – Deployer, який перевіряє працездатність, реконфігурує проксі тощо. Це концепт, який не відноситься до зовнішнього світу та існує всередині Kubernetes. Я покажу, як можна створити власний концепт Deployer за допомогою open-source інструментів.
Отже, перше, що робить Deployer, – це створює контролер реплікації RC, використовуючи API Kubernetes. Цей API створює піди та сервіси для подальшого розгортання, тобто створює новий кластер для наших додатків. Як тільки RC переконається в тому, що репліки стартували, він перевірить їхню працездатність Health check. Для цього у Deployer використовується команда GET/health. Вона запускає відповідні компоненти перевірки та перевіряє всі елементи, що забезпечують роботу кластера.
Після того, як всі поди повідомили про своє здоров'я, Deployer створює новий елемент конфігурації – розподілене сховище etcd, яке використовується всередині Kubernetes, у тому числі для зберігання конфігурації балансувальника навантаження. Ми записуємо дані в etcd і невеликий інструмент confd відстежує etcd на предмет появи нових даних.
Якщо він виявив зміни початкової конфігурації, то генерує новий файл налаштувань і передає його ha-proxy. У цьому випадку ha-proxy перезавантажується без втрати будь-яких з'єднань та адресує навантаження новим services, які забезпечують роботу нової версії наших програм.
Як бачите, не дивлячись на безліч компонентів, тут немає нічого складного. Вам просто потрібно приділити більше уваги API та etcd. Я хочу розповісти вам про open-source деплоєра, яким ми самі користуємося – Amdatu Kubernetes Deployer.
Це інструмент для оркестрування розгортань Kubernetes, що має такі функції:
- розгортання Blue/Green deployment;
- налаштування зовнішнього балансувальника навантаження;
- керування дескрипторами розгортання;
- управління фактичним розгортанням;
- перевірка працездатності Health checks під час розгортання;
- Використання в поди змінних середовища.
Цей Deployer створений на вершині Kubernetes API і є REST API для управління дескрипторами та розгортаннями, а також Websocket API для потокових логів у процесі розгортання.
Він містить дані конфігурації балансувальника навантаження в etcd, тому ви можете не користуватися ha-proxy з підтримкою «прямо з коробки», а легко використовувати свій власний файл конфігурації балансувальника. Amdatu Deployer написаний на Go, як і сам Kubernetes, та ліцензований Apache.
Перед початком застосування цієї версії деплоєра я скористався наступним дескриптором розгортання, де вказані потрібні мені параметри.
Одним з важливих параметрів цього коду є включення прапора "useHealthCheck". Нам слід зазначити, що в процесі розгортання необхідно перевірити працездатність. Цей параметр може бути вимкнений, коли в розгортанні використовуються контейнери сторонніх розробників, які не потрібно перевіряти. У цьому дескрипторі також зазначено кількість реплік та URL фронтенду, який потрібен ha-proxy. Наприкінці зазначений прапор специфікації пода «podspec», який звертається до Kubernetes для отримання інформації щодо налаштування портів, образу і т.д. Це досить простий дескриптор у форматі JSON.
Ще один інструмент, який є частиною open-source проекту Amdatu, це Deploymentctl. Він має інтерфейс користувача UI для конфігурування розгортання, зберігає історію розгортання і містить webhooks для зворотних викликів сторонніми користувачами та розробниками. Ви можете не використовувати UI, оскільки Amdatu Deployer є REST API, але цей інтерфейс може набагато полегшити вам розгортання без залучення будь-якого API. Deploymentctl написано на OSGi/Vertx з використанням Angular 2.
Зараз я продемонструю сказане вище на екрані, використовуючи заздалегідь зроблений запис, так що вам не доведеться чекати. Ми будемо розгортати простий додаток на Go. Не турбуйтеся, якщо до цього не стикалися з Go, це дуже простий додаток, так що вам все має бути зрозуміло.
Тут ми створюємо HTTP-сервер, який відповідає тільки на /health, тому ця програма тільки перевіряє працездатність health check і нічого більше. Якщо перевірка проходить, буде задіяна показана внизу JSON-структура. Вона містить версію програми, яка буде розгорнута деплоєром, message, який ви бачите у верхній частині файлу, та логічний тип даних boolean – працездатна наша програма чи ні.
З останнім рядком я трохи схитрував, тому що помістив у верхній частині файлу фіксоване значення boolean, яке надалі допоможе мені розгорнути навіть «нездорову» програму. Згодом ми з цим розберемося.
Отже, почнемо. Спочатку перевіряємо наявність будь-яких запущених подів за допомогою команди ~kubectl get pods і за відсутності відповіді URL фронтенду переконуємось, що жодних розгортань на даний момент не провадиться.
Далі на екрані ви бачите згаданий мною інтерфейс Deploymentctl, в якому задаються параметри розгортання: простір імен, ім'я програми, версію розгортання, кількість реплік, фронтенд URL, назва контейнера, образ, ліміти ресурсів, номер порту для перевірки health check і т.д. . Ліміти ресурсів дуже важливі, оскільки дозволяють задіяти максимально можливу кількість заліза. Тут можна переглянути журнал розгортання Deployment log.
Якщо зараз повторити команду ~kubectl get pods, видно, що система «завмирає» на 20 секунд, у процесі яких відбувається реконфігурація ha-proxy. Після цього під запуск, і нашу репліку можна побачити в лозі розгортання.
Я вирізав з відео 20 секундне очікування, і зараз ви бачите на екрані, що перша версія програми розгорнута. Все це було зроблено лише за допомогою UI.
Тепер спробуймо другу версію. Для цього я зміню message програми з Hello, Kubernetes! на "Hello, Deployer!", система створює цей образ і поміщає його в реєстр Docker, після чого ми просто ще раз натискаємо кнопку "Deploy" у вікні Deploymentctl. При цьому автоматично запускається лог розгортання точно так, як це відбувалося при розгортанні першої версії програми.
Команда ~ kubectl get pods показує, що в даний момент запущено 2 версії програми, проте фронтенд показує, що ми все ще працює версія 1.
Балансувальник навантаження очікує, доки буде проведено перевірку health check, після чого перенаправить трафік на нову версію. Через 20 с ми перемикаємося на curl і бачимо, що тепер у нас розгорнуто 2 версію програми, а першу видалено.
Це було розгортання "здорового" - healthy - додатки. Давайте подивимося, що станеться, якщо для нової версії програми я зміню значення параметра Healthy з true на false, тобто спробую розгорнути unhealthy програму, яка не пройшла перевірку працездатності. Це може статися, якщо на стадії розробки в додатку були допущені якісь помилки конфігурації, і він у такому вигляді вирушив у продакшн.
Як бачите, розгортання проходить усі вищепоказані етапи, і ~ kubectl get pods показує, що запущені обидва пода. Але на відміну від попереднього розгортання, балка показує стан timeout. Тобто через те, що перевірка health check не пройшла, нова версія програми не може бути розгорнута. В результаті ви бачите, що система повернулася до використання старої версії програми, а нова версія просто видалена.
Добре в цьому те, що навіть якщо у вас є величезна кількість одночасних запитів, що надходять у додаток, вони навіть не помітять простою під час реалізації процедури розгортання. Якщо протестувати цю програму за допомогою фреймворку Gatling, яка надсилає йому максимально можливу кількість запитів, то не один із цих запитів не буде відкинутий. Це означає, що користувачі навіть не помітять оновлення версій в режимі реального часу. Якщо воно скінчиться невдачею, робота продовжиться на старій версії, якщо буде вдалою – користувачі перейдуть на нову версію.
Існує лише одна річ, яка може призвести до невдачі – якщо перевірка health check пройшла успішно, а додаток дав збій, як тільки на нього надійшло робоче навантаження, тобто колапс настане лише після завершення розгортання. В цьому випадку вам доведеться вручну відкотитись на стару версію. Отже, ми розглянули, як використовувати Kubernetes із призначеними для нього open-source інструментами. Процедура розгортання проходитиме набагато простіше, якщо ви вбудуєте ці інструменти в конвеєри створення/розгортання Build/Deploy pipelines. При цьому для запуску розгортання ви можете використовувати як інтерфейс користувача, так і повністю автоматизувати цей процес, застосувавши, наприклад, commit to master.
Наш сервер збірки Build Server створить Docker-образ, вставить його в Docker Hub або будь-який інший реєстр, який ви використовуєте. Хаб Docker підтримує webhook, тому ми можемо запустити віддалене розгортання через Deployer наведеним вище шляхом. Таким чином, можна повністю автоматизувати розгортання програми в потенційний продакшн.
Перейдемо до розгляду наступної теми – масштабування кластера Kubernetes. Зауважу, що команда kubectl є командою масштабування. З ще допомогою можна легко збільшити кількість реплік у кластері. Однак на практиці ми зазвичай хочемо збільшувати кількість не подів, а нодів.
При цьому в робочий час може знадобитися збільшення, а в нічний час, для скорочення вартості послуг Amazon – зменшення кількості запущених екземплярів програми. Це не означає, що буде достатньо масштабувати лише кількість подів, тому що навіть якщо один із нодів буде нічим не зайнятий, вам все одно доведеться платити за нього Amazon. Тобто поряд з масштабуванням подів вам знадобиться масштабувати і кількість використовуваних машин.
Це може викликати складнощі, тому що незалежно від того, використовуємо ми Amazon або інший хмарний сервіс, Kubernetes нічого не знає про кількість використовуваних машин. У ньому немає інструмента, що дозволяє масштабувати систему на рівні нодів.
Тож нам доведеться подбати і про ноди, і про поди. Ми можемо легко масштабувати запуск нових нодів за допомогою AWS API та машин групи масштабування Scaling group для налаштування кількості робочих вузлів Kubernetes. Також можна використовувати cloud-init або подібний до нього скрипт для реєстрації нодів у кластері Kubernetes.
Нова машина стартує у Scaling group, ініціює себе як нод, прописується в реєстрі майстра та починає роботу. Після цього можна збільшити кількість реплік для використання на нодах, що утворилися. Зменшення масштабу вимагає більших зусиль, оскільки необхідно переконатися, що подібний крок не призведе до знищення програм, що вже працюють, після відключення «непотрібних» машин. Для запобігання такому сценарію потрібно привести ноди до статусу unschedulable. Це означає, що планувальник за замовчуванням під час планування подів DaemonSet ігноруватиме ці ноди. Планувальник не буде нічого видаляти з цих серверів, але й запускатиме там ніяких нових контейнерів. Наступний крок полягає у витісненні вузла drain node, тобто у перенесенні з нього працюючих подів на іншу машину, або інші ноди, що мають достатню для цього ємність. Переконавшись, що на цих вузлах більше немає контейнерів, їх можна видалити з Kubernetes. Після цього для Kubernetes вони просто перестануть існувати. Далі потрібно використовувати AWS API для відключення непотрібних вузлів або машин.
Ви можете використовувати Amdatu Scalerd - ще один open-source інструмент для масштабування, аналогічний AWS API. Він надає CLI для додавання чи видалення нодів у кластері. Його цікавою особливістю є можливість налаштувати планувальник за допомогою наступного json-файлу.
Зображений код наполовину зменшує ємність кластера в нічний час. У ньому налаштовано як кількість наявних реплік, і бажана ємність кластера Amazon. Використання цього планувальника автоматично зменшить кількість вузлів уночі та збільшить їх вранці, дозволивши заощадити вартість використання нодів такого хмарного сервісу, як Amazon. Ця функція не вбудована в Kubernetes, але використання Scalerd дозволить вам як завгодно масштабувати цю платформу.
Хочу звернути вашу увагу на те, що багато людей говорять мені: «Все це добре, але як щодо моєї бази даних, яка зазвичай перебуває у статичному стані?» Як можна запустити щось подібне в такому динамічному середовищі, як Kubernetes? На мій погляд, ви не повинні робити це, не повинні намагатися організувати роботу сховища даних в Kubernetes. Технічно це можливо, і в інтернеті є посібники з цього питання, проте це серйозно ускладнить ваше життя.
Так, у Kubernetes є поняття постійних сховищ, і ви можете спробувати запускати такі сховища даних, як Mongo або MySQL, але це досить трудомістка задача. Це з тим, що сховища даних в повному обсязі підтримують взаємодію Космосу з динамічним оточенням. Більшість баз даних вимагають значного налаштування, у тому числі ручного налаштування кластера, не люблять автомасштабування та інші подібні штуки.
Тому не варто ускладнювати собі життя, намагаючись запустити сховище даних у Kubernetes. Організуйте їх роботу традиційним способом з використанням звичних сервісів і просто надайте Kubernetes можливість ними користуватися.
На завершення теми хочу познайомити вас з платформою Cloud RTI на базі Kubernetes, над якою працює моя команда. Вона забезпечує централізоване ведення логів, моніторинг додатків і кластерів і має безліч інших корисних функцій, які вам знадобляться. У ній використовуються різні open-source інструменти, такі як Grafana для відображення моніторингу.
Прозвучало питання, навіщо використовувати з Kubernetes балансувальник навантаження ha-proxy. Гарне питання, тому що в даний час існує 2 рівня балансування навантаження. Сервіси Kubernetes досі знаходяться на віртуальних IP-адресах. Ви не можете використовувати їх для портів зовнішніх хост-машин, тому що якщо Amazon перевантажить свій хмарний хост, адреса зміниться. Ось чому ми розміщуємо перед сервісами ha-proxy — щоб створити статичнішу структуру для безперебійної взаємодії трафіку з Kubernetes.
Ще одне хороше питання – як можна подбати про зміну схеми бази даних під час здійснення blue/green deployment? Справа в тому, що незалежно від використання Kubernetes, зміна схеми бази даних є складним завданням. Вам потрібно забезпечити сумісність старої та нової схеми, після чого ви зможете оновити базу даних, а потім оновити самі програми. Ви можете виконати "гарячу заміну" hot swapping бази даних, а потім оновити програми. Я знаю людей, які завантажували новий кластер бази даних з новою схемою, це варіант, якщо у вас є schemeless база даних типу Mongo, але в будь-якому випадку це не просте завдання. Якщо більше питань немає, дякую за увагу!
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог 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