Istio — це незалежна від платформи відкрита сервісна мережа, яка забезпечує управління трафіком, виконання політик і збір телеметрії.

Відкрита: Istio розробляється та підтримується як програмне забезпечення з відкритим вихідним кодом. Ми заохочуємо участь та відгуки від спільноти в цілому.

Незалежна від платформи: Проєкт Istio не орієнтований на будь-яке конкретне середовище розгортання. На початкових етапах розробки Istio підтримуватиме розгортання на основі Kubernetes. Однак, Istio створюється для того, щоб забезпечити швидку та легку адаптацію до інших середовищ.

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

Для більш детальної інформації, будь ласка, дивіться Сервісна мережа Istio

Традиційно більшість логіки, яку обробляє Istio, була інтегрована безпосередньо в застосунки. Управління оновленнями цієї логіки звʼязку може бути дуже складним завданням для цілої низки сервісів. Istio надає рішення на рівні інфраструктури для управління комунікаціями між сервісами.

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

Оператори сервісів: Istio дозволяє впроваджувати політики та здійснювати моніторинг мережі з єдиної централізованої точки управління, незалежно від еволюції застосунків. В результаті оператори можуть забезпечити безперервне дотримання політик за допомогою спрощеної системи управління.

Рекомендуємо слідувати інструкціям на сторінці початку роботи, яка встановлює демонстраційну конфігурацію разом з зразком застосунку Istio, Bookinfo. Ви можете використовувати цю установку для перегляду різних посібників Istio, які демонструють розумну маршрутизацію, примусове дотримання політик, безпеку, телеметрію тощо, у формі навчального посібника.

Щоб почати використовувати Istio з промисловими розгортаннями Kubernetes, будь ласка, ознайомтеся з нашими моделями розгортання і сторінкою FAQ який метод установки Istio слід використовувати?.

Istio використовує ліцензію Apache 2.0.

Проєкт Istio був розпочатий командами Google та IBM у партнерстві з командою Envoy від Lyft. Розробка ведеться повністю відкрито на GitHub.

Istio розроблений як платформонезалежний інструмент, спочатку зосереджений на Kubernetes. Для нашого релізу 1.25 Istio підтримує середовища, що працюють на Kubernetes (1.29, 1.30, 1.31, 1.32).

Ваша участь вітається. Ми з нетерпінням чекаємо відгуків, доповнень і повідомлень про помилки від спільноти.

Репозиторії коду розміщені на GitHub. Будь ласка, ознайомтеся з нашими правилами участі, щоб дізнатися, як долучитися.

Окрім коду, існують інші способи долучитися до спільноти Istio, зокрема на нашому форумі, Slack та Stack Overflow.

Ознайомтеся з документацією прямо тут на istio.io. Документація включає огляди концепцій, інструкції по завданням, приклади, та повну довідкову документацію.

Докладна документація для розробників зберігається у нашій Wiki на GitHub.

Ознайомтеся з довідником з операційної діяльності для пошуку рішень та нашою сторінкою для повідомлення про помилки для подання помилок.

Перегляньте нашу сторінку з етапами випуску функцій та новини для отримання останніх новин.

Це грецьке слово ιστίο, яке означає «вітрило».

Якщо ви хочете мати можливість спілкуватися з членами нашої спільноти в реальному часі, ви можете приєднатися до нашого простору Istio в Slack.

Окрім простої початкової установки для оцінки, існує декілька різних методів установки Istio. Який з них слід використовувати, залежить від ваших вимог до продуктивного середовища. Нижче наведені деякі плюси та мінуси кожного з доступних методів:

1. Установка за допомогою istioctl

   Найпростіший і найбільш надійний метод установки та керування з високим рівнем безпеки. Це рекомендований метод для більшості сценаріїв використання спільнотою.

   Переваги:

   • Повна перевірка конфігурації та верифікація стану.
   • Використовує API IstioOperator, який надає широкі можливості конфігурації/кастомізації.

   Недоліки:

   • Необхідно керувати кількома бінарними файлами, по одному для кожної мінорної версії Istio.
   • Команда istioctl може встановлювати значення автоматично на основі вашого робочого середовища, що може призводити до різних установок в різних Kubernetes-середовищах.

