k8s HPA бесполезен? Или нет?)

Я уже писал о возможности масштабировать поды горизонтально через компонент HPA — Horizontal Pod Autoscaler. Он собирает метрики загрузки пода (границы можно настраивать) и меняет число реплик в заданных границах.

Круто? Да. Но есть одно «но». В namespace ресурсы часто прибиты гвоздями. Один namespace = один микросервис. Микросервис имеет некие бизнес-требования по нагрузке, проходит нагрузочное тестирование и получает некоторое количество ресурсов. Хуже того — кластер, в котором находится namespace, тоже имеет жёсткое ограничение по ресурсам. Это частное, небольшое по сравнению с cloud-провайдерами облако. Лишним node взяться неоткуда. Поэтому HPA в частном облаке бесполезен. Все ресурсы уже забронированы. От того, что часть из них уберут из балансировки, ни холодно ни жарко. Только замедление при старте пода.

В больших облаках, типа AWS, эту проблему решают тем, что прячут кластер от клиента и динамически меняют его размер.Если потребителей много и у них разный характер нагрузки, всё должно работать хорошо.

Что можно сделать в частном облаке? Например, вот так: https://youtu.be/GWJ9rDrsBdQ?si=dx-VHMlIIYKo2g4q Кейс не универсальный, но если есть свой кластер и понятно, что в нём будут жить приложения с разными пиками нагрузки — потребление ресурсов можно оптимизировать. Как развитие идеи — автоматическая генерация рекомендаций по настройке кластера.

#k8s #optimization

Нужны ли sidecar?

Напомню, sidecar - это паттерн распределенных систем. Суть - есть 2+ контейнера. Один главный — контейнер собственно сервиса, содержит основную логику. Второй - "прицепной" (это дословный перевод sidecar) контейнер. Его роль - дополнить и улучшить контейнер сервиса. Причем часто основной сервис даже не предполагает о его существовании. Удобно для прозрачного навешивания нового функционала. Примеры: добавление Service Mesh, логирования, шифрования, работа с секретами...

У себя в компании я наблюдаю тренд по отказу от sidecar.

Почему?
У нас микросервисы. Мы не делаем их большими, требования к ресурсам стараемся оптимизировать - получаем реалистичные бизнес-требования, проводим НТ, устанавливаем requests и limits. Так по крайней мере должно быть)
Но что получается в итоге?
Предположим у нас service mesh. Предположим есть требование безы - весь входящий и исходящий трафик идет через ingress\egress. Это уже минимум +3 контейнера envoy proxy со своими limits. Если один контейнер сервиса = один envoy proxy, + ingress + egress.
А если каждый из них нужно "обмазать" sidecar для шифрования. А еще для хранения секретов. А еще для логирования. И еще какие-то требования платформы.
Итого я видел кейсы, когда на один контейнер простого бизнесового сервиса в namespace было 7 или 8 служебных контейнеров. И даже если каждый из них потребляет меньше ресурсов, чем бизнес сервис - в итоге мы получаем х3 накладных расходов по ресурсам. Грустно(
Проблема на самом деле не только в контейнерах - любые служебные pod в namespace тоже вносят свой вклад.

Как же решается проблема?
Путей несколько:
1) часть функционала можно встроить в сам приклад. Если в прикладе уже есть клиентский модуль сервиса X и его все равно надо периодически обновлять с пересборкой - сделать этот клиентский модуль чуть толще вполне себе можно.
2) у k8s есть такая штука как операторы. Это сервис, работающий где-то рядом с ядром k8s, который может отслеживать изменения конфигурации в любом namespace и по этому событию делать что-то полезное. Например, по наличию определенной аннотации у пода подгружать для него секреты. Или собирать метрики с пода, опрашивая url Prometheus, построенный по определенному шаблону. Или настраивать Rate Limiter на envoy proxy при его старте. Оператор можно создать самому, это по сути plugin для k8s
3) если продолжить мысль из предыдущего пункта - по такому же сценарию можно поступить и с Istio proxy (он же envoy). Встречайте - Ambient Mesh. Вот статья про технологию https://habr.com/ru/articles/807117/, а вот как это внедряется в Сбере https://yandex.ru/video/preview/3928252140575819915 Все прокси не исчезают, трафик в облаке большой, оператор не может маршрутизировать его сам. Но прокси создаются на каждой node, а не на каждом контейнере. Требования к ресурсам у них будут побольше, но все равно получаем экономию по ресурсам в разы.

P.S. еще одна проблема, которую решает отказ от sidecar - с разработчика снимается обязанность отслеживать появление новых версий sidecar и их обновления.

#k8s #cloud #optimization