Вимоги до застосунку

Istio надає широкі функціональні можливості застосункам з мінімальним або взагалі без впливу на код самого застосунку. Багато застосунків у Kubernetes можуть бути розгорнуті в кластері з підтримкою Istio без жодних змін. Однак, є деякі особливості моделі sidecar в Istio, які можуть потребувати спеціальної уваги при розгортанні застосунку з підтримкою Istio. Цей документ описує ці особливості та специфічні вимоги до застосунків з підтримкою Istio.

Вимоги до podʼів

Щоб бути частиною mesh, podʼи в Kubernetes повинні відповідати таким вимогам:

• UID застосунку: Переконайтеся, що ваші podʼи не запускають застосунки від імені користувача з ідентифікатором користувача (UID) зі значенням 1337, оскільки 1337 зарезервований для sidecar proxy.

• Можливості NET_ADMIN та NET_RAW: Якщо ви не використовуєте втулок Istio CNI, контейнер istio-init потребує можливостей NET_ADMIN та NET_RAW для налаштування перенаправлення трафіку iptables. Простір імен повинен використовувати рівень примусового застосування privileged Pod Security Admission. Рівні baseline та restricted блокують ці можливості та перешкоджатимуть запуску контейнера istio-init.

  Щоб перевірити мітку pod-security.kubernetes.io/enforce на просторі імен:

  $ kubectl get namespace <your namespace> --show-labels
  NAME       STATUS   AGE   LABELS
  myapp      Active   3d    pod-security.kubernetes.io/enforce=privileged,...

  Щоб встановити для простору імен примусове застосування privileged:

  $ kubectl label namespace <your namespace> pod-security.kubernetes.io/enforce=privileged --overwrite

  Якщо ваша політика безпеки не дозволяє примусове застосування privileged у просторі імен, натомість використовуйте втулок Istio CNI, який виконує перенаправлення трафіку без необхідності підвищених можливостей у podʼі.

• Мітки podʼів: Рекомендуємо явно оголошувати podʼи з ідентифікатором застосунку та версією, використовуючи мітку podʼа. Ці мітки додають контекстну інформацію до метрик та телеметрії, які збирає Istio. Кожне з цих значень зчитується з кількох міток, впорядкованих від найвищого до найнижчого пріоритету:

  • Назва застосунку: service.istio.io/canonical-name, app.kubernetes.io/name або app.
  • Версія застосунку: service.istio.io/canonical-revision, app.kubernetes.io/version або version.

• Іменовані порти сервісу: Порти сервісу можуть бути опціонально названі для явного зазначення протоколу. Дивіться Вибір протоколу для отримання додаткової інформації. Якщо pod належить до кількох сервісів Kubernetes, сервіси не можуть використовувати той самий номер порту для різних протоколів, наприклад HTTP і TCP.

Порти, які використовує Istio

Наступні порти та протоколи використовуються проксі sidecar (Envoy) в Istio.

Наступні порти та протоколи використовуються панеллю управління Istio (istiod).

Протоколи “Server First”

Деякі протоколи є протоколами “Server First”, що означає, що сервер надсилає перші байти. Це може вплинути на PERMISSIVE mTLS та Автоматичний вибір протоколу.

Обидві ці функції працюють шляхом перевірки початкових байтів зʼєднання для визначення протоколу, що є несумісним з протоколами “Server First”.

Щоб підтримати ці випадки, дотримуйтесь кроків Явного вибору протоколу, щоб оголосити протокол застосунку як TCP.

Нижче наведені порти, які зазвичай використовують протоколи “Server First”, і автоматично вважаються TCP:

Оскільки TLS-комунікація не є “Server First”, TLS-зашифрований трафік “Server First” працюватиме з автоматичним визначенням протоколу, якщо ви переконаєтеся, що весь трафік, що підлягає TLS-скануванню, зашифрований:

1. Налаштуйте режим mTLS як STRICT для сервера. Це забезпечить TLS-шифрування для всіх запитів.
2. Налаштуйте режим mTLS як DISABLE для сервера. Це відключить TLS-сканування, дозволяючи використовувати протоколи “Server First”.
3. Налаштуйте всі клієнти для надсилання трафіку TLS, зазвичай через DestinationRule або покладаючись на авто mTLS.
4. Налаштуйте ваш застосунок для прямого надсилання трафіку TLS.

Вихідний трафік

Щоб підтримувати можливості маршрутизації трафіку Istio, трафік, що виходить з контейнера, може маршрутизуватися інакше, ніж коли sidecar не розгорнуто.

Для трафіку на основі HTTP маршрутизація базується на заголовку Host. Це може призвести до непередбачуваної поведінки, якщо IP-адреса призначення та заголовок Host не узгоджені. Наприклад, запит типу curl 1.2.3.4 -H "Host: httpbin.default" буде маршрутизовано до сервісу httpbin, а не до 1.2.3.4.

Для не HTTP-трафіку (включаючи HTTPS) Istio не має доступу до заголовка Host, тому рішення про маршрутизацію базуються на IP-адресі сервісу.

Одним з наслідків цього є те, що прямі виклики до контейнерів (наприклад, curl <POD_IP>), а не до сервісів, не будуть збігатись. Хоча трафік може бути пропущений, він не отримає повну функціональність Istio, включаючи шифрування mTLS, маршрутизацію трафіку та телеметрію.

Дивіться сторінку Маршрутизація трафіку для отримання додаткової інформації.