Istio: Найвища продуктивність для мережевої безпеки

Режим Ambient забезпечує більше зашифрованої пропускної здатності, ніж будь-який інший проєкт в екосистемі Kubernetes.

Mar 6, 2025 | Від Джон Говард - Solo.io

Шифрування під час передачі є базовою вимогою для майже всіх середовищ Kubernetes сьогодні і створює основу для безпеки з нульовою довірою.

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

Хоча більшість користувачів Cloud Native знають Istio як сервісну мережу, що забезпечує розширену функціональність HTTP, вона також може виконувати роль основного шару мережевої безпеки. Коли ми почали створювати режим ambient в Istio, ці два шари були явно розділені. Однією з наших основних цілей було забезпечити безпеку (і довгий список інших функцій) без компромісів.

З режимом ambient, Istio тепер є способом створення безпечної мережі з нульовою довірою в Kubernetes з найвищою пропускною здатністю.

Подивімось на деякі результати перед тим, як заглибитися в те, як і чому.

Перевірка на практиці

Для тестування продуктивності ми використовували стандартний інструмент для тестування мережі, iperf, щоб виміряти пропускну здатність TCP-трафіку через різні популярні рішення для мережевої безпеки Kubernetes.

Продуктивність різних рішень для мережевої безпеки.

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

Продуктивність Istio забезпечується ztunnel, спеціально створеною панеллю даних, яка є легкою, швидкою та безпечною. За останні 4 випуски продуктивність Ztunnel покращилася на 75%!

Деталі тестування

Реалізації, що тестуються:

Istio: версія 1.26 (передреліз), стандартні налаштування
Linkerd: версія edge-25.2.2, стандартні налаштування
Cilium: версія v1.16.6 з kubeProxyReplacement=true
- WireGuard використовує encryption.type=wireguard
- IPsec використовує encryption.type=ipsec з алгоритмом GCM-128-AES
- Крім того, обидва режими були протестовані з усіма рекомендаціями в посібнику з налаштування продуктивності Cilium (включаючи netkit, native режим маршрутизації, BIGTCP (для WireGuard; IPsec несумісний), BPF masquerade та BBR bandwidth manager). Однак результати були однаковими з цими налаштуваннями та без них, тому повідомляється лише один результат.
Calico: версія v3.29.2 з calicoNetwork.linuxDataplane=BPF та wireguardEnabled=true
Kindnet: версія v1.8.5 з --ipsec-overlay=true.

Деякі реалізації шифрують трафік лише між вузлами, тому виключені з тестів на одному вузлі.

Тести проводилися на одному зʼєднанні iperf (iperf3 -c iperf-server), усереднюючи результат 3 послідовних запусків. Тести проводилися на 16-ядерних x86 машинах під керуванням Linux 6.13. З різних причин жодна реалізація не використовує більше ніж 1-2 ядра при обробці одного зʼєднання, тому кількість ядер не є вузьким місцем.

Примітка: багато з цих реалізацій підтримують HTTP-контроль. Цей тест не перевіряє цю функціональність у жодній реалізації. Попередні пости зосереджувалися на цій області Istio.

Випереджаючи ядро

Дуже поширене сприйняття в продуктивності мережі полягає в тому, що виконання всього в ядрі, або нативно, або за допомогою розширень eBPF, є оптимальним способом досягнення високої продуктивності. Однак ці результати показують протилежний ефект: реалізації в просторі користувача (Linkerd та Istio) значно перевершують реалізації в просторі ядра. Що ж відбувається?

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

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

Перехід на rustls, високопродуктивну бібліотеку TLS, що фокусується на безпеці (#820).
Зменшення копіювання даних на вихідному трафіку (#1012).
Динамічне налаштування розмірів буферів активних з’єднань (#1024).
Оптимізація копіювання памʼяті (#1169).
Перехід на криптографічну бібліотеку AWS-LC, високопродуктивну криптографічну бібліотеку, оптимізовану для сучасного апаратного забезпечення (#1466).

Деякі інші фактори включають:

WireGuard та Linkerd використовують алгоритм шифрування ChaCha20-Poly1305, тоді як Istio використовує AES-GCM. Останній високо оптимізований для сучасного апаратного забезпечення.
WireGuard та IPsec працюють з окремими пакетами (зазвичай не більше 1500 байт, обмежених мережею MTU), тоді як TLS працює з записами до 16KB.

Спробуйте режим ambient сьогодні

Якщо ви хочете підвищити безпеку вашого кластера без компромісів у складності або продуктивності, зараз ідеальний час, щоб спробувати режим ambient Istio!

Слідуйте посібнику з початку роботи, щоб дізнатися, як легко його встановити та увімкнути.

Ви можете спілкуватися з розробниками в каналі #ambient на Slack Istio або використовувати форум обговорень на GitHub для будь-яких питань, які у вас можуть виникнути.