Англійська для Istio Service Mesh

Istio додає площину керування на вершині сітки проксі- серверів, і більшість плутанини у обговореннях команди виникає через змішування його об’ єктів маршрутизації вищого рівня з поведінкою проксі- сервера, яку вони налаштовують. Вивчення словника VirtualServices, керування трафіком і mTLS дозволяє вам пояснити інциденти маршрутизації точно, замість того, щоб просто сказати « мережа виглядає дивно »

Ключовий словник

** Sidecar proxy ** — контейнер Envoy автоматично вставляється поруч з кожним модулем програми у мережі, перехоплюючи весь вхідний і вихідний трафік, щоб Istio могло застосовувати маршрутизацію, безпеку і правила телеметрики без зміни коду програми. “Транспорт не доходить до нового підрозділу, оскільки проксі-сервер не був впроваджений — перевірте, чи встановлено позначку впровадження у просторі імен.”

** Розділення трафіку ** — практика маршрутизації відсотка запитів до різних версій служби, визначена декларативно у Istio, а не у логіці програми, зазвичай використовується для розгортання канарських серверів. “Ми використовуємо розділення трафіку, щоб відправити 5% запитів до нової версії — якщо рівень помилок залишиться стабільним, ми поступово збільшимо його.”

** Mutual TLS (mTLS) ** — режим автентифікації, у якому як клієнт, так і сервер, що виконують роль проксі, надають сертифікати для перевірки ідентичності один одного, шифруючи трафік між службами без будь- яких змін коду програми.

• “Ввімкнути взаємний TLS у строгому режимі для цього простору імен, щоб не приймати ніяких потоків звичайного тексту між службами, навіть випадкових.” *

** VirtualService ** — нетиповий ресурс Istio, який визначає, як буде маршрутизовано запити для заданої назви вузла, включаючи правила збігу, значення розділення трафіку, повторні спроби і тайм- аути, розташоване над необробленими налаштуваннями проксі. “Повідомлення 404 надходять від неправильно налаштованої VirtualService — вона відповідає шляху, але маршрутизується до неправильного підмножин.”

** Розрив схеми ** — шаблон стійкості, налаштований за допомогою DestinationRule, який обмежує кількість одночасних з’ єднань або запитів до служби, автоматично викидає непрацездатний екземпляр з пулу балансування навантаження, щоб запобігти каскадним помилкам. “Вийшло з ладу з’єднання і стало відкидати запити до цього під’єднання після того, як воно досягло обмеження на кількість з’єднань - саме тому ми побачили 503 замість повного відключення.”

Звичайні фрази

• Чи справді проксі-сервер sidecar вводиться в цей під, або трафік обходить мережу повністю?»
• Чи можемо ми використовувати розділення трафіку, щоб канарити цей випуск замість повного розгортання?»
• «Чи є взаємний TLS встановлений на строгий або дозволений режим в цьому просторі імен?»
• «Яка VirtualService насправді відповідає цьому шляху запитів?»
• Чи є це дійсно знищенням цієї гілки, чи це просто знищенням цієї гілки?»

Приклади висловлювань

Пояснення інциденту маршрутизації товаришу по команді: “Запити потрапляли до старої версії, тому що VirtualService все ще вказував обидві підмножини на одну і ту ж мітку розгортання — це була не помилка розділення трафіку, а помилка в міткуванні.”

Перегляд налаштувань безпеки:

• “Ми повинні застосовувати взаємний TLS у строгому режимі по всій мережі, а не лише у дозволеному — зараз неправильно налаштований клієнт все ще може надсилати трафік з відкритим текстом.” *

Диагностика відключення в пост-мортному стані:

• “Перерив ланцюга успішно викинув перевантажений модуль, але у нас не вистачало здорових реплік, тому проксі- сервер не мав куди далі направляти запити.” *

Професійні поради

• При обговоренні інциденту скажіть VirtualService замість « конфігурація маршрутизації » — це буде вказувати переглядачам безпосередньо на певний ресурс Istio, який їм слід перевірити.
• Поясніть, що ** розділення трафіку ** є механізмом, що базується на відсотках, коли ви пропонуєте розгортання — це пояснює, що ви маєте на увазі поступове, контролюване виведення, а не миттєве переключення.
• Вкажіть, чи буде ** взаємний TLS ** перебувати у строгому або допусковому режимі під час перевірки безпеки — це розрізнення визначає, чи буде відкидатися простий текстовий трафік, чи буде він просто незашифрованим, але дозволеним.
• Згадуйте ** circuit breaking ** пороги явно при зневадженні неочікуваних 503s — це часто мережа, що захищає систему, а не нова помилка в самій програмі.