2. Установка за допомогою Helm

   Використання Helm-чартів дозволяє легко інтегруватися з робочими процесами на основі Helm і автоматично видаляти ресурси під час оновлень.

   Переваги:

   • Знайомий підхід з використанням стандартних інструментів індустрії.
   • Вбудоване управління релізами та оновленнями Helm.

   Недоліки:

   • Менше перевірок і валідацій порівняно з istioctl install.
   • Деякі адміністративні завдання потребують більше кроків та мають вищу складність.

3. Застосування згенерованого маніфесту Kubernetes

   • Генерація маніфестів Kubernetes за допомогою istioctl
   • Генерація Kubernetes маніфестів за допомогою helm

   Цей метод підходить, коли потрібен суворий аудит або доповнення отриманих маніфестів, або існують обмеження сторонніх інструментів.

   Переваги:

   • Легше інтегрувати з інструментами, які не використовують helm або istioctl.
   • Не потрібні інструменти для установки, окрім kubectl.

   Недоліки:

   • Не виконуються перевірки під час установки, виявлення середовища або валідації, які підтримуються будь-яким з вищезазначених методів.
   • Не підтримується управління установкою або можливість оновлення.
   • Менш зручний інтерфейс користувача.
   • Звітування про помилки під час установки менш надійне.

Інструкції з установки для всіх цих методів доступні на сторінці установки Istio.

Переконайтеся, що ваш кластер відповідає вимогам для автоматичної інʼєкції sidecar. Якщо ваш мікросервіс розгорнутий у просторах імен kube-system, kube-public або istio-system, вони виключені з автоматичної інʼєкції sidecar. Будь ласка, використовуйте інший простір імен.

ztunnel в Istio не вводить єдину точку відмови (SPOF) у кластер Kubernetes. Відмови ztunnel обмежені окремим вузлом, який є вразливим компонентом у кластері. Він поводиться так само як і інша критична інфраструктура вузлів, що працює в кожному кластері, така як ядро Linux, середовище виконання контейнерів тощо. У правильно спроєктованій системі відмови вузлів не призводять до відмови кластера. Дізнайтеся більше.

Ви можете змінити налаштування взаємного TLS для ваших сервісів у будь-який час, використовуючи політику автентифікації та правило призначення. Детальніше дивіться в завданні.

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

Якщо ви встановили Istio з values.global.proxy.privileged=true, ви можете використовувати tcpdump, щоб визначити статус шифрування. Також, з Kubernetes 1.23 і пізніших версій, як альтернатива встановленню Istio як привілейованого сервісу, ви можете використовувати kubectl debug для запуску tcpdump в тимчасовому контейнері. Дивіться міграцію на взаємний TLS в Istio для інструкцій.

Коли включено STRICT режим взаємного TLS, не-Istio робочі навантаження не можуть взаємодіяти з Istio сервісами, оскільки у них не буде відповідного сертифікату клієнта Istio.

Якщо вам потрібно дозволити таким клієнтам доступ, режим взаємного TLS можна налаштувати на PERMISSIVE, що дозволить як незашифровану, так і зашифровану передачу даних. Це можна зробити для окремих робочих навантажень або для всієї мережі.

Дивіться Правила автентифікації для отримання додаткової інформації.

Якщо взаємний TLS увімкнено, перевірки працездатності HTTP та TCP від kubelet не працюватимуть без змін, оскільки kubelet не має сертифікатів, виданих Istio.

Є кілька варіантів:

1. Використання перезапису перевірок для перенаправлення запитів liveness і readiness безпосередньо до сервісу. Дивіться більше інформації в розділі Перезапис перевірок. Ця опція стандартно увімкнена і рекомендована.

2. Використання окремого порту для перевірок працездатності та ввімкнення взаємного TLS лише на звичайному сервісному порті. Докладніше читайте в розділі Перевірка працездатності сервісів Istio.

3. Використання режиму PERMISSIVE для сервісу, щоб він міг приймати як відкритий, так і взаємний TLS трафік. Зверніть увагу, що взаємний TLS не буде примусовим при використанні цієї опції.

Для робочих навантажень, що виконуються в Kubernetes, термін дії їх сертифікатів Istio стандартно становить 24 години.

