Продуктивність та масштабованість

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

Компоненти панелі даних Istio, проксі Envoy, обробляють дані, що проходять через систему. Компонент панелі управління Istio, Istiod, налаштовує панель даних. Панель даних і панель управління мають окремі питання продуктивності.

Огляд продуктивності для Istio 1.24

Тести навантаження Istio охоплюють 1000 сервісів і 2000 podʼів у mesh Istio з 70 000 запитами в секунду по всій мережі.

Продуктивність панелі управління

Istiod налаштовує sidecar проксі на основі конфігурацій, створених користувачем, і поточного стану системи. У середовищі Kubernetes конфігурацію і стан системи представляють визначення власних ресурсів (CRD) та розгортання. Обʼєкти конфігурації Istio, такі як шлюзи та віртуальні сервіси, є конфігурацією, створеною користувачем. Щоб створити конфігурацію для проксі, Istiod обробляє комбінацію конфігурацій і стану системи з середовища Kubernetes і створеної користувачем конфігурації.

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

• Швидкість змін розгортання.
• Швидкість змін конфігурації.
• Кількість проксі, що підключаються до Istiod.

Однак, ця частина може масштабуватися горизонтально.

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

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

Продуктивність панелі даних

Продуктивність панелі даних залежить від багатьох факторів, наприклад:

• Кількість клієнтських підключень
• Потрібна швидкість запитів
• Розмір запиту та розмір відповіді
• Кількість робочих потоків проксі
• Протокол
• Процесорні ядра
• Різні функції проксі. Зокрема, фільтри телеметрії (логування, трасування та метрики) мають помірний вплив.

Затримки, пропускна здатність та споживання процесора і памʼяті проксі вимірюються як функція зазначених факторів.

Використання ресурсів sidecarʼом та ztunnel

Оскільки sidecar проксі виконує додаткову роботу на шляху даних, він споживає ресурси процесора та памʼять. В Istio 1.24, при 1000 http-запитів на секунду, що містять 1 КБ корисного навантаження:

• один проксі з двома робочими потоками споживає близько 0,20 vCPU і 60 МБ памʼяті.
• один проксі waypoint з 2 робочими потоками споживає близько 0,25 vCPU і 60 МБ памʼяті
• один ztunnel-проксі споживає близько 0,06 vCPU і 12 МБ памʼяті.

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

Затримка

Оскільки Istio додає sidecar проксі чи ztunnel на шляху даних, затримка є важливим фактором. Кожна функція, яку додає Istio, також додає до довжини шляху всередині проксі та потенційно впливає на затримку.

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

Затримка для Istio 1.24

В режимі sidecar запит пройде через клієнтський проксі-сервер, а потім через серверний проксі-сервер, перш ніж потрапить на сервер, і навпаки. В режимі ambient запит пройде через клієнтський вузол ztunnel, а потім через серверний вузол ztunnel, перш ніж потрапить на сервер. При налаштованих маршрутних точках запит буде проходити через проксі-маршрутизатор між ztunnel’ами. На наступних графіках показано затримки P90 і P99 для запитів http/1.1, що проходять через різні режими панелі даних. Для проведення тестів ми використовували пустий кластер з 5 машин M3 Large та Flannel як основний CNI. Ми отримали ці результати за допомогою Istio benchmarks для протоколу http/1.1 з корисним навантаженням 1 КБ при 500, 750, 1000, 1250 і 1500 запитах на секунду з використанням 4 клієнтських зʼєднань, 2 робочих проксі-серверів і включеним взаємним TLS.

Примітка: Це тестування було виконано у CNCF Community Infrastructure Lab. Різне апаратне забезпечення може давати різні значення.

• no mesh: Клієнтський pod напряму викликає серверний pod, жодних podʼів у сервісній мережі Istio.
• ambient: L4: Стандартний режим оточення з захищеним L4 Overlay
• ambient: L4+L7: Стандартний режим оточення із захищеним L4 Overlay та ввімкненими waypoints для простору імен.
• sidecar: Клієнтські та серверні sidecarʼи.

Інструменти для тестування

Istio використовує такі інструменти для тестування:

• fortio.org — інструмент для тестування навантаження з постійною пропускною здатністю.
• nighthawk — інструмент для тестування навантаження, заснований на Envoy.
• isotope — синтетичний застосунок із налаштовуваною топологією.