#kubernetes #secrets #api

(заметка не несёт никакой ценности, лишь мысли)

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

Это может быть знания зачем EXPOSE в докер файле и на что это влияет, какая разница между cgroup v1 и cgroup v2 или различия хранилищ для больших данных и миллиардов мелких файлов по 6 KB.
Практической ценности такие изыскания обычно не имеют, это больше любопытство и разминка для ума. Лишь иногда попадаются настоящие "бриллианты".

Мне захотелось узнать, а какие есть способы, чтобы снизить нагрузку на Kubernetes API.
Все мы знаем про кучу операторов, которые не хило нагружают апишку, но что, если снизить средствами самого кубера?
У нас есть несколько VERBs.
https://kubernetes.io/docs/reference/using-api/api-concepts/

Знания и поиск по документации привел к тому, что есть WATCH запрос, который идёт каждый раз от kubelet, когда стартует под или скейлится или происходит редеплой через любую из стратегий, при использовании секрета кубернетиса.
То есть каждый раз при этих действиях идёт WATCH.
Сам по себе секрет, просто лежащий в кубере, никакой нагрузки не несёт.
Пока secret не примонтирован(как переменная или файл) и пока не было рестарта/скейла/редеплоя, апишку никто не дёргает.
Однако при активном скейлинге (все мои проекты), это прям попадание в точку.
Да, вочей хватает.

sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

Затем мои поиски вывели на отличную опцию immutable в секретах (вру, я слышал и знал о ней раньше, но прям в проде не использовал).
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable
С этой опцией нельзя поменять значение секрета. Его можно только реплейснуть или удалить и создать с нуля.
Копнув дальше, я узнал, что тут можно немного снизить нагрузку из-за интересного механизма.

"если секрет иммутабл, то кублет(с каждой ноды) не делает WATCH запрос в апишку".

"О господи! Оно!" - подумал я. Это было нечто новое, захотелось сразу использовать. И сразу в проде 😀
Начал смотреть какие есть реализации:
- исправление своих чартов, чтобы секреты были иммутабл и были хуки(иначе при редеплое и изменении секрета хелм упадёт с ошибкой).
- написание мутейшн хука или оператора, который все задеплоенные секреты помечает сразу иммутабл, а все команды переучить, чтобы в их чартах были хуки

В целом неплохая картина: немного изменил флоу в командах по релизам, добавил хуки, все секреты в кубе иммутабл и получаем:
- меньше латенси WATCH и CONNECT запросов (проверено, кубер 1.33, Linode)

sum(rate(apiserver_request_duration_seconds_sum{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)
/
sum(rate(apiserver_request_duration_seconds_count{job=~"kubernetes-apiservers|apiserver", cluster=~"$cluster"}[$__rate_interval])) by (verb)

- меньшее количество WATCH запросов (проверено, кубер 1.33, Linode + AWS)

sum by (verb) (rate(apiserver_request_total{ cluster=~"$cluster"}[$__rate_interval]))

- меньше памяти в ETCD. Это теоретически, большинство клауд провайдеров не дают прямой доступ к метрикам ETCD(я тестировал на AWS + linode), а потому доказать не могу. Барметал с нуля поднимать лень, так что пусть это окажется лишь теорией.

Всё выглядит как сказка, а что на деле?

Тут я вспомнил, что работал в замечательном банке с синим логотипом, и там до сих пор во всех департаментах работают очень крутые инженеры (всем привет, кто читает, вы солнышки❤️).
Тема интересная, заменшил в паблик чате @kubernetes_ru и меня тут же спустили на землю.

Оказалось что ребята это уже пробовали у себя и быстро от этого ушли.
Беда в том , что если такой immutable секрет замонитирован на ноде более, чем в один под(разные деплойменты) то такой секрет не подтянется при изменим даже при рестарте.
Проверил - да, у меня есть много секретов общих для нескольких деплойментов.
Безусловно это ставит крест на моей задумке, баги мне не нужны ради 1.5-3% экономии нагрузки.

Ладно, время на изыскания вышло, эх, и на этот раз не бриллиант.😭