Цю конфігурацію можна змінити, налаштувавши поле proxyMetadata у конфігурації проксі. Наприклад:

proxyMetadata:
  SECRET_TTL: 48h

Ні. Коли на серверних робочих навантаженнях використовується traffic.sidecar.istio.io/excludeInboundPorts, Istio все одно налаштовує клієнтський Envoy для стандартного надсилання взаємного TLS. Щоб змінити це, потрібно налаштувати правило Destination Rule з режимом взаємного TLS, встановленим на DISABLE, щоб клієнти надсилали звичайний текст на ці порти.

Ви можете зіткнутися з тим, що MySQL не може підключитися після встановлення Istio. Це відбувається через те, що MySQL використовує протокол server first, який може заважати виявленню протоколу Istio. Зокрема, використання режиму PERMISSIVE для mTLS може спричиняти проблеми. Ви можете побачити повідомлення про помилки, такі як ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.

Цю проблему можна вирішити, увімкнувши режим STRICT або DISABLE, або ж налаштувавши всіх клієнтів на надсилання mTLS. Дивіться більше інформації в розділі server first protocols.

Так. Istio надає можливості авторизації як для HTTP, так і для простих TCP сервісів у mesh. Дізнатися більше.

Дотримуючися інструкцій в завданні Захищений трафік Ingress, можна забезпечити безпеку Istio Ingress так, щоб він приймав лише TLS трафік.

Так, можна. Це працює як з увімкненим, так і з вимкненим взаємним TLS.

Ви можете збирати дані телеметрії Istio, використовуючи Prometheus. А потім використовувати HTTP API Prometheus для запитів до цих даних.

Телеметрія у проксі (відомою як v2) знижує використання ресурсів і покращує продуктивність проксі в порівнянні з телеметрією на основі Mixer (відомою як v1) і є переважним механізмом для телеметрії в Istio. Однак є кілька відмінностей у телеметрії між v1 і v2, які наведені нижче:

• Відсутні мітки для трафіку поза мережею Телеметрія у проксі покладається на обмін метаданими між проксі Envoy для збору інформації, такої як імʼя робочого навантаження, простір імен і мітки. У телеметрії на основі Mixer ця функціональність виконувалася Mixer як частина комбінування атрибутів запитів з даними платформи. Цей обмін метаданими виконується проксі Envoy, додаючи конкретний HTTP заголовок для протоколу HTTP або доповнюючи протокол ALPN для протоколу TCP, як описано тут. Такий підхід вимагає, щоб проксі Envoy були впроваджені як у клієнтських, так і в серверних робочих навантаженнях, що передбачає, що телеметрія, що збирається, коли один з партнерів не знаходиться в мережі, буде без атрибутів партнера, таких як імʼя робочого навантаження, простір імен і мітки. Однак, якщо обидва партнери мають впроваджені проксі, всі мітки, згадані тут, доступні в згенерованих метриках. Коли серверне робоче навантаження знаходиться поза мережею, метадані робочого навантаження сервера все ще передаються клієнтському sidecar, що призводить до того, що клієнтські метрики мають заповнені мітки метаданих робочого навантаження сервера.

• Обмін метаданими TCP вимагає mTLS Обмін метаданими TCP покладається на протокол ALPN Istio, який вимагає, щоб mutual TLS (mTLS) був увімкнений для успішного обміну метаданими між проксі Envoy. Це означає, що якщо mTLS не увімкнено у вашому кластері, телеметрія для протоколу TCP не включатиме інформацію про партнера, таку як імʼя робочого навантаження, простір імен і мітки.

• Відсутність механізму для конфігурації власних кошиків для гістограмних метрик Телеметрія на основі Mixer підтримувала налаштування кошиків для метрик типу гістограми, таких як тривалість запиту та розміри байтів TCP. Телеметрія у проксі не має такого механізму. Крім того, кошики для метрик затримки в телеметрії у проксі вимірюються в мілісекундах, в порівнянні з секундами в телеметрії на основі Mixer. Однак, в телеметрії у проксі доступно стандартно більше кошиків для метрик затримки на нижчих рівнях затримки.

