Продуктивність ambient у мультикластері
Мультикластерні розгортання з режимом ambient дозволяють пропонувати справді глобально стійкі застосунки в масштабі з мінімальними накладними витратами. Окрім своїх звичайних функцій, панель управління Istio створює спостереження (watch) за всіма віддаленими кластерами, щоб підтримувати актуальний перелік глобальних сервісів, які пропонує кожен кластер. Панель даних Istio може маршрутизувати трафік до цих віддалених глобальних сервісів — або як частину звичайного розподілу трафіку, або спеціально, коли локальний сервіс недоступний.
Продуктивність панелі управління
Як задокументовано тут, панель управління Istio загалом масштабується як добуток змін розгортання, змін конфігурації та кількості підключених проксі. Ambient у мультикластері додає два нові виміри до історії масштабованості панелі управління: кількість віддалених кластерів і кількість віддалених сервісів. Оскільки панель управління не програмує проксі для віддалених кластерів (припускаючи топологію розгортання з кількома основними екземплярами), додавання 10 віддалених сервісів до мережі має значно менший вплив на продуктивність панелі управління, ніж додавання 10 локальних сервісів.
Наш тест навантаження мультикластерної панелі управління створив 300 сервісів із 4000 точок доступу у кожному з 10 кластерів і додавав ці кластери до мережі по одному. Приблизний вплив на панель управління від додавання віддаленого кластера в такому масштабі становив 1% ядра ЦП і 180 МБ памʼяті. У такому масштабі має бути безпечно масштабуватися значно далі 10 кластерів у мережі з належно масштабованою панеллю управління. Слід зазначити, що для масштабованості мультикластера горизонтальне масштабування панелі управління не допоможе, оскільки кожен екземпляр панелі управління підтримує повний кеш віддалених сервісів. Натомість ми рекомендуємо змінювати запити та ліміти ресурсів панелі управління для вертикального масштабування відповідно до потреб вашої мультикластерної мережі.
Продуктивність панелі даних
Коли трафік маршрутизується до віддаленого кластера, вихідна панель даних встановлює зашифрований тунель до шлюзу східн-захід кластера призначення. Потім вона встановлює вторинний зашифрований тунель усередині першого, який завершується на панелі даних призначення. Таке використання внутрішнього та зовнішнього тунелів дозволяє панелі даних безпечно спілкуватися з віддаленим кластером, не знаючи деталей того, які IP-адреси podʼів відповідають яким сервісам.
Однак подвійне шифрування має певні накладні витрати. Тест навантаження панелі даних вимірює затримку відповіді трафіку між podʼами в одному кластері порівняно з podʼами у двох різних кластерах, щоб зрозуміти вплив подвійного шифрування на затримку. Крім того, подвійне шифрування потребує подвійного рукостискання, що непропорційно впливає на затримку нових зʼєднань із віддаленим кластером. Як ви можете бачити нижче, наші початкові зʼєднання спостерігали в середньому 2,2 мілісекунди (346%) додаткової затримки, тоді як запити з використанням наявних зʼєднань показали збільшення на 0,13 мілісекунди (72%). Хоча ці цифри можуть здаватися значними, очікується, що більшість мультикластерного трафіку перетинатиме зони доступності або регіони, і спостережуване збільшення накладних затримок буде мінімальним порівняно із загальною затримкою транзиту між центрами обробки даних.