Практичні вправи

1. Пояснити, як VirtualService і розділення трафіку працюють разом для реалізації випуску canary.
2. Описати відмінність між допустимим і строгим взаємним TLS, а також пояснити, чому ця відмінність має значення під час перевірки безпеки.
3. Напишіть речення, у якому поясните співробітнику команди, чому переривання мережі призвело до помилки 503, а не до повного відключення.

Наприклад, слово «навигація» означає «навигація з використанням мови»

Будьмо чесними - навіть досвідчені розробники можуть спіткнутися, коли обговорюють складні технології, такі як Istio. Це не просто про те, щоб знати * визначення * таких термінів, як « VirtualService » або « mTLS », але про те, щоб чітко і точно сформулювати ці поняття англійською мовою, особливо коли співпрацювати з колегами, які можуть мати різні рівні технічного розуміння або володіння рідною мовою. Це особливо стосується розробників, які вивчають професійну англійську; тонкість і точне формулювання надзвичайно важливі. Часто просте нерозуміння може призвести до затримок у розгортанні або конфліктів під час перегляду коду. Сфокусування на точному передачі ваших ідей - а не просто на тому, що щось * є * - значно поліпшить спілкування у вашій команді.

Поширений сценарій виникає під час перегляду коду. Ви надіслали запит на звантаження, який змінює правила маршрутизації для служби за допомогою VirtualServices Istio. Ваш рецензент, назовемо його Девідом, залишає коментар: « Ця зміна вводить потенційну нестабільність. Чи можете ви розібратися, як це впливає на споживачів, які знаходяться нижче, і які заходи безпеки є на місці?” Девід не обов’язково критикує ваш код безпосередньо; він шукає роз’яснення щодо впливу ваших змін. Пряма відповідь на кшталт «Я додав деякі розділення трафіку» була б недостатньою. Замість цього, більш ефективним підходом є формулювання його як «Я реалізував маршрутизацію канарій з 10% початкового розділення трафіку до цієї нової версії за допомогою VirtualService, забезпечуючи, що будь-які проблеми будуть негайно вміщені і не вплинуть на більшість користувачів, поки ми моніторимо метрики». Зауважте, як ця відповідь включає конкретні деталі - тип стратегії маршрутизації, відсоток і план моніторингу. Це демонструє, що ви розглянули потенційні ризики і маєте стратегію зменшення ризиків. Аналогічно, в обговореннях Slack, бути точним з термінологією є ключовим. Сказати «Я намагаюся переконатися, що рух рухається правильно» є неясним. Замість цього, «Я налаштовую VirtualService Istio, щоб забезпечити дотримання трафіку визначених правил маршрутизації, заснованих на заголовках HTTP», пропонує набагато більшу ясність.

Крім того, при написанні описів PR, уникайте надто технічного жаргону, який може збентежити інших. Сфокусуйтеся на тому, що ви досягли і чому це важливо з точки зору бізнесу. Наприклад, замість « Реалізовано mTLS для покращення безпеки », спробуйте « Безпечний зв’ язок між Службою А і Службою Б за допомогою взаємного TLS (mTLS) для захисту конфіденційних даних під час передачі — критична вимога для нашої відповідності PCI ». Таке оформлення підкреслює переваги (згідність з PCI) поряд з технічною реалізацією, що робить цей спосіб доступним для більшої кількості користувачів. Навчання впевнено висловлювати ці нюансовані ідеї є ключем до розблокування вашого повного потенціалу у середовищі, що працює на Istio.

istioctl route --virtualservice my-vs -r istio-mesh.yaml

За допомогою цієї команди можна продемонструвати, як ви можете скористатися командою istioctl для перевірки налаштувань VirtualService, підкресливши практичне застосування обговорюваного словника. Це не просто про розуміння * що * команда робить; це про те, щоб бути в змозі описати свою мету і потенційні результати - “Я використовую цю команду, щоб перевірити, що правила маршрутизації, визначені в istio-mesh.yaml, правильно застосовуються до VirtualService з назвою’my-vs’”