Дякую за питання! З нашого досвіду, протягом усього часу використання Istio в наших кластерах, проблем з тротлінгом не виникало. На різних середовищах значення ресурсів можуть відрізнятися. В нашому випадку на дев серидовищі (як в статті) Ztunnel зазвичай навантажений до 30% по CPU та пам’яті. Istio CNI в свою чергу споживає незначну кількість CPU після старту пода (1-5%), а по пам’яті досягає максимуму до 60%.
Ці дані свідчать про те, що налаштовані ресурси достатні для забезпечення стабільної роботи без суттєвого впливу на летенсі. Проте, у кожному випадку треба підбирати індивідуальні значееня й якщо у вас є специфічні вимоги або спостерігаються відхилення, завжди корисно періодично переглядати і коригувати ресурси відповідно до навантаження.

Дякую за коментар! Наша команда обрала Istio через його широкий набір можливостей і розширюваність, що дозволяє використовувати його як універсальний інструмент для управління трафіком у складних мікросервісних архітектурах, також Istio проявив себе надійним інструментом й в інших проектах. Окрім mTLS та балансування, також використовуємо такі фічі як rate limiting, authorization & authentication policies й редірект трафіку

Дякую за коментар і корисну підказку! Це виглядає як цікаве рішення, яке допоможе зекономити час і зменшити кількість ручних дій. Обов’язково вивчу це питання глибше.

Наразі ми співпрацюємо з Амазоном, оскільки маємо отримали спеціальні умови, такі як знижки та кредити, а використовуємо тільки AAD (нова назва — Microsoft Entra ID) в Ажурі. Взагалі є можливість використовувати будь-який Identity Provider (IdP), підключення буде виглядати схожим чином

У нашому проекті нам пощастило використовувати мову програмування Python на бекенді, що призвело до відсутності проблем у цьому компоненті системи. Однак у фронтенд-додатках, розроблених на React, були внесені певні зміни, а саме заміни багатьох бібліотек на ті, які є сумісними з АРМ. Щодо продуктивності, ми не виявили суттєвого втрати швидкодії. Навпаки, мікросервіси тепер ефективніше використовують ресурси ЦП на близько 10-15%, що свідчить про їх оптимізацію. Важливо відзначити, що хоча споживання процесора зменшилося, спостерігається збільшення обсягу використовуваної пам’яті, а саме на 25-27%. Стосовно питання грошей, хоча наразі не можна точно визначити ефект на фінансовий аспект, але, враховуючи динаміку, можна припустити, що економія складе приблизно 6-8% у порівнянні з витратами минулого місяця.

Вибачте за непорозуміння і враження від статті. Раджу розглянути додаткові ресурси для отримання більш детальної інформації про перформанс ARM в порівнянні з x86. Є багато джерел, де це питання розглядається більш глибоко та докладно. Одним із таких ресурсів може бути [redpanda.com/...​n-2-arm-vs-x86-comparison], або [filia-aleks.medium.com/...​-perfromance-3581aaef75d9], де обговорюється питання профітів для компаній і спеціалістів при використанні ARM, а також проведено порівняння перформансу з x86.

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