Використання Kubernetes для оркестрації пристроїв в edge computing

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, спільното. Мене звати Михайло Майдан, я — Head of Rust department у Yalantis. Компанія має глибоку експертизу використання мови Rust та декілька поточних проєктів у секторі зеленої енергетики, медичного та промислового ІoT. До цього я мав пʼять років досвіду роботи Embedded Engineer з використанням C/C++ і є справжнім embedded enthusiast.

Зі зростанням популярності IoT з‘являється багато викликів: об‘єднання великої кількості пристроїв в одну мережу, управління, масштабування та забезпечення відмовостійкості. Із цим легко можна впоратися за допомогою Kubernetes! Ви, напевно, чули про цей інструмент для оркестрування, масштабування та забезпечення відмовостійкості системи, але чи знаєте ви, що він також може допомогти інтегрувати різноманітні IoT-пристрої в єдину розподілену систему? Сьогодні ми з вами поговоримо про використання Kubernetes для керування і застосунками, і IoT-гаджетами.

Edge computing vs cloud

Edge computing передбачає обробку даних ближче до джерела їхнього виникнення, що часто вказує на контраст з cloud computing. Насправді ж це не суперечить cloud computing, а скоріше доповнює його. Він завжди діє сумісно з cloud-інфраструктурою, надаючи можливість обробки даних у місці їхнього виникнення.

Розглянемо ситуацію з IoT-пристроями, наприклад сенсорами. Коли сенсор передає велику кількість даних, і від результату обробки залежить чиєсь життя (невчасна реакція може обернутися катастрофою) — важливо швидко реагувати на них. Обробка даних на cloud може зайняти багато часу, або ж проблеми зі зв’язком можуть вплинути на час доставки рішення на пристрій, тому використовуються спеціальні edge node або сервери, що розташовані в одній мережі з джерелом даних. Вони можуть швидко обробляти й реагувати на інформацію, ухвалюючи рішення на місці.

Особливо це актуально, коли час реакції є критично важливим. Архітектура edge computing досить проста: на одному боці є cloud-інфраструктура зі своїми серверами для обробки даних, показом інформації користувачам й отриманням команд. З іншого боку — edge node, що можуть бути поруч з джерелами даних, як-от IoT-пристрої. Ці edge node обробляють дані на місці, забезпечуючи швидку реакцію, і можуть також синхронізуватися з cloud, якщо це необхідно.

Edge node можуть бути різними пристроями: від спеціалізованих серверів до мінікомп’ютерів, наприклад: Raspberry Pi, Orange Pi та інші. Такі node дозволяють обробляти критично важливі дані близько до місця їхьої появи та віддавати команди залежно від алгоритму. Часто такі node перебувають в одній мережі з ІоТ-пристроями. Це особливо важливо, коли потрібно зменшити потік води чи, наприклад, перекрити газ у місці витоку.

Use case

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

Щоб забезпечити такий сценарій, розглянемо просте, але ефективне рішення, яке надалі можна буде розширити. Спочатку використовувати MQTT (Message Queuing Telemetry Transport) для зв’язку з девайсами. Це дозволить реалізувати патерн, де девайси надсилають дані до edge node, які можуть обробляти дані локально або надсилати їх у хмару для обробки надалі. Таке рішення буде простим, але водночас воно не дасть так просто розширювати систему чи зробити її відмовостійкою — для цього будуть потрібні інші підходи.

Аби покрити всі необхідні вимоги, розглянемо використання Kubernetes. K8S має всі необхідні характеристики, щоб автоматизувати розгортання, моніторинг та контроль за системою з такою великою кількістю пристроїв. K8S дозволить масштабувати систему, а також гарантує її безпеку.

Загалом, ваша система буде містити MQTT-брокера для обміну даними між IoT-девайсами та edge node — це потрібно для зменшення кількості трафіку в локальній мережі. Але K8S займає нішу автоматизації управління, моніторингу та обслуговування edge node та конфігурації IoT-пристроїв, які підімкнені до них.

Що таке Kubernetes?

Kubernetes — це open-source рішення, розроблене компанією Google, написане на Go, яке дозволяє керувати процесом розгортання та масштабування застосунків.

Однією з його основних фішок є здатність координувати та керувати мікросервісами, надаючи їм потрібні ресурси та балансуючи навантаження.

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

Контейнери є основною одиницею роботи в Kubernetes. Ви, напевно, знаєте про Docker-контейнери — це щось на кшталт невеликих «капсул», у які можна запакувати своє програмне забезпечення з усіма його залежностями та середовищем. А от кожен такий контейнер в Kubernetes має свій особливий термін — Pod. Це як самостійний модуль, готовий для деплою й обробки.

Вам хочеться мати змогу безпроблемно розгортати свій вебсервер? Деплоймент в Kubernetes — те, що вам потрібно. Це «магічна кнопка» для запуску вашого коду.

Коли йдеться про виведення системи в зовнішній світ, допоможе Service. Він забезпечує доступність вашого застосунка в зовнішній мережі.

