Привіт, Хабре! Представляю вашій увазі переклад статті «Service mesh data plane vs control plane» автора Метт Клейн.

На цей раз «захотілося і перевелося» опис обох компонентів service mesh, data plane і control plane. Цей опис мені здався найзрозумілішим і найцікавішим, а головне підводить до розуміння «А чи потрібне воно взагалі?».

Оскільки ідея «Сервісної мережі (Service mesh)» стає все більш популярною протягом останніх двох років (Оригінальна стаття від 10 жовтня 2017), а кількість учасників у просторі зросла, я побачив пропорційне зростання плутанини серед усієї технічної спільноти щодо того, як порівнювати та протиставляти різні рішення.

Ситуацію найкраще описати наступними серіями твітів, які я написав у липні:

Плутанина з сервісною мережею (service mesh) № 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Жоден із них не дорівнює Istio. Istio – це щось зовсім інше. 1/

Перші просто площині даних (data planes). Самі собою вони нічого не роблять. Вони мають бути налаштовані на щось більше. 2 /

Istio є прикладом площини керування (control plane), яка зв'язує частини разом. Це інший шар. /кінець

У попередніх твітах згадується кілька різних проектів (Linkerd, NGINX, HAProxy, Envoy та Istio), але, що важливіше, вводяться загальні поняття площини даних (data plane), сервісної мережі (service mesh) та площини керування (control plane). У цьому пості я зроблю крок назад і розповім, що я маю на увазі під термінами "площина даних (data plane)" і "площина управління (control plane)" на дуже високому рівні, а потім розповім, як терміни відносяться до проектів, згаданих у твітах.

Що таке сервісна мережа (What is a service mesh, really)?

Рисунок 1: Огляд мережі (Service mesh overview)

Малюнок 1 ілюструє концепцію сервісної мережі (service mesh) на базовому рівні. Є чотири сервісні кластери (AD). Кожен екземпляр сервісу пов'язаний з локальним сервером проксі. Весь мережевий трафік (HTTP, REST, gRPC, Redis тощо) від окремого екземпляра програми передається через локальний проксі-сервер у відповідні зовнішні сервісні кластери. Таким чином, екземпляр програми не знає про мережу в цілому і знає лише про своє локальне проксі. Фактично, мережу розподіленої системи було віддалено від сервісу.

Площина даних (Data plane)

У сервісній мережі (service mesh) проксі-сервер, розташований локально для програми, виконує такі завдання:

• Виявлення сервісів (Service discovery). Які сервіси/служби/програми доступні для вашої програми?
• Перевірка працездатності (Health checking). Чи є екземпляри сервісів, повернені виявленням сервісів (service discovery), працездатними та чи готові приймати мережевий трафік? Це може включати як активну (наприклад, перевірка відповіді/healthcheck), так і пасивну (наприклад, з використанням 3 послідовних 5xx помилок як індикація нездорового стану сервісу) перевірки працездатності.
• Маршрутизація (Routing). Отримавши від сервісу REST запит до «/foo», до якого сервісного кластера слід надсилати запит?
• Балансування навантаження (Load balancing). Після того як під час маршрутизації було обрано кластер сервісу, до якого примірника сервісу має бути надіслано запит? З яким таймаутом? З якими параметрами обриву ланцюга (circuit breaking)? Якщо запит не вдався, його потрібно повторити?
• Аутентифікація та авторизація (Authentication and authorization). Для вхідних запитів, чи може викликаючий сервіс бути криптографічно пізнаний/авторизований за допомогою mTLS або будь-якого іншого механізму? Якщо він упізнаний/авторизований, чи дозволено йому викликати запитану операцію (endpoint) у сервісі, чи має бути повернена неавтентифікована відповідь?
• Спостережуваність (Observability). Для кожного запиту повинні бути згенеровані докладні статистичні дані, журнали/логи та дані розподіленого трасування, щоб оператори могли розуміти розподілений потік трафіку та проблеми налагодження в міру їх виникнення.

За всі попередні пункти в сервісній мережі (service mesh) відповідає площина даних (data plane). Насправді, локальний для сервісу (sidecar) проксі і є площиною даних (data plane). Іншими словами, площина даних (data plane) відповідає за умовну трансляцію, пересилання та спостереження за кожним мережевим пакетом, який надсилається в сервіс або надсилається з нього.