• Відсутність термінації метрик для метрик з коротким часом існування Телеметрія на основі Mixer підтримувала термінацію метрик, за якої метрики, що не були згенеровані протягом встановленого часу, були видалені з колекції Prometheus. Це корисно в сценаріях, таких як одноразові завдання, які генерують метрики з коротким часом існування. Видалення метрик запобігає звітуванню про метрики, які більше не змінюватимуться в майбутньому, тим самим зменшуючи мережевий трафік і зберігання в Prometheus. Цей механізм термінації не доступний у телеметрії у проксі. Робоче рішення для цього можна знайти тут.

Метрики з коротким терміном життя можуть впливати на продуктивність Prometheus, оскільки вони часто є великою джерелом кардинальності міток. Кардинальність — це міра кількості унікальних значень для міток. Щоб управляти впливом ваших метрик з коротким терміном життя в Prometheus, спочатку потрібно визначити метрики та мітки з високою кардинальністю. Prometheus надає інформацію про кардинальність на своїй сторінці /status. Додаткову інформацію можна отримати через PromQL. Є кілька способів зменшити кардинальність метрик Istio:

• Вимкніть резервне використання заголовка хосту. Мітка destination_service є одним з потенційних джерел високої кардинальності. Значення для destination_service стандартно використовують заголовок хосту, якщо проксі Istio не може визначити службу призначення з інших метаданих запиту. Якщо клієнти використовують різні заголовки хостів, це може призвести до великої кількості значень для destination_service. В цьому випадку слідуйте керівництву з налаштування метрик, щоб вимкнути резервне використання заголовка хосту на рівні мережі. Щоб вимкнути резервне використання заголовка хосту для конкретного робочого навантаження або простору імен, потрібно скопіювати конфігурацію EnvoyFilter статистики, оновити її, щоб вимкнути резервне використання заголовка хосту, і застосувати її з більш специфічним селектором. Цей тікет має більше деталей про те, як цього досягти.
• Викиньте непотрібні мітки зі збору. Якщо мітка з високою кардинальністю не потрібна, ви можете викинути її зі збору метрик через налаштування метрик за допомогою tags_to_remove.
• Нормалізуйте значення міток, через федерацію або класифікацію. Якщо інформація, надана міткою, потрібна, ви можете використовувати федерацію Prometheus або класифікацію запитів для нормалізації мітки.

Mixer був видалений у випуску Istio 1.8. Міграція необхідна, якщо ви все ще покладаєтеся на вбудовані адаптери Mixer або будь-які зовнішні адаптери для розширення мережі.

Для вбудованих адаптерів надано кілька альтернатив:

• Інтеграції Prometheus і Stackdriver реалізовані як розширення проксі. Налаштування телеметрії, створеної цими двома розширеннями, може бути досягнута через класифікацію запитів та налаштування метрик Prometheus.
• Функціональність глобального та локального обмеження швидкості (memquota і redisquota адаптери) надається через розвʼязання на основі Envoy для обмеження швидкості.
• Адаптер OPA замінений на розвʼязання на основі Envoy ext-authz, яке підтримує інтеграцію з агентом політики OPA.

Для власних зовнішніх адаптерів рекомендується міграція до розширень на основі Wasm. Будь ласка, ознайомтеся з посібниками по розробці модуля Wasm та розповсюдженню розширень. Як тимчасове рішення, ви можете увімкнути підтримку Envoy ext-authz та gRPC доступу до API логів у Mixer, що дозволяє вам оновити Istio до версій після 1.7, одночасно використовуючи 1.7 Mixer з зовнішніми адаптерами. Це дасть вам більше часу для міграції на розширення на основі Wasm. Зверніть увагу, що це тимчасове рішення не протестовано в бойових умовах і навряд чи отримає виправлення помилок, оскільки воно доступне тільки у гілці Istio 1.7, яка вийшла з терміну підтримки після лютого 2021 року.

Ви можете використовувати docker-compose для встановлення Prometheus.

Ви можете включити трейсинг, щоб визначити маршрут запиту в Istio.

Додатково, ви можете використовувати такі команди, щоб дізнатися більше про стан мережі:

