Чому саме Istio?
Istio вперше представив концепцію сервісної мережі на основі sidecar, коли вона була запущена у 2017 році. З самого початку проєкт включав функції, які стали визначальними для сервісної мережі, включаючи стандартизований mutual TLS для нульової довіри в мережі, розумну маршрутизацію трафіку та спостережуваність через метрики, журнали та трасування.
З того часу проєкт продовжує розвиватися, включаючи мультикластерні та мультимережеві топології, розширюваність через WebAssembly, розробку API Kubernetes Gateway та переведення інфраструктури мережі від розробників застосунків за допомогою режиму оточення.
Ось кілька причин, чому ми вважаємо, що ви повинні використовувати Istio як свою сервісну мережу.
Простота та потужність
Kubernetes має сотні функцій і десятки API, але ви можете почати використовувати його всього лише однією командою. Ми побудували Istio таким же чином. Прогресивне розкриття означає, що ви можете використовувати невелику кількість API та вмикати більш потужні функції тільки за необхідності. Інші “простенькі” сервісні мережі витратили роки, щоб наздогнати функціонал, який Istio мав з першого дня.
Краще мати функцію і не потребувати її, ніж потребувати її та не мати!
Проксі Envoy
З самого початку Istio працював на базі проксі Envoy, високопродуктивного проксі-сервісу, спочатку створеного компанією Lyft. Istio був першим проєктом, який скористався Envoy, і команда Istio була першими зовнішнім контрибʼютором. Envoy згодом став балансувальником навантаження, який підтримує Google Cloud і проксі для майже кожної іншої платформи сервісної мережі.
Istio успадковує всю потужність та гнучкість Envoy, включаючи високий рівень розширюваності за допомогою WebAssembly, яка була додана в Envoy командою Istio.
Спільнота
Istio є справжнім проєктом спільноти. У 2023 році було 10 компаній, які зробили понад 1 000 внесків кожна в Istio, жодна з компаній не перевищила поріг у 25%. (Дивіться цифри тут).
Жоден інший проєкт сервісної мережі не має такої підтримки від індустрії, як Istio.
Пакети
Ми надаємо стабільні бінарні релізи всім, з кожним релізом, і зобовʼязуємося продовжувати це робити. Ми публікуємо безкоштовні та регулярні патчі безпеки для нашого останнього релізу та кількох попередніх релізів. Багато наших постачальників підтримуватимуть старі версії, але ми вважаємо, що залучення постачальника не повинно бути вимогою для безпеки в стабільному відкритому проєкті.
Розглянуті альтернативи
Добрий документ з проєктування включає розділ про альтернативи, які були розглянуті та врешті-решт відхилені.
Чому б не “використовувати eBPF”?
Ми це робимо — де це доречно! Istio можна налаштувати для використання eBPF для маршрутизації трафіку від Podʼів до проксі. Це показує невелике підвищення продуктивності порівняно з використанням iptables.
Чому не використовувати це для всього? Ніхто не робить цього, оскільки ніхто насправді не може.
eBPF — це віртуальна машина, яка працює всередині ядра Linux. Вона була розроблена для функцій, які гарантовано завершуються в обмеженому обчислювальному середовищі, щоб уникнути дестабілізації поведінки ядра, таких як проста маршрутизація трафіку L3 або спостережуваність застосунків. Вона не була розроблена для тривалих або складних функцій, як в Envoy: тому операційні системи мають простір користувача! Супроводжувачі eBPF припустили, що він може бути розширений для підтримки виконання програми такої складності, як Envoy, але це науковий проєкт і малоймовірно, що він матиме практичну значущість у реальному світі.
Інші мережі, які стверджують, що “використовують eBPF”, насправді використовують проксі Envoy для кожного вузла або інші інструменти простору користувача для більшої частини їх функціональності.
Чому не використовувати проксі для кожного вузла?
Envoy не є від природи багатокористувацьким. В результаті, у нас є великі проблеми з безпекою та стабільністю при змішуванні складних правил обробки для трафіку L7 від кількох необмежених користувачів у спільному екземплярі. Оскільки Kubernetes стандартно може розміщувати Podʼи з будь-якого простору імен на будь-якому вузлі, вузол не є відповідною межею розміщення. Бюджетування та атрибуція витрат також є великими проблемами, оскільки обробка L7 коштує набагато більше, ніж L4.
В режимі оточення (ambient) ми строго обмежуємо наш проксі ztunnel до обробки L4 — так само як і ядро Linux. Це значно зменшує площу вразливості та дозволяє нам безпечно експлуатувати спільний компонент. Трафік потім пересилається на проксі Envoy, які працюють по кожному простору імен, так що жоден проксі Envoy ніколи не є багатокористувацьким.
У мене є CNI. Чому мені потрібен Istio?
Сьогодні деякі втулки CNI починають пропонувати функціональність, схожу на сервісну мережу, як надбудову, що розгортається поверх їх власної реалізації CNI. Наприклад, вони можуть реалізувати власні схеми шифрування для трафіку між вузлами або Podʼами, ідентифікацію навантаження або підтримувати деякий рівень політики транспортного рівня, перенаправляючи трафік на проксі L7. Ці надбудови сервісної мережі є нестандартними й, таким чином, можуть працювати лише поверх CNI, що їх надає. Вони також пропонують різні набори функцій. Наприклад, рішення, побудовані на основі Wireguard, не можуть бути сумісними з FIPS.
З цієї причини Istio реалізував компонент нульової довіри (ztunnel), який прозоро та ефективно забезпечує цю функціональність за допомогою перевірених стандартних протоколів шифрування. Дізнайтеся більше про ztunnel.
Istio спроєктовано як сервісну мережу, що забезпечує послідовну, високо захищену, ефективну та відповідну стандартам реалізацію сервісної мережі, що надає могутній набір політик L7, платформонезалежну ідентифікацію навантаження, використовуючи протоколи mTLS, що доведені в індустрії — в будь-якому середовищі, з будь-яким CNI або навіть в кластерах з різними CNI.