Площина керування (The control plane)

Мережева абстракція, яку забезпечує локальний проксі у площині даних (data plane), є чарівною (?). Проте як проксі-сервер насправді дізнається про маршрут «/foo» до сервісу B? Які дані виявлення сервісів (service discovery), які заповнюються проксі-запитами, можуть бути використані? Як налаштовані параметри балансування навантаження, таймууту (timeout), обриву ланцюга (circuit breaking) тощо? Як здійснюється розгортання програми з використанням синього/зеленого (blue/green) методу чи методу поступового переведення трафіку? Хто налаштовує параметри загальносистемної автентифікації та авторизації?

Всі перелічені вище пункти перебувають у веденні площині управління (control plane) сервісної мережі (service mesh). Площина управління (control plane) приймає набір ізольованих проксі-серверів без стану та перетворює їх на розподілену систему.

Я думаю, що причина, через яку багато технологій знаходять заплутаними розділені поняття площини даних (data plane) і площини керування (control plane), полягає в тому, що для більшості людей площина даних знайома, тоді як площина керування чужорідна/незрозуміла. Ми вже давно працюємо з фізичними мережевими маршрутизаторами та комутаторами. Ми розуміємо, що пакети/запити повинні йти з пункту А до пункту Б, і що ми можемо використовувати для цього апаратне та програмне забезпечення. Нове покоління програмних проксі — просто модні версії інструментів, які ми використовували протягом тривалого часу.

Малюнок 2: Людська площина управління (Human control plane)

Проте, ми вже тривалий час використовували площини управління (control plane), хоча більшість мережевих операторів можуть пов'язувати цю частину системи з будь-яким технологічним компонентом. Причина цього проста:
Більшість площин управління (control plane), що використовуються сьогодні, - це ... ми.

На малюнку 2 показано те, що я називаю «Людською площиною управління (Human control plane)». У цьому типі розгортання, яке все ще трапляється дуже часто, людина-оператор, ймовірно сварлива, створює статичні конфігурації — потенційно, за допомогою скриптів — і розгортає їх за допомогою якогось спеціального процесу на всіх проксі-серверах. Потім проксі починають використовувати цю конфігурацію та приступають до обробки площини даних (data plane) з використанням оновлених налаштувань.

Рисунок 3: Розширена площина керування сервісною мережею (Advanced service mesh control plane)

На малюнку 3 показано «розширена» площину керування (control plane) сервісної мережі (service mesh). Вона складається з наступних частин:

• Людина (The human): Все ще є людина (сподіваюся, менш сердита), яка приймає рішення на високому рівні щодо всієї системи в цілому.
• Інтерфейс площини управління (Control plane UI): Людина взаємодіє з будь-яким типом інтерфейсу користувача для управління системою. Це може бути веб-портал, додаток командного рядка (CLI) або інший інтерфейс. За допомогою інтерфейсу користувача оператор має доступ до таких глобальних параметрів конфігурації системи, як:
  • Управління розгортанням, синій/зелений (blue/green) та/або з поступовим переведенням трафіку
  • Параметри автентифікації та авторизації
  • Специфікації таблиці маршрутизації, наприклад, коли додаток A запитує інформацію про /foo, що відбувається
  • Налаштування балансувальника навантаження, наприклад, тайм-аут (timeouts), повторні спроби (retries), параметри обриву ланцюга (circuit breaking) і т.д.
• Планувальник робочого навантаження (Workload scheduler): Сервіси запускаються в інфраструктурі через систему планування/оркестрації певного типу, наприклад Kubernetes або Nomad. Планувальник відповідає за завантаження служби разом із її локальним проксі-сервером.
• Виявлення сервісу (Service discovery). Коли планувальник запускає та зупиняє екземпляри сервісу, він повідомляє про стан працездатності до системи виявлення сервісу.
• API конфігурації локального проксі-сервера (Sidecar proxy configuration APIs) : Локальні проксі-сервери динамічно витягують стан із різних компонентів системи за моделлю «узгодженість у кінцевому рахунку» (eventually consistent) без участі оператора. Вся система, що складається з усіх запущених на даний момент екземплярів сервісів і локальних проксі-серверів, зрештою сходиться в одну екосистему. API універсальної площини даних (data plane) у Envoy є одним із прикладів того, як це працює на практиці.