• istioctl proxy-config: Отримати інформацію про конфігурацію проксі, коли ви працюєте в Kubernetes:

  # Отримати інформацію про конфігурацію bootstrap для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  Отримати інформацію про конфігурацію кластера для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  Отримати інформацію про конфігурацію прослуховувача для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  Отримати інформацію про конфігурацію маршрутизації для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  Отримати інформацію про конфігурацію точок доступу для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  Спробуйте наступне, щоб дізнатися більше про команди proxy-config
  $ istioctl proxy-config –help

• kubectl get: Отримує інформацію про різні ресурси в мережі разом з конфігурацією маршрутизації:

  # Показати всі віртуальні сервіси
  $ kubectl get virtualservices

Так. Prometheus — це система моніторингу з відкритим кодом та база даних часових рядів. Ви можете використовувати Prometheus з Istio для запису метрик, які відстежують справність Istio та застосунків у сервісній мережі. Ви можете візуалізувати метрики за допомогою інструментів, таких як Grafana та Kiali. Перегляньте Конфігурацію для Prometheus, щоб зрозуміти, як увімкнути збір метрик.

Кілька приміток:

• Якщо pod Prometheus запустився до того, як pod istiod встиг створити необхідні сертифікати та надіслати їх до Prometheus, pod Prometheus потрібно перезапустити, щоб зібрати дані з цілей, захищених взаємним TLS.
• Якщо ваш застосунок надає метрики Prometheus на окремому порту, цей порт слід додати до специфікацій сервісу та розгортання.

Istio інтегрується з системами розподіленого трейсингу, використовуючи Envoy-based трейсинг. Завдяки інтеграції трейсингу на основі Envoy, застосунки відповідають за перенаправлення заголовків трейсів для наступних вихідних запитів.

Додаткову інформацію можна знайти в огляді Розподіленого трейсингу та у документації Envoy щодо трейсів.

Istio дозволяє звітувати про трейс-відрізки (span) для комунікацій між робочими навантаженнями всередині мережі. Проте, щоб різні трейс-відрізки (span) могли бути зшиті разом для повного огляду потоку трафіку, застосунки повинні пропагувати контекст трейсингу між вхідними та вихідними запитами.

Зокрема, Istio покладається на застосунки для пересилання ідентифікатора запиту, згенерованого Envoy, і стандартних заголовків. Ці заголовки включають

• x-request-id

• traceparent

