І знову привіт!.. Напередодні старту курсу ми підготували ще один корисний переклад.
Service Mesh – це інфраструктурний рівень, що конфігурується, з низькою затримкою, який потрібен для обробки великого обсягу мережевих міжпроцесних комунікацій між програмними інтерфейсами програми (API). Service Mesh забезпечує швидку, надійну та безпечну комунікацію між контейнеризованими та часто ефемерними сервісами інфраструктури додатків. Service Mesh надає такі можливості, як виявлення сервісів, балансування навантаження, шифрування, прозорість, трасування, автентифікацію та авторизацію, а також підтримку шаблону автоматичного вимкнення (автоматичний вимикач).
Service Mesh зазвичай реалізується шляхом надання кожному екземпляру сервісу екземпляра проксі, який називається Sidecar. Sidecar обробляють комунікації між сервісами, здійснюють моніторинг та усувають проблеми безпеки, тобто все, що може бути абстраговано від окремих сервісів. Таким чином, розробники можуть писати, підтримувати та обслуговувати код програми у сервісах, а системні адміністратори можуть працювати з Service Mesh та запускати програму.
Istio від Google, IBM та Lyft, на даний момент є найвідомішою Service Mesh-архітектурою. А Kubernetes, що спочатку розроблявся в Google, зараз є єдиним фреймворком для оркестрації контейнерів, який підтримує Istio. Вендори намагаються створити комерційні версії Istio, що підтримуються. Цікаво, що нового вони зможуть привнести до проекту з відкритим кодом.
Проте Istio – це єдиний варіант, оскільки розробляються інші реалізації Service Mesh. Паттерн sidecar proxy є найбільш популярною реалізацією, як можна судити з проектів Buoyant, HashiCorp, Solo.io та інших. Існують і альтернативні архітектури: технологічний інструментарій Netflix – це один із підходів, де функціонал Service Mesh реалізується за рахунок бібліотек Ribbon, Hysterix, Eureka, Archaius, а також таких платформ як Azure Service Fabric.
Service Mesh також має свою власну термінологію для компонентів-сервісів та функцій:
- Фреймворк оркестрація контейнерів. У міру того, як все більше і більше контейнерів додається в інфраструктуру програми, виникає потреба в окремому інструменті для моніторингу та управління контейнерами – фреймворку оркестрації контейнерів. Kubernetes щільно зайняв цю нішу, причому настільки, що навіть його основні конкуренти Docker Swarm та Mesosphere DC/OS пропонують як альтернативу інтеграцію з Kubernetes.
- Сервіси та екземпляри (поди Kubernetes). Екземпляр – це єдина запущена копія мікросервісу. Іноді один екземпляр – це один контейнер. У Kubernetes екземпляр складається з невеликої групи незалежних контейнерів, що називається подом. Клієнти рідко звертаються безпосередньо до екземпляра або пода, частіше вони звертаються до сервісу, який представляє собою набір ідентичних масштабованих і стійких до відмов екземплярів або подів (реплік).
- Sidecar Proxy. Sidecar Proxy працює з одним екземпляром або подом. Сенс Sidecar Proxy в тому, щоб спрямовувати або проксувати трафік, що надходить від контейнера, з яким він працює, і зворотний трафік. Sidecar взаємодіє з іншими Sidecar Proxy та управляється фреймворком оркестрації. Багато реалізації Service Mesh використовують Sidecar Proxy для перехоплення та керування всім вхідним та вихідним трафіком екземпляра або пода.
- Виявлення сервісів. Коли екземпляру необхідно взаємодіяти з іншим сервісом, йому необхідно знайти (виявити) справний та доступний екземпляр іншого сервісу. Як правило, екземпляр виконує пошук по DNS. Фреймворк оркестрації контейнерів зберігає список екземплярів, які готові для отримання запитів, та надає інтерфейс для DNS-запитів.
- Балансування навантаження. Більшість фреймворків оркестрації контейнерів забезпечують балансування навантаження на 4 рівні (транспортному). Service Mesh реалізує більш складне балансування навантаження на 7 рівні (прикладному), багате на алгоритми і більш ефективне в питанні управління трафіком. Параметри балансування навантаження можуть бути змінені за допомогою API, що дозволяє оркеструвати синьо-зелене або канаркове розгортання.
- Шифрование. Service Mesh може зашифровувати та розшифровувати запити та відповіді, знімаючи цей тягар із сервісів. Service Mesh також може підвищити продуктивність за рахунок пріоритезації або перевикористання існуючих постійних з'єднань, що знижує необхідність дорогих обчислень для створення нових з'єднань. Найбільш поширеною реалізацією шифрування трафіку є mutual TLS (mTLS), де інфраструктура відкритих ключів (PKI) генерує та розповсюджує сертифікати та ключі для використання їх у Sidecar Proxy.
- Аутентифікація та авторизація. Service Mesh може авторизувати та автентифікувати запити, зроблені зовні або зсередини програми, надсилаючи екземплярам лише валідовані запити.
- Підтримка шаблону автоматичного вимкнення. Service Mesh підтримує , що ізолює нездорові екземпляри, а потім поступово повертає їх у пул здорових екземплярів при необхідності.
Та частина програми Service Mesh, яка керує мережевим трафіком між екземплярами називається Площина даних. Створення та розгортання конфігурації, яка керує поведінкою Площина даних, виконується за допомогою окремої Лінія управління. Лінія управління зазвичай включає в себе або спроектована таким чином, щоб підключатися до API, CLI або GUI для керування програмою.
Control Plane у Service Mesh розподіляє конфігурацію між Sidecar Proxy та Data Plane.
Часто архітектура Service Mesh застосовується для вирішення складних операційних завдань із використанням контейнерів та мікросервісів. Піонерами в області є такі компанії як Lyft, Netflix і Twitter, які надають сервіси, що стабільно працюють, мільйонам користувачів по всьому світу. (). Для менш вимогливих прикладних завдань швидше за все буде досить простих архітектур.
Архітектура Service Mesh навряд чи стане відповіддю на всі питання, пов'язані з роботою додатків та їх доставкою. Архітектори та розробники мають величезний арсенал інструментів, і лише один з них — молоток, який серед безлічі завдань повинен вирішувати лише одне – забивати цвяхи. , наприклад, включає кілька різних моделей, які дають безперервний спектр підходів до вирішення завдань за допомогою мікросервісів.
Елементи, які поєднуються в архітектурі Service Mesh, такі як NGINX, контейнери, Kubernetes та мікросервіси як архітектурний підхід, можуть бути не менш продуктивно використані і в реалізаціях без Service Mesh. Наприклад, Istio був розроблений як повноцінна архітектура Service Mesh, але модульність говорить про те, що розробники можуть вибирати та застосовувати лише необхідні їм компоненти технологій. Пам'ятаючи про це, необхідно сформувати чітке розуміння концепції Service Mesh, навіть якщо ви не впевнені, що зможете коли-небудь повноцінно її реалізувати в додатку.
Джерело: habr.com