По суті, мета площини управління (control plane) полягає в тому, щоб встановити політику, яка зрештою буде прийнята площиною даних (data plane). Більш досконалі площини управління (control plane) приберуть від оператора більше деталей деяких систем і вимагатимуть менше ручного управління, за умови, що вони працюють правильно!

Площина даних та площина управління. Зведення (Data plane vs. control plane summary)

• Площина даних сервісної мережі (Service mesh data plane): торкається кожного пакета/запиту в системі. Відповідає за виявлення додатків/сервісів, перевірку працездатності, маршрутизацію, розподіл навантаження, автентифікацію/авторизацію та спостережуваність.
• Площина управління сервісною мережею (Service mesh control plane): надає політику та конфігурацію для всіх працюючих площин даних всередині сервісної мережі. Не чіпає жодних пакетів/запитів у системі. Площина управління перетворює всі площини даних на розподілену систему.

Поточний стан проекту (Current project landscape)

Розібравшись з поясненням вище, подивімося на поточний стан проекту «сервісної мережі (service mesh)».

• Площина даних (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Площини керування (Control planes): Istio, Nelson, SmartStack

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

На початку 2016 року Linkerd був одним із перших проксі-серверів площини даних (data plane) для сервісної мережі (service mesh) та проробив фантастичну роботу щодо підвищення обізнаності та збільшення уваги до моделі проектування «сервісна мережа» (service mesh). Приблизно через 6 місяців після цього Envoy приєднався до Linkerd (хоча працював у Lyft з кінця 2015 року). Лінкерд та Envoy — це два проекти, які найчастіше згадуються під час обговорення сервісних мереж (service mesh).

Istio було оголошено у травні 2017 року. Цілі проекту Istio дуже схожі на розширену площину управління (control plane), показану на малюнку 3. Envoy для Istio є проксі-сервером "за замовчуванням". Таким чином, Istio є площиною управління (control plane), а Envoy - площиною даних (data plane). За короткий час Istio викликало багато хвилювань, та інші площини даних (data plane) почали інтеграцію як заміну Envoy (і Linkerd, і NGINX продемонстрували інтеграцію з Istio). Той факт, що в одній площині управління можна використовувати різні площини даних (data plane), означає, що площина управління (control plane) і площина даних (data plane) не обов'язково тісно пов'язані. Такий API, як універсальний API площини даних (data plane) Envoy, може утворювати міст між двома частинами системи.

Nelson і SmartStack допомагають додатково проілюструвати поділ площини керування (control plane) та площини даних (data plane). Nelson використовує Envoy як проксі і будує надійну площину управління (control plane) сервісної мережею (service mesh) з урахуванням стека HashiCorp, тобто. Nomad і т.д. SmartStack став, мабуть, першим із нової хвилі сервісних мереж (service mesh). SmartStack формує площину керування (control plane) навколо HAProxy або NGINX, демонструючи можливість розв'язування площини керування (control plane) сервісною мережею (service mesh) та площини даних (data plane).

Мікросервісна архітектура із сервісною мережею (service mesh) привертає до себе дедалі більше уваги (правильно!), і дедалі більше проектів та вендорів починають працювати у цьому напрямі. Протягом наступних кількох років ми побачимо багато інновацій як у площинах даних (data plane), так і у площинах керування (control plane), а також подальше змішування різних компонентів. Кінець кінцем мікросервісна архітектура має стати більш прозорою і чарівною (?) для оператора.
Сподіваюся, дедалі менш роздратованого.

Ключові моменти (Key takeaways)

• Сервісна мережа (service mesh) і двох різних частин: площині даних (data plane) і площині управління (control plane). Обидва компоненти обов'язкові, і без них система не працюватиме.
• Всі знайомі з площиною керування (control plane), і на даний момент площиною керування (control plane) можете бути ви!
• Всі площини даних (data plane) конкурують між собою за функціями, продуктивністю, конфігурованістю та розширюваністю.
• Усі площини управління (control plane) конкурують між собою за функціями, конфігурованістю, розширюваністю та зручністю використання.
• Одна площина управління (control plane) може містити правильні абстракції та API, щоб можна було використовувати кілька площин даних (data plane).

Джерело: habr.com