Service Mesh & Istio Vocabulary: 25 Terms for Cloud-Native Engineers (англійською)
Проксі Sidecar, рівень управління/даних, управління трафіком, mTLS і словник Istio/Linkerd для інженерів платформи.
Якщо ви працюєте в команді платформи Kubernetes або нещодавно приєдналися до організації, що працює в хмарі, ви майже напевно чули такі фрази, як « ми розгортаємо Istio » або « давайте застосуємо mTLS по всій мережі ». Технологія мережі послуг стала основою сучасної архітектури мікросервісів, проте словник, що її оточує, може здатися непроникним — особливо для інженерів, чия перша мова не є англійською. У цій статті розглянуто 25 основних термінів, пов’ язаних з мережею служб і Istio, щоб ви могли стежити за обговореннями архітектури, читати пост- смертні повідомлення про інциденти і безпечно брати участь у перегляді дизайну.
Основні поняття: Що таке сервісна мережа?
** Сервісна мережа ** — виділений шар інфраструктури, який обробляє обмін даними між службами в рамках розподіленої програми. Замість того, щоб випікати мережеву логіку (повторні спроби, тайм- аути, безпека) в кожній службі, сітка переносить цю відповідальність на окремий шар, який працює прозоро.
«Ми дублювали логіку повторних спроб у кожній мікросервісі. Перехід до мережі послуг дозволяє нам централізувати цю поведінку і послідовно її застосовувати»
Команда безопасности попросила нас зашифровать весь внутренний трафик. Сервісна мережа зробила це простим без торкання коду програми»
** Sidecar proxy (Envoy) ** — невеликий мережевий проксі- контейнер, який буде автоматично вставлено разом з кожним службовим контейнером у підконтейнері. Він перехоплює весь вхідний і вихідний трафік від імені програми. Envoy є найпоширенішим проксі-сервером, прийнятим як Istio, так і кількома іншими мережами.
«Проксі-сервер sidecar є тим, що дає мережі її видимість — кожен запит проходить через нього, тому ми отримуємо метрики безкоштовно»
“Посол справляється з важкими вантажами: балансування навантаження, перевірка здоров’я, відстеження. Сама програма не повинна знати, що щось з цього існує»
** Площина керування ** — рівень керування мережі служб. Він відповідає за налаштування проксі-серверів sidecar, розповсюдження правил і збір телеметричних даних. У Istio компонент керування площиною називається istiod.
“Істиод - наш контрольний план. Він відсилає правила маршрутизації до кожного Envoy sidecar по кластеру»
Якщо керуюча площина йде вниз, площина даних продовжує працювати — проксі працюють на їх останній відомій конфігурації
** Площина даних ** — набір проксі- серверів, які обробляють мережевий трафік під час виконання. У той час як керуюча площина вирішує * що * правила є, площина даних * накладає * їх на кожен окремий запит.
“Ми оптимізуємо площину даних для пропускної здатності. Контрольна площина менш чутлива до затримки»
«Подумайте про це так: контрольна площина — це мозок, а інформаційна площина — це руки»
Istio — мережа послуг з відкритим кодом, спочатку розроблена Google, IBM і Lyft. Це найбільш широко прийнята мережа в середовищі Kubernetes підприємства і використовує Envoy як проксі-сервер для планети даних.
«Ми обрали Istio через його багаті функції управління трафіком і розмір його спільноти»
«Istio має більш стриману криву навчання, ніж Linkerd, але гнучкість, яку він пропонує, варто того для нашого випадку використання»
** Linkerd ** — легка, CNCF- ступенева мережа служб, зосереджена на простоті і низьких витратах ресурсів. Він використовує мікро-проксі на основі Rust замість Envoy.
«Ми оцінювали як Istio, так і Linkerd. Linkerd переміг для нас через свою простішу операційну модель і менші розміри»
Автоматичний mTLS Linkerd був функцією, яка продала команду безпеки
Безпека: шифрування і автентифікація трафіку
** mTLS (mutual TLS) ** — протокол безпеки, за якого * як клієнт, так і сервер надають сертифікати для перевірки своєї ідентичності, на відміну від стандартного TLS, за якого розпізнається лише сервер. Сервісна мережа може автоматично застосовувати mTLS у всіх службах без будь-яких змін коду.
«З mTLS, пошкоджена служба не може імітувати іншу — кожне з’єднання автентифікується на обох кінцях»
“Ми ввімкнули строгий режим mTLS в нашій мережі. Тепер будь-який незашифрований трафік відкидається на рівні проксі.”
** PeerAuthentication ** — нетиповий ресурс Istio, який визначає, як служба приймає з’ єднання. Встановлення його в режим STRICT означає, що приймається тільки mTLS-трафік; PERMISSIVE дозволяє як простий текст, так і mTLS під час періодів міграції.
«Ми встановили PeerAuthentication на PERMISSIVE, поки ми вводили старі послуги, а потім переключилися на STRICT, як тільки все було зареєстровано»
«Політика PeerAuthentication в кореневому просторі імен застосовується в мережі — будьте обережні, коли змінюєте її»
** AuthorizationPolicy ** — ресурс Istio, який керує тим, які служби мають право спілкуватися між собою. Він діє як дрібнозернистий брандмауер, що працює на рівні програм.
«Ми використовуємо AuthorizationPolicy, щоб переконатися, що платіжна служба може бути викликана тільки службою оплати, нічого іншого»
«Нульова довіра мережі в сіті по суті є AuthorizationPolicy застосовується всюди.»
Керування трафіком: контроль за потоком запитів
** Керування трафіком ** — можливість керування маршрутизацією запитів між службами. Межа дозволяє застосовувати складні правила маршрутизації, засновані на заголовках HTTP, вагах, ідентифікації користувача або інших критеріях — без розгортання нового коду.
“Менеджмент руху в Istio - це те, що дозволило нам випустити канарку. Ми пересунули 5% трафіку до нової версії і спостерігали за кількістю помилок перед затвердженням»
«Команда продукту попросила про функціональний прапорець, який направляє бета-користувачів до нового інтерфейсу користувача. Ми реалізували його як правило управління трафіком в mesh, а не в коді програми»
** VirtualService ** — нетиповий ресурс Istio, який визначає правила маршрутизації для трафіку, призначеного для певної служби. Цей параметр вказує Envoy * куди* надсилати запити на основі таких умов, як префікс URI, заголовки HTTP або навантаження на джерело.
«VirtualService є місцем, де я визначаю мою логіку маршрутизації — 90% до v1, 10% до v2»
«Ми використовуємо VirtualService з маршрутизацією на основі заголовків, тому QA може тестувати новий сервіс без впливу на виробничих користувачів»
** DestinationRule ** — нетиповий ресурс Istio, який визначає * як* обробляти трафік після його прибуття до місця призначення, включаючи стратегію балансування навантаження, параметри пулів з’ єднань і виявлення відхилень. Він працює в тандемі з VirtualService.
«DestinationRule є місцем, де ви налаштовуєте підмножини — він позначає, які підмножини є v1 і які є v2.»
«Ми налаштували параметри з’єднання в нашому DestinationRule після того, як побачили виснаження з’єднання під навантаженням»
** Пересування трафіку ** — поступове пересування відсотка поточного трафіку з однієї версії служби на іншу. Це технічний механізм за канарськими розгортаннями і синім / зеленим розгортанням у сітківці.
«Ми робимо перенесення трафіку, а не випуски великого вибуху зараз. Починайте з 1%, дивіться на золоті сигнали, збільшуйте, якщо стабільно»
«Перенесення трафіку через мережу є безпечнішим, ніж підходи, засновані на DNS, тому що ви можете негайно повернутись, оновлюючи VirtualService.»
** Circuit breaker (у мережі) ** — шаблон, який припиняє надсилання запитів до непрацездатного екземпляра служби, якщо перевищується поріг помилок або затримки. У Istio поведінку при розриві схеми налаштовується за допомогою параметрів виявлення відхилень у DestinationRule.
“Виявлення відхилень в нашому DestinationRule викидає будь-який вузол, який повертає п’ять послідовних помилок 5xx. Це наш перемикач»
«Без автоматичного перемикачів, повільна служба вниз по течії може призвести до каскаду збоїв по всьому графі виклику»
** Повторні спроби ** — автоматичне перенаправлення невдалого запиту вказану кількість разів перед поверненням повідомлення про помилку викликаючому. У Istio поведінку повторення спроб визначено у VirtualService.
“Ми встановили повтори на 3 з інтервалом повторів 25 мс для наших кінцевих точок читання. Перехідні мережеві бліпи більше не виникають як помилки»
«Будьте обережні з повторними спробами на не-ідемонтів операціях — повторна спроба запиту на платіж не те саме, що повторна спроба пошуку продукту»
** Тайм- аут (у мережі) ** — максимальний час очікування запиту на відповідь, після якого мережа поверне повідомлення про помилку викликаючому. Якщо налаштувати цей параметр у VirtualService, він запобігатиме повільним службам від тривалого зберігання відкритих з’ єднань.
“Ми встановили тайм-аут 500 мс на всі виклики до сервісу рекомендацій. Якщо це повільно, ми повертаємося до типового списку, а не блокуємо користувача»
«Тайм-аут в сіті впроваджується незалежно від того, який є тайм-аут самої програми — виграє той, хто коротший»
Спостережливість: бачити те, що бачить мережа
** Спостережливість (золоті сигнали через сітку) ** — здатність розуміти внутрішній стан системи, вивчаючи її виходи. Мережа служб автоматично надає чотири золоті сигнали — затримку, трафік, помилки і насиченість — для кожної служби, оскільки весь трафік проходить через проксі- сервери.
«До мережі, отримання RED-метрики (Швидкість, помилки, тривалість) означало інструментування кожної служби окремо. Тепер ми отримуємо їх безкоштовно»
«Спостережливість на рівні сітки була першою річчю, яку я показав інженерному директору — повний графік обслуговування з розривами затримки, не потрібно змінювати код»
** Розподілене відстеження ** — відстеження окремого запиту під час його поширення за допомогою декількох служб, збирання хронології кожного переходу. Istio інтегрується з трасерами, такими як Jaeger і Zipkin, вводячи контекст трасерів в проксі-сервери.
«Ми знайшли 200-мс пік затримки, використовуючи розподілене відстеження — це був запит бази даних в службі, яку ми не підозрювали»
«Istio обробляє поширення сліду на проксі-рівні, але послуги повинні пересувати заголовки B3 для того, щоб слід був повним.»
** Графік служб ** — візуальне представлення того, які служби спілкуються з іншими службами, отримане за допомогою мережевої телеметрики. Інструменти, такі як Kiali, відображають графік служби Istio в реальному часі.
«Граф сервісу в Kiali відразу ж показав нам кругову залежність, яку ми не задокументували»
«Під час інциденту, графік обслуговування зробив очевидним, який нижній сервіс був причиною каскаду»
** Телеметрия ** — збірка метрик, журналів і слідів, що випромінюється мережею. Istio можна налаштувати для експорту телеметричних даних до Prometheus, Grafana, Jaeger та інших платформ спостереження.
«Ми налаштували телеметрию Istio, щоб випускати нетипові метричні дані для наших панелей SLO»
«Телеметрия з мережі знаходиться на рівні L7 — ви бачите коди стану HTTP, часи відповіді, шляхи запитів»
Як використовувати ці терміни в розмові
Зрозуміти словниковий запас — це лише половина справи — вам також потрібно використовувати його природно. Ось чотири реалістичні сценарії з прикладними фразами.
** Сценарій 1 — Перегляд архітектури **
“Ми пропонуємо прийняти Istio як нашу мережу сервісів. Контрольна плата буде працювати як istiod, і Envoy sidecars буде автоматично введено в кожну капсулу. Ми будемо застосовувати строгий mTLS по всій мережі з першого дня і використовувати VirtualServices для переміщення трафіку під час випуску канарських версій»
Сценарий 2 - пост-мёртвый инцидент
“Коренева причина була відсутністю автоматичного вимкнення в DestinationRule для служби інвентарізації. Коли запаси стали повільними, повторні спроби збільшили навантаження. Додавши виявлення відхилень з 30-секундним інтервалом викидання, можна було б автоматично ізолювати погані вузли»
** Сценарій 3 — Обговорення безпеки **
“Наша модель загрози вимагає взаємної автентифікації між всіма внутрішніми службами. Мережа обробляє це прозоро через mTLS — службам не потрібно керувати сертифікатами самостійно. Ми використаємо PeerAuthentication в режимі STRICT і AuthorizationPolicy для забезпечення найменш привілейованого зв’язку»
** Сценарій 4 — Введення нового члена команди **
«Мисліть про сітку як про два шари: площина даних - це всі Envoy sidecars, що працюють поряд з вашими контейнерами - вони обробляють кожен байт трафіку. Площина керування — це istiod, за допомогою якої можна налаштувати ці додаткові машини на основі нетипових ресурсів Istio, які ви застосовуєте до кластера. Як тільки ви зрозумієте це розділення, решта Istio має набагато більше сенсу»
Таблиця швидких посилань
| Term | What it does | Where configured |
|---|---|---|
| Service mesh | Handles service-to-service networking transparently | Infrastructure layer |
| Sidecar proxy (Envoy) | Intercepts and processes all pod traffic | Injected automatically |
| Control plane (istiod) | Configures and manages sidecar proxies | Kubernetes control plane |
| Data plane | Enforces routing/security rules on live traffic | Each pod’s sidecar |
| mTLS | Mutual certificate authentication for service traffic | PeerAuthentication |
| VirtualService | Defines routing rules (weights, headers, subsets) | Namespace / cluster |
| DestinationRule | Configures load balancing, connection pools, outlier detection | Namespace / cluster |
| Traffic shifting | Gradual percentage-based canary routing | VirtualService weights |
| Circuit breaker | Ejects unhealthy hosts after error threshold | DestinationRule outlier detection |
| Timeout | Max wait time before mesh returns an error | VirtualService |
Завдяки цьому словнику ви зможете безпечно брати участь у обговореннях з інженерії платформи, писати більш зрозумілі підручники з програмування і ефективніше співпрацювати з командами SRE і безпеки. Наступного разу, коли хтось згадує « перенесення трафіку за допомогою VirtualService » або « збільшення порогів виявлення відхилень », ви точно знатимете, що вони мають на увазі — і які питання вам слід задати.