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

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

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

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

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

• Можливості NET_ADMIN та NET_RAW: Якщо політики безпеки podʼів застосовані у вашому кластері та якщо ви не використовуєте втулок Istio CNI, ваші podʼи повинні мати дозволені можливості NET_ADMIN та NET_RAW. Контейнери ініціалізації proxy Envoy потребують цих можливостей.

  Щоб перевірити, чи дозволені можливості NET_ADMIN та NET_RAW для ваших podʼів, вам потрібно перевірити, чи може обліковий запис сервісу використовувати політику безпеки podʼів, яка дозволяє можливості NET_ADMIN та NET_RAW. Якщо ви не вказали обліковий запис сервісу в deployment podʼів, podʼи запускаються з використанням службового облікового запису default у просторі імен розгортання.

  Щоб вивести перелік можливостей службового облікового запису, замініть <your namespace> та <your service account> на ваші значення у наступній команді:

  $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

  Наприклад, щоб перевірити службовий обліковий запис default у просторі імен default, виконайте наступну команду:

  $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

  Якщо ви бачите NET_ADMIN та NET_RAW або * у списку можливостей однієї з дозволених політик для вашого облікового запису сервісу, ваші podʼи мають дозвіл на запуск контейнерів ініціалізації Istio. В іншому випадку вам доведеться надати цей дозвіл.

• Мітки 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, маршрутизацію трафіку та телеметрію.

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