Service Mesh Vocabulary: Istio, Envoy, and mTLS Explained (англійською)
Площина даних, площина керування, проксі- сервер, Envoy, Istio, mTLS, VirtualService, DestinationRule — словник мережі служб, який вам потрібен для обговорення архітектури Kubernetes англійською мовою.
Сервісні мережі вирішують одну з найскладніших проблем в мікросервісах: робить комунікацію між сервісами надійною, безпечною і спостережною - без необхідності кожної команди сервісу реалізовувати власну логіку повторних спроб, розриву ланцюга і mTLS. Якщо ви працюєте у середовищі Kubernetes, словник мережевих служб постійно з’ являється у оглядах архітектури, підручниках з керування та обговореннях команди з розробки платформи.
Архітектура: плани і проксі
** Service mesh ** — Виділений шар інфраструктури, який обробляє зв’ язок між службами. Сервісна мережа забезпечує керування трафіком, безпеку (mTLS) і спостережність (розподілене відстеження, метрики) прозорими — без змін до коду програми. Фраза: “Ми ввели мережу сервісів для забезпечення mTLS між всіма внутрішніми службами і отримання розподіленого відстеження з коробки.”
** Площа даних ** — Компонент мережі служб, який обробляє мережевий трафік: перехоплення, маршрутизацію, балансування навантаження і шифрування запитів. Площа даних реалізується за допомогою проксі- серверів, які працюють разом з кожною службою. Фраза: “Envoy є рівнем даних — він обробляє кожен пакет, що входить і виходить з сервісу.”
** Площина керування ** — компонент, який налаштовує проксі- сервери площини даних і керує ними. За допомогою цієї програми розповсюджуються правила, сертифікати і правила маршрутизації для всіх проксі- серверів у мережі. Фраза: “Istiod є контролюючим рівнем — він відсилає оновлені налаштування маршрутизації до Envoy проксі по кластеру.”
** Sidecar proxy ** — Проксі- контейнер, вставлений у кожен під поряд з контейнером програми. Sidecar перехоплює весь вхідний і вихідний трафік, застосовуючи правила мережі прозорими. Фраза: “Проксі sidecar автоматично вводиться в кожен Pod у просторі імен production — програма про це не знає.”
** Envoy proxy ** (вимова: * « en- voi » *) — відкритий високошвидкісний проксі- сервер, який використовується як площина даних Istio і багатьма іншими мережами служб. Дуже налаштовується через xDS API. Фраза: “Envoy виставляє свою статистику на /stats/prometheus — ми скачуємо їх для метрики трафіку сервісу.”
Впровадження мережевих послуг
** Istio ** (вимова: * “is- tee- oh” *) — Найбільш широко розгорнута мережа сервісів, що використовує Envoy як площину даних і Istiod як площину керування. Багатий набір можливостей: керування трафіком, mTLS, RBAC, додатки Wasm. Фраза: “Ми запускаємо Istio в режимі оточення — без причепів, що значно зменшує витрати ресурсів.”
Linkerd (вимова: “linker-dee”) — легка, рідна для Kubernetes мережа служб, написана на Rust. Простіше, ніж Istio, з меншими витратами ресурсів. Фраза: “Ми обрали Linkerd над Istio — команда виявила його операційну складність набагато нижче.”
Безпека: mTLS
** mTLS (Mutual TLS) ** — Обидва клієнти і сервер розпізнають один одного за допомогою сертифікатів X. 509, встановлюючи зашифроване з’ єднання з взаємною розпізнаванням. У мережі сервісів mTLS застосовується прозорими проксі-серверами sidecar. Фраза: “mTLS забезпечує, що тільки послуги з чинним сертифікатом, виданим мережевим CA, можуть спілкуватися — підрозділ підробки не може олігархізувати легітимну службу.”
** Меш- федерація** — з’ єднання двох або більше мереж служб (потенційно, через кластери або хмари), щоб служби у одній мережі могли безпечно спілкуватися зі службами у іншій мережі. Фраза: “Меш-федерація між кластерами ЄС і США дозволяє службі користувача в ЄС викликати службу розрахунків в США з mTLS і повною спостережністю.”
Транспортне управління
** Правила обліку трафіку ** — налаштування, які керують маршрутизацією трафіку до служби: алгоритм балансування навантаження, параметри пулів з’ єднань, виявлення відхилень (розривів). Визначено в Істіо DestinationRule.
** Правило повторних спроб ** — налаштування, які вказують, скільки разів проксі- сервер повинен повторювати невдалий запит, за яких умов і з яким відстроченням. Фраза: * “Політика повторних спроб на 5xx помилки повторюється до трьох разів з експоненційним відступом назад — не потрібно змінювати код програми.” *
** Перерва у роботі на рівні мережі ** — Проксі мережі служб автоматично припиняє пересування запитів до непрацездатної кінцевої точки, що знаходиться вище за межу помилок, надаючи йому час на відновлення. Фраза: “Відключення в DestinationRule викинуло екземпляр, що зазнав невдачі, після п’яти послідовних помилок 503.”
** VirtualService ** — нетиповий ресурс Istio, який визначає правила маршрутизації для трафіку до служби: розділення трафіку, маршрутизація за заголовками, введення помилок, тайм- аут. Фраза: “VirtualService маршрутизує 10% трафіку до версії canary і 90% до stable.”
** DestinationRule ** — нетиповий ресурс Istio, який визначає правила, які буде застосовано до трафіку * після* маршрутизації: правила балансування навантаження, параметри пулів з’ єднань, налаштування автоматичних перемикачів, параметри mTLS.
** Шлюз вхідних даних ** — точка вхідної мережі служб для трафіку, що входить до кластера ззовні. Istio IngressGateway управляє зовнішнім трафіком, на відміну від мережевого трафіку між службами. Фраза: “TLS закінчення відбувається на Ingress Gateway — схід-захід трафік всередині мережі використовує mTLS end-to-end.”
Спостережливість з Меші
** Розподілене відстеження за допомогою мережі ** — Мережа служб може автоматично поширювати контекст відстеження (наприклад, B3 заголовки або W3C traceparent ) між службами і звітами простягаються до сервера відстеження, що забезпечує розподілене відстеження з мінімальними інструментами програми. Фраза: “Istio генерує трасування для кожного переходу в графі сервісу — ми не торкалися коду програми.”
** Спостережливість з мережі ** — Мережа надає * золоті сигнали * (затримка, трафік, помилки, насиченість) для кожної взаємодії між службами як метрики Prometheus, без будь- якого інструментування на рівні програми. Фраза: “Метрик мережі показує, що затримка P99 автентифікації збільшилася після останнього розгортання — це вузьке місце.”
** Вправа: ** Намалювати діаграму архітектури з двома службами з сітки служб і позначки: площина даних, площина керування, проксі- сервер, з’ єднання mTLS і шлюз Ingress. Потім напишіть пояснення діаграми у 100 слів, використовуючи словник з цього повідомлення.
На практиці: Навігація нюансів і уникнення нерозуміння
Будьмо чесними - навіть досвідчені розробники іноді натякають на термінологію навколо мереж послуг. Це не просто про те, щоб знати * що * Istio, Envoy, або mTLS є; це про розуміння того, як обговорювати їх ефективно з колегами, особливо при спілкуванні в різних командах або середовищах. Для тих, хто вивчає професійну англійську, точність і ясність є найважливішими, і саме тут тонкі відмінності у фразуваннях можуть створити плутанину.
Поширений сценарій виникає під час перегляду коду. Уявіть старшого інженера Марка, який коментує запит на витяг, який використовує VirtualService. Він може написати: « Це визначення VirtualService здається надто складним; чи не могли б ми спростити його, щоб маршрутизувати трафік лише за назвою вузла? » Якщо молодший розробник, Elena, не має досвіду роботи з мережами сервісів і має проблеми з терміном « VirtualService », вона може сприйняти коментар Марка як критику її вибору у проектуванні. Проблема не обов’язково в тому, що робить VirtualService - це те, що Єлена не має конкретного словника, щоб повністю зрозуміти архітектурну концепцію і наміри Марка. Аналогічно, повідомлення Slack, що обговорює проблеми з затримкою, може швидко застрягти в технічному жаргоні, якщо учасники не послідовно використовують терміни, такі як «план даних» проти «плану управління» точно. Неправильне використання цих фраз може призвести до неправильно спрямованих зусиль з усунення несправностей і марного часу. Важливо побудувати спільне розуміння термінології * перед * зануренням у складні конфігурації. Хорошою точкою відліку завжди є запитання: «Чи можете ви пояснити це простішими словами?» - це демонструє повагу до різних рівнів досвіду і допомагає подолати будь-які словникові прогалини.
Іншим прикладом може бути опис нової функції в PR: «Ми використовуємо проксі-сервери Istio Envoy sidecar для реалізації взаємного TLS (mTLS) між нашими мікросервісами, забезпечуючи безпечне спілкування». Розробник, не знайомий з концепцією, може запитати: «Що означає «використання» в цьому контексті? І чому ми використовуємо sidecars? “Термін “збільшення” може звучати надто технічно і не чітко передати переваги. Використання яскравіше формулювання - “Ми використовуємо Envoy як проксі-сервер для безпечного спілкування…” - є більш доступним. Крім того, послідовне посилання на mTLS як «взаємний TLS», а не просто «mtls» (без великої літери «M») покращує читабельність і уникнення потенційної плутанини з іншими технологіями або акронімами.
Зрозуміти ці нюанси не означає запам’ятовувати визначення; це означає розвинути відчуття того, як досвідчені фахівці спілкуються в цій сфері. Це стосується визнання того, що різні люди можуть мати різні рівні знайомства з словником, і відповідно адаптувати свою мову, щоб забезпечити чітке спілкування.
# Example Istio YAML configuration - demonstrating VirtualService usage
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-vs
spec:
hosts:
- "my-app.example.com"
gateways:
- http://ingress-gateway
http:
routes:
- match:
Host:
- my-app.example.com
destination:
host: my-app-service