У Kubernetes основні елементи, про які нам зараз буде цікаво говорити, — це node і Control plane.

Суть роботи Kubernetes — його власний сервер, який називається Control plane. Він відповідальний за керування всіма node, підняття подів, масштабування та інше. І, звісно ж, користувач має можливість конфігурувати його згідно зі своїми потребами, налаштовуючи різні параметри системи. Важливо бути пильними під час конфігурації, оскільки неправильні налаштування можуть призвести до помилкової роботи системи або зайвих витрат.

Наприклад, якщо ви хочете завжди мати в готовності певну кількість node, вам слід підійти до цього питання ретельно, особливо якщо плануєте використовувати послуги хмарних платформ, як-от AWS. Раціональний підхід може допомогти зменшити зайві витрати. Варто відзначити, що існують рішення для ефективного управління ресурсами.

Щодо самого Kubernetes, то його скорочена назва — K8S. Цей «звичайний» Kubernetes є універсальним рішенням, яке застосовується в більшості випадків.

K3S

Існують рішення, які спеціально призначені для вбудованих систем як K3S. Крім того, є ще декілька варіацій, таких як K3D, що взагалі базується на K3S. Варто вказати й на kube edge, який можна розглядати як лайтвейт версію стандартного Kubernetes. Вони дозволяють використовувати багато з того функціоналу, який надає Kubernetes, зменшуючи вимоги до апаратних ресурсів.

Призначення цих рішень досить гнучке. Наприклад, Control plane або мастер-сервер може взяти на себе навіть Raspberry Pi, який має мінімальні апаратні вимоги — 500 МБ оперативної пам’яті, хоча рекомендації стосуються мінімум 1 ГБ.

Node або agent node — це пристрої, на яких Control plane буде запускати Pods та виконувати різні задачі. За характеристиками node можуть бути менш потужними, але для того, щоб забезпечити нормальне функціонування демона K3S, потрібно аби пристрій мав достатньо потужний процесор і RAM. Rasbperry Pi від версії 3 буде достатньо.

Сценарій має такий вигляд: маємо основний сервер з внутрішньою базою даних SQLite, який взаємодіє з agent node та іншими пристроями, які вирішують різні задачі. Control plane ухвалює рішення про те, які поди підняти, скільки їх запустити й інші параметри.

Kubernetes Custom Resource Definition

Kubernetes має дуже цікавий механізм — Kubernetes Custom Resource Definition (CRD). Звісно, він не випадково так названий — це можливість розширювати Kubernetes API за допомогою власних ресурсів.

Ідея в тому, що ви можете створити власний тип ресурсу, визначивши його структуру за допомогою Custom Resource Definition. Після цього ресурс стає доступним для всіх node у кластері.

Мовою Kubernetes цей підхід називається «оператор». Його можна зрозуміти краще, розглядаючи використання Custom Resource Definition. Ці ресурси зберігаються в etcd — довіреній базі даних Kubernetes. Ця база даних зберігає стан кожного об’єкта, який був створений згідно з CRD.

Ви можете використовувати Kubernetes API для встановлення та зчитування стану цих ресурсів. І коли ви задаєте стан, ви фактично керуєте цим об’єктом, а зчитуючі стан — отримуєте поточні дані.

Ця концепція базується на патерні оператор. Оператор — це поєднання Custom Resource Definition та контролера, який відповідає за взаємодію із цими ресурсами. Контролер постійно моніторить та керує станами, збереженими в CRD. Ви можете використовувати цю структуру для реалізації різних сценаріїв. Наприклад, створити CRD для опису пристрою, який має підтримувати певну температуру, і використовувати оператор для автоматизації керування температурою цього пристрою.

Solution Design

Розробімо рішення для описаного вище use case — локального оброблення даних. Припустимо, ми маємо сенсори, які моніторять температуру і передають дані. Якщо температура перевищує певне значення, ми хочемо виконати дії, наприклад, перекрити подачу газу або щось подібне.

Для цього ми можемо використовувати Raspberry Pi як edge node. Оскільки сенсори зазвичай — це пристрої з мінімальними потужностями, а також з батарейкою, вони не можуть бути в ролі K3S node. Але edge node чудово підходить на цю роль. Для комунікації між edge node краще взяти якийсь IoT-протокол, для прикладу MQTT, і комунікувати з усіма сенсорами через нього. Сенсори передають дані на edge node за допомогою MQTT, а edge node приймає рішення на місці.

Ми можемо встановити правила на Raspberry Pi, які вказують, як реагувати на різні значення температури. Наприклад, якщо температура перевищує заданий поріг, Raspberry Pi може відправити команду на сенсор або інший пристрій, щоб перекрити подачу газу. Також, якщо необхідно, Raspberry Pi може відправити ці дані на центральний сервер або на Gateway для подальшого аналізу або звітування.

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

Remote control