• tracestate

  Користувачі Zipkin повинні переконатися, що вони [поширюють заголовки трейсів B3] (https://github.com/openzipkin/b3-propagation).

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• b3

Розповсюдження заголовків можна виконати за допомогою клієнтських бібліотек, таких як OpenTelemetry. Це також можна зробити вручну, як задокументовано у Задачі розподіленого трасування.

Для інтеграцій трейсингу на основі Envoy, Envoy (sidecar проксі) надсилає інформацію про трейсинг безпосередньо до бекендів трейсингу від імені застосунків, що проходять через проксі.

Envoy:

• генерує ID запитів та заголовки трейсингу (наприклад, X-B3-TraceId) для запитів, коли вони проходять через проксі
• генерує трейс-відрізки (span) для кожного запиту на основі метаданих запиту та відповіді (наприклад, час відповіді)
• надсилає згенеровані трейс-відрізки (span) до бекендів трейсингу
• передає заголовки трейсингу до застосунку, який проходить через проксі

Istio підтримує OpenTelemetry та сумісні бекенди включаючи Jaeger. Серед інших платформ також підтримуються Zipkin та Apache SkyWalking.

Шлюз Istio або додатковий проксі-сервер (Envoy) генерує початкові заголовки, якщо вони не вказані в запиті.

Хоча sidecar Istio обробляє як вхідні, так і вихідні запити для асоційованого екземпляра застосунку, він не має явного способу корелювати вихідні запити з вхідним запитом, який їх спричинив. Єдиний спосіб досягти такої кореляції — це якщо застосунок передає відповідну інформацію (наприклад, заголовки) з вхідного запиту до вихідних запитів. Передача заголовків може бути здійснена через клієнтські бібліотеки або вручну. Подальше обговорення представлено в Що потрібно для розподіленого трейсингу з Istio?.

Швидкість вибірки для трейсингу встановлена в 1% в конфігураційному профілі default. Це означає, що лише 1 зі 100 трейсів, захоплених Istio, буде надіслано до бекенда для трейсингу. Швидкість вибірки в профілі demo все ще встановлена на 100%. Дивіться цей розділ секцію для отримання додаткової інформації про те, як налаштувати швидкість вибірки.

Якщо ви все ще не бачите дані трейсингу, будь ласка, переконайтесь, що ваші порти відповідають конвенціям іменування портів в Istio і що відповідний порт контейнера відкритий (наприклад, через специфікацію podʼа), щоб дозволити захоплення трафіку sidecar проксі (Envoy).

Якщо ви бачите дані трейсингу тільки для egress-проксі, але не для ingress-проксі, це також може бути повʼязано з конвенціями іменування портів.

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

Зараз Istio не підтримує протоколи pub/sub та event bus. Будь-яке використання цих технологій є використанням навмання і може призвести до збоїв в будь-який момент.

Правила можна переглянути за допомогою команди kubectl get virtualservice -o yaml

Стандартно Istio захоплює вхідний трафік на всіх портах. Ви можете змінити цю поведінку, використовуючи анотацію traffic.sidecar.istio.io/includeInboundPorts у podʼі, щоб вказати явний список портів для захоплення, або використовуючи traffic.sidecar.istio.io/excludeOutboundPorts для вказівки списку портів, які потрібно пропустити.

Обидва ці налаштування DestinationRule дозволяють передавати трафік з взаємним TLS. За допомогою ISTIO_MUTUAL сертифікати Istio будуть використовуватися автоматично. Для MUTUAL потрібно налаштувати ключ, сертифікат і довірений CA. Це дозволяє ініціювати взаємний TLS з застосунками, які не є частиною Istio.

Так, Istio повністю підтримує ці типи завантажень починаючи з Istio 1.10.

Прості специфікації ingress, що включають хост, TLS і точні відповідності шляхів, будуть працювати без потреби в правилах маршрутизації. Однак зверніть увагу, що шлях, використаний у ресурсі ingress, не повинен містити символи ..

Наприклад, наступний ресурс ingress відповідає запитам для хосту example.com з URL /helloworld.

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Однак наступні правила не працюватимуть, оскільки вони використовують регулярні вирази в шляху та анотації ingress.kubernetes.io:

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Анотації Ingress, інші, ніж клас Ingress, не будуть враховані
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Після застосування конфігурації CORS ви можете помітити, що ніби нічого не змінилося, і запитати, що пішло не так. CORS є часто неправильно зрозумілим HTTP-концептом, що часто призводить до плутанини при конфігурації.

Щоб зрозуміти це, корисно зробити крок назад і подивитися на що таке CORS і коли його слід використовувати. Стандартно оглядачі мають обмеження на “кросдоменні” запити, ініційовані скриптами. Це заважає, наприклад, вебсайту attack.example.com здійснити JavaScript-запит до bank.example.com і вкрасти чутливу інформацію користувача.

Щоб дозволити цей запит, bank.example.com має дозволити attack.example.com здійснювати кросдоменні запити. Ось де і зʼявляється CORS. Якби ми обслуговували bank.example.com у кластері з увімкненим Istio, ми могли б налаштувати corsPolicy, щоб дозволити це:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

У цьому випадку ми явно дозволяємо один орієнтир; маски часто використовуються для не чутливих сторінок.

Після цього поширена помилка — це надсилання запиту, наприклад curl bank.example.com -H "Origin: https://attack.example.com", і очікування, що запит буде відхилено. Однак curl і багато інших клієнтів не побачать відхилення запиту, оскільки CORS є обмеженням оглядача. Конфігурація CORS просто додає заголовки Access-Control-* у відповідь; клієнт (оглядач) вирішує відхилити запит, якщо відповідь не є задовільною. В оглядачах це робиться за допомогою Preflight запиту.

Наразі Istio підтримує протоколи на основі TCP. Крім того, Istio надає функціональність, таку як маршрутизація та метрики, для інших протоколів, таких як http та mysql.

Для перегляду списку всіх протоколів та інформації про налаштування протоколів перегляньте документацію з Вибору протоколів.