Когда Red Hat выпустила Istio 1.20, все только и говорили о сияющих новых функциях: плагинах WebAssembly, улучшенной телеметрии и давно обещанной федерации мультикластеров. Для тех, кто работает с микросервисами на Kubernetes, особенно в экосистеме Red Hat с OpenShift, это должно было стать следующим большим шагом. Обещание? Больше мощности, больше контроля, больше… всего. И для небольших развертываний, вероятно, так оно и есть. Но что происходит, когда вам действительно нужно выжать из этой системы максимум? Вот тут-то история становится интереснее — и дороже.
Речь не о том, хорош Istio или плох. Это стандартный инструмент в арсенале Kubernetes, столь же вездесущий, как статическое электричество на техконференции. Главный вопрос, как всегда, в том, кто платит по счетам, когда вы начинаете танцевать. И с Istio 1.20 и OpenShift этот счёт, похоже, растёт выше и быстрее, чем кто-либо мог предвидеть.
Производительность под ударом
Понятно, мы все видели маркетинговые материалы. Компании любят расхваливать последние релизы как монументальный шаг вперёд. Но когда вы управляете тысячами подов, даже незначительная неэффективность накапливается и превращается в катастрофический оверхед. Именно этим и занялось недавнее исследование, посвящённое Istio 1.20.1 на Red Hat OpenShift 4.14. Они развернули довольно стандартный 8-узловой кластер на AWS, нагрузили его веб-сервисами Nginx Plus, а затем решили посмотреть, что произойдёт, когда система будет работать с тысячей, а затем с десятью тысячами подов. Результаты не радуют тех, кто ожидал плавного и экономичного пути.
Они обнаружили, что главные фишки Istio 1.20 — такие как валидация плагинов Wasm и более надёжные конвейеры телеметрии — не достаются бесплатно. При 1000 подов управляющий план (istiod) работал, потребляя около 2 vCPU и 6 ГБ ОЗУ. Вполне управляемо, верно? А теперь перенесёмся к 10 000 подам. Внезапно istiod требует внушительные 8 vCPU и колоссальные 24 ГБ ОЗУ. Это 300% увеличение CPU и 400% рост памяти по сравнению с базовым уровнем. И вот что интересно: это вдвое больше, чем показывал Istio 1.19 при том же масштабе. Так вот вам и инкрементальные улучшения.
И дело не только в управляющем плане. Каждый под получает более «прожорливый» сайдкар Envoy. Речь идёт о дополнительных 15% памяти и 8% CPU на сайдкар в Istio 1.20 по сравнению с предшественником. При 1000 подах это означает дополнительные 18 ГБ ОЗУ, выброшенные в ваш кластер. Масштабируйте это до 10 000 подов, и вы получите ещё 180 ГБ памяти и ошеломляющие 800 дополнительных vCPU ядер по всей вашей инфраструктуре — и всё это только для поддержки сайдкаров. Таблица рисует мрачную картину:
| Масштаб (Поды) | Средняя память сайдкара (МБ) | Средний CPU сайдкара (vCPU) | Общая стоимость ресурсов сайдкара (относительно без Istio) |
|---|---|---|---|
| 1 000 | 138 | 0.14 | 1.2x |
| 5 000 | 141 | 0.16 | 1.8x |
| 10 000 | 145 | 0.18 | 2.3x |
Это не просто небольшое увеличение; это фундаментальный рост потребления ресурсов, необходимого даже для работы Istio, ещё до того, как вы начнёте применять к нему сложные политики трафика.
Медленное ползучее увеличение задержек
Задержка — бич распределённых систем. Даже несколько миллисекунд могут решить, будет ли приложение отзывчивым или будет казаться вялым. При низком уровне трафика (100 одновременных запросов) Istio 1.20 добавляет ничтожные 3 мс к p99-задержке. Но это в лучшем случае. При 5000 одновременных запросов, как показывает тест, p99-задержка увеличивается на значительные 22% по сравнению с базовой линией без какого-либо service mesh. Хуже того, это 12% рост по сравнению с Istio 1.19 при той же нагрузке. Похоже, новая обработка телеметрии по умолчанию добавляет накладные расходы к каждому запросу, независимо от того, используете ли вы эти модные функции телеметрии или нет. Это как купить спортивный автомобиль высокой производительности и обнаружить, что базовая модель поставляется с постоянно развернутым парашютом.
Операционные головные боли
Помимо чистого потребления ресурсов и задержек, существуют и операционные расходы. Помните распространение конфигурации? Это время, которое требуется, чтобы изменение, которое вы внесли — например, обновление правила маршрутизации — действительно вступило в силу во всех ваших подах. В Istio 1.20 этот промежуток растягивается с быстрых 2 секунд при 1000 подах до «ледниковых» 45 секунд, когда вы достигаете 10 000 подов. А обновления? Забудьте о быстрых, краткосрочных окнах обслуживания. Обновление на кластере из 5000 подов заняло 10,5 минут с Istio 1.20 против 8 минут в 1.19. Для масштабных развертываний это означает планирование периодов обслуживания, которые раньше могли быть не нужны, добавляя ещё один слой операционного трения.
Затем сама телеметрия. Istio 1.20 по умолчанию выдаёт 12 новых метрик. Хорошо, конечно, но для кластеров с более чем 5000 подами это может увеличить объём телеметрии Prometheus на колоссальные 40%. Если вы храните 30 дней метрик, как многие команды эксплуатации, вам придётся рассчитывать на увеличение затрат на хранение примерно на 35%. А если вы решите использовать эти новые плагины Wasm? Добавьте ещё 10 мс задержки и 5% дополнительной памяти сайдкара на каждый плагин. Это каскад функций «хорошо бы иметь», которые незаметно раздувают ваш счёт за инфраструктуру.
“Istio 1.20 по умолчанию включает 12 новых метрик, увеличивая объём телеметрии Prometheus на 40% для кластеров с 5000+ подами.”
Путь вперёд (если очень хочется)
Статья здесь не только для того, чтобы испортить праздник. Она предлагает несколько разумных советов для тех, кто уже привержен пути Istio на OpenShift. Отключение неиспользуемых функций — очевидный шаг; если вы не используете валидацию Wasm, отключите её. Установка жёстких лимитов ресурсов на Istiod и сайдкары может предотвратить бесконтрольное потребление. Использование ревизий Istio для обновлений без простоя — стандартная практика, но стоит упомянуть. А оптимизация рабочих узлов с помощью Node Tuning Operator OpenShift может немного снизить оверхед для этих сайдкаров Envoy. Фильтрация метрик у источника также может сократить объём телеметрии. Это хорошие, практические шаги.
Но мой главный вывод, после двух десятилетий наблюдения за подъёмами и спадами технологических трендов, заключается в том, что мы видим неизбежное последствие «раздувания» функций в сложных системах. Istio 1.20 действительно стал более мощным, абсолютно. Но его повышенная сложность и настройки по умолчанию имеют значительную, часто скрытую, цену в производительности и стоимости при масштабировании выше определённой точки. Это напоминание о том, что «бесплатность» в open source не распространяется на инженерное время и доллары инфраструктуры, необходимые для эффективной работы этих мощных инструментов в масштабе. Если вы не проводите тщательное тестирование и оптимизацию, вы, вероятно, оставляете деньги — и производительность — на столе.
Является ли это похоронным звоном для Istio? Едва ли. Он по-прежнему де-факто стандарт для многих. Но это серьёзный предупредительный выстрел для всех, кто планирует развернуть его в среде OpenShift высокого масштаба. Обещания передовых функций манят, но результаты тестирования подчёркивают суровую реальность: стоимость масштабирования с Istio 1.20 на OpenShift может быть намного выше, чем ожидалось изначально, требуя тщательного планирования и агрессивной оптимизации, чтобы избежать деградации производительности и неожиданных всплесков затрат на инфраструктуру.
🧬 Связанные материалы
- Читайте также: Daily Briefing: April 25, 2026
- Читайте также: OpenForge Collection: SOTA Tools от Greyforge Labs, меняющие DevOps