Ми бажаємо забезпечити можливість віддалено контролювати систему — задати максимальну температуру у кімнаті, наприклад, 22 градуси. Це можна зробити через вебінтерфейс, який взаємодіє з хмарним сервером. Сервер знає, яка edge node відповідає за цей пристрій, оскільки кожна edge node створює набір CRD і об’єктів для них, які дозволяють бачити сенсори в систему K3S як об’єкти-ресурси і керувати ними за допомогою K8S API.

У CRD є два основних поля — spec (специфікація) та status (стан).

Поле spec містить значення, які користувач встановлює, наприклад, задану максимальну температуру. Контролер спостерігає за полем status та вирішує, як реагувати, якщо специфікація не збігається зі станом. Наприклад, якщо користувач задав температуру 22 градуси, а фактичний стан показує 20, контролер може зробити додаткові дії — відправку команди на інші пристрої для досягнення заданого значення.

Така система дозволяє віддалено керувати пристроями та контролювати їх стан за допомогою хмарних ресурсів та Kubernetes.

Зберігання Custom Resource Definitions (CRD) в системі K3S: внутрішня та зовнішня бази даних

Розглянемо де можна зберігати Custom Resource Definitions (CRD).

У K3S є декілька варіантів, які дозволяють зберігати ці CRD. Один з варіантів — використовувати внутрішню базу даних, зокрема etcd, яку K3S використовує як свій Storage для Control plane. Тобто etcd буде відповідальний за збереження стану і конфігурації CRD.

Альтернативно можна вказати K3S використовувати зовнішні бази даних, як-от MySQL або Postgres. База даних буде використовуватися для зберігання станів та конфігурацій CRD. Це може забезпечити швидше функціонування, але, звісно, потребує додаткової інфраструктури та налаштувань.

Також можна реалізувати ситуацію, де кожен Control plane має свою внутрішню базу даних, але вони синхронізуються між собою. Це також забезпечить швидке відновлення та високу доступність.

Щодо K3S-агентів, вони представляють інші пристрої, які підімкнені до Control plane. Агенти надсилають інформацію про свій стан та дії, і це дозволяє системі взаємодіяти з ними та вносити зміни в їхній стан.

Scaling

У випадку індустріальних об’єктів з великою кількістю IoT-пристроїв, важливо забезпечити ефективний механізм масштабування системи. Завдяки K3S ми можемо використовувати механізми автоскейлінгу для забезпечення оптимальної обробки навантаження.

Система має можливість автоматичного масштабування завдяки Kubernetes. Під час піків навантаження, коли об’єм даних різко зростає, ми можемо динамічно збільшити кількість оброблюючих подів. Наприклад, використати Raspberry Pi як edge node і призначити їх для обробки даних. У критичних моментах, коли навантаження зростає, система автоматично підмикатиме додаткові Raspberry Pi до обробки даних та перенаправлятиме трафік на них.

Нам лише потрібно налаштувати правила, за якими система буде реагувати на зміни навантаження. Наприклад, якщо спостерігається, що використання CPU на одній node перевищує 70%, система автоматично активує процес перенаправлення трафіку на інші node. Це робиться для того, щоб забезпечити оптимальну продуктивність системи та знизити час відгуку на запити.

Availability

Під час розробки вбудованих застосунків на мовах програмування C, C++ або Rust, часто виникають проблеми, пов’язані з витоком пам’яті, невизначеною поведінкою (UB) та іншими. Це призведе до некоректної роботи аплікації, навіть її зупинки. Однак Kubernetes допоможе забезпечити надійну доступність системи.

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

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

Такий підхід забезпечує високу доступність системи, уникає впливу можливих падінь аплікацій на її функціонування.

Deployment

Kubernetes має вбудовані стратегії автодеплойменту, які дозволяють ефективно оновлювати ваші застосунки.

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

Це дає можливість перенаправити лише частину трафіку на нову версію та вивчити її реакцію на навантаження. Якщо нова версія працює стабільно, трафік можна перемикати повністю. Важливо зауважити, що навіть якщо нова версія зазнає збою, Kubernetes не вбиває стару версію, а забезпечує збереження стабільності системи.

Такі різні стратегії дозволяють ефективно впроваджувати оновлення та забезпечувати стійкість системи під час міграцій.

Висновки

Система, побудована на основі Kubernetes, зокрема K3S та kube edge, має численні переваги для впровадження в edge-обчислення. Її легкий бінарний об’єм (навіть менш ніж 70 МБ) та вбудована функціональність роблять її хорошим вибором для впровадження на пристроях з обмеженими ресурсами, як-от Raspberry Pi.

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

Custom Resource Definition дозволяє розширювати можливості системи та описувати власні сутності, забезпечуючи гнучкість та налаштовуваність. Також варто відзначити зручність роботи з API, що дає можливість зчитувати та записувати дані за допомогою однакових інтерфейсів.

Проте є деякі недоліки, як-от вимоги до апаратних ресурсів. Для нормальної роботи системі потрібно достатньо оперативної пам’яті та швидкого диску. Хоча й система стає все популярнішою, знайти великі комерційні використання її можливостей поки що важко.

Система на базі Kubernetes є потужним інструментом для побудови edge-рішень, з усіма її перевагами та викликами.