ℹ️ Оптимизация расходов на AWS SQS

Если вы используете AWS SQS с дефолтными настройками и у вас более миллиона сообщений в день, обратите внимание на параметр receive_wait_time_seconds.
По умолчанию его значение равно 0, что означает использование Short Polling.
При таком подходе AWS будет брать с вас плату за каждый API-запрос, даже если очередь пуста.
Что можно сделать:
Установите receive_wait_time_seconds = 20 в вашем Terraform-конфиге, чтобы включить Long Polling.
При этом режиме AWS будет удерживать соединение до 20 секунд в ожидании сообщений, что существенно сократит количество API-вызовов.
Результат:
В моём случае это снизило расходы примерно в 3 раза! Ваша экономия может отличаться в зависимости от паттерна использования очереди и частоты появления сообщений.
⚠️Важно:
Подходит для случаев, когда вам не критична минимальная задержка в получении сообщений.
Если ваш сценарий требует мгновенной обработки - оставьте Short Polling и платите больше.

#AWS #Terraform #CostOptimization

ℹ️Оптимизация расходов на AWS RDS Proxy и CloudWatch

Если у вас есть RDS MySQL с read replica и RDS proxy, то вы можете сильно сэкономить на CloudWatch логах.
Проблема:
- RDS Proxy по умолчанию отправляет ВСЕ логи уровня INFO в CloudWatch
- Это нельзя отключить через консоль или API
- Вы платите за:
1. Каждый входящий лог-ивент (PutLogEvent)
2. Хранение этих логов
- Большинство этих логов - просто информационные, не критичные для мониторинга
Решение:
1. Написать в AWS Support
2. Попросить изменить log level для RDS Proxy с INFO на ERROR
3. Profit!
Результат:
- Количество логов уменьшается в миллионы раз
- В нашем случае счёт за CloudWatch снизился на 170$ в месяц
Бонус-совет:
Даже если вам нужны некоторые логи, можно дополнительно уменьшить retention time в CloudWatch до 1 дня для экономии на хранении.

Да, это может показаться мелочью, но:
- Занимает 5 минут времени
- Требует только написать письмо
- Экономит реальные деньги, в моем случае аж $170 ежемесячно

#AWS #CostOptimization

На выходных впервые пересмотрел всю классическую серию фильмов Звёздные Войны с 1 по 6 эпизод.
Очень понравилось, потрясающе. Как жаль, что я раньше не видел эти фильмы.

Так же понравился Чубакка. Его внешний вид и особенно звуки мне напомнили самого себя, когда в будний день меня внезапно без приглашения и записи в календаре инвайтят на встречу в зум/слак/тимс. Один в один это я.

Random Teams call? Full Chewbacca mood.

Больше стал внедрять оптимизацию по ресурсам.
Понравилась утилита krr от робусты. Хотя саму робусту я, мягко говоря, недолюбливаю.
https://github.com/robusta-dev/krr
Использование простое, например вот так:

>./krr simple --history_duration=120

Оно показывает все рекомендации, как поправить CPU/Memory request/limits.
Исправляешь везде и скедулер куба работает точнее.
Не выделяются лишние ноды или наоборот не ощущается нехватка ресурсов с медленным скейлом нод.
Раз в квартал сделать оптимизации руками и всё ок.
У меня это встроено в скедулед пайплайн, который срабатывает раз в месяц, я прост смотрю отчёт.
В конечном итоге это нужно для оптимизации костов.

#kubernetes #CostOptimization

Комментарии стоит писать так, чтобы любой участник команды понимал что в конфиге, что это за код и почему такие цифры (с)

# Node: 32Gi RAM total (100%)
#
# Memory allocation and thresholds visualization:
#
# Memory (Gi)     % of total
# 32.00 (100%) ┌──────────────────────────────────────────────┐
#              │                                              │
# 30.13 (94.2%)│               Safe working zone              │ ← Allocatable: 30.13Gi (32 - 1 - 0.87)
#              │                 (26.93Gi)                    │
#              │                 (84.2%)                      │
# 20.00 (62.5%)│                                              │
#              │                                              │
#              │                                              │
# 10.00 (31.3%)│                                              │
#              │                                              │
#  3.20 (10.0%)│- - - - - - - - - - - - - - - - - - - - - - │ ← Soft eviction starts (10% of total)
#              │           Soft eviction zone                 │ ← 30s grace period
#  1.00 (3.1%) │━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━│ ← Hard eviction starts
#              │           Hard eviction zone                 │
# 0.00 (0%)    └──────────────────────────────────────────────┘ ← Node is "not ready" and "dead" (memory pressure)
#
# Reserved (total 1.87Gi, 5.8%):
# - system-reserved: 1Gi (3.1%) - OS & system daemons
# - kube-reserved: 893Mi ≈ 0.87Gi (2.7%) - k8s components
#
# Working ranges:
# - 30.13Gi - 3.2Gi:  Safe working zone (26.93Gi, 84.2% usable)
# - 3.2Gi - 1Gi:      Soft eviction zone (2.2Gi, 6.9%)
# - <1Gi (3.1%):      Hard eviction zone (immediate pod killing)

# https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
[settings.kubernetes]
api-server = "${endpoint}"
cluster-certificate = "${cluster_auth_base64}"
cluster-name = "${cluster_name}"
pod-pids-limit = 1024
image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80
container-log-max-files = 50
container-log-max-size = "100Mi"

[settings.kubernetes.system-reserved]
cpu = "200m"
ephemeral-storage = "1Gi"
memory = "1Gi"

[settings.kubernetes.kube-reserved]
# memory_to_reserve = max_num_pods * 11 + 255
# memory_to_reserve = 58 * 11 + 255 = 638 + 255 = 893 MiB
memory = "893Mi"

[settings.kernel]
lockdown = "integrity"

[settings.host-containers.admin]
enabled = ${enable_admin_container}

[settings.host-containers.control]
enabled = ${enable_control_container}

[settings.kubernetes.eviction-hard]
"memory.available" = "1Gi"
"nodefs.available" = "20%"
"nodefs.inodesFree" = "5%"
"imagefs.available" = "15%"

[settings.kubernetes.eviction-soft]
"memory.available" = "10%"

[settings.kubernetes.eviction-soft-grace-period]
"memory.available" = "30s"

Тут, конечно же с телефона полная херня, но с ПК клиента все отлично.

#kubernetes

Столкнулся с интересной проблемой в Kubernetes кластере с Bottlerocket AMI и хочу поделиться находкой.

Изначально ситуация выглядела как классическая проблема с памятью:
1. Растет нагрузка на сервис (новые прожорливые поды)
2. Приложения начинают потреблять больше памяти
3. Происходят OOM киллд шторм, сжирается вся память нод.
4. Ноды падают в not ready, сервис деградирует

Первый этап решения был очевидным - настроить kubelet так, чтобы защитить ноды от падения(выше пример).
Внес изменения, и теперь:
1. Растет нагрузка
2. Приложения едят память
3. Происходят OOM шторм
4. Ноды теперь живы, поды умирают по оомкиллед не убивая ноду - поды убивает кублет.

Вроде бы лучше, но проблемы с сервисом все равно есть.
Включил расширенное логирование, собрал данные за несколько дней и обнаружил реальную причину:
1. Растет нагрузка
2. Приложения едят память
3. OOM киллы убивают поды, ноды живы.
4. Автоскейлер поднимает новые ноды (около 15 секунд)
5. НО! Новые ноды не могут сразу принять поды, потому что сетевой драйвер (CNI) еще инициализируется
"NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"

И вот эта временная яма между "старые поды умерли от ООМкиллд шторма" и "новые ноды еще не готовы из-за долгой инициализации сетевого драйвера" создает провал в работе сервиса. Сраные 11 секунд.

Сейчас исследую два направления решения:
1. Ускорение инициализации сетевого драйвера на новых нодах
2. Упреждающее масштабирование - чтобы новые ноды поднимались заранее, до достижения критической нагрузки

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

Ниже можно найти окончание истории, проблема была не в этом

Позволю себе репостнуть самому себе свой же ответ. Лень перепечатать, да хотя бы пусть даже и без мата.
Ну уж простите, такой я импульсивный человек, мат у меня не табуирован в момент эмоций.
Сегодня с утра сделал тесты после той простыни - всё подтвердилось.

TLDR:
- дело было не в CNI/cluster autoscaler/OOM, да в общем-то и не напрямую в кубернетес
- дело было в кретинизме лайвнес пробы, которая смотрела на базу подключаясь, забивая коннекты при большой нагрузке(количестве подов) и левых ограничениях на базе в 1400 лимит коннешнов.
4000 лимит пока решил проблему, но теперь есть и алёрт и пояснение за всё это, в будущем 100% не повторится.

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

* На картинке это я со своими первыми гипотезами и странными мыслями

Ну вот гипотеза номер v4 (а первые две я опущу, там вообще не туда копал вообще. настолько не туда, что всратых историй не будет).
Третья гипотеза тут. Ссылка для тех, кто пропустил начало треда.

Первая мысль была "а и правда, в хули у нас пробы одним из первых валятся" после наводки от @identw
Нырнул глубже, традиционно обнулив все предыдущие факты и наблюдения, чтобы быть беспристрастным.
Ну поехали с нуля. База так база.

- оказалось, что у проблемных подов health-check стоит, в том числе, и на базу (Aurora MySQL). Доступность БД, сука. Прям в код аппликейшн пришлось посмотреть. Девелоперы не признавались.
- ок, лезем в графану, метрики то у нас все есть. Идём в историю ласт аутейдж.Ого, есть зацепка.
- в момент проблемы все коннекшны до базы достигают максимального значения в 1400 (почему 1400 никто не знает, хотя по дефолту должно быть 3000-4000, сорс https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html).
А чо там с подключением? А подключение идёт через rds proxy. Смотрим на proxy и звенит рында как на корабле "та-да!", всё верно, лимит стоит в 100%, вместо рекомендуемого 90. Пофиг на 90, ползём дальше, пока в дурку не загребли.
- ладно. ну и чего нам это даёт?

И вот зарождается гипотеза номер 4.
А что, если проблема не в скейлинге, не в CNI (который просто случайно в логе вывалился, а я как рак сельский дурачок вцепился клешнями), не в ООМ, не в кублете, а в другом? Да вообще, сука не напрямую в кубере.

Маняфантазёр с влажными идеями вошёл в чат
Не может ли быть такой ситуации?:
- работает допустим 4 ноды, 50+ подов, всё ок.
- город просыпается, нагрузка возрастает, клиенты начинают усиленно клацать в UI имитируя работу
- KEDA скейлит поды, количество коннекшнов до базы упирается в 1400 и это 100% (а потому что через прокси ограничений нет). Даже от себя к базе не подключится, нет гэпа ля мейнтенанса.
- бизнес поды начинают лихорадочно кудахтать и liveness пробы отвечают, что вошли не в ту дверь.
- кублет видит, что часть подов подыхают, KEDA/kubelet (я тут тупой и не знаю кто быстрее тут) поднимают новые реплики взамен умирающих лебедей.
- на старых нодах видим троттлинг, ну а хули, они единственные кто пока ещё может с базой работать
- ресурсов на нодах не хватает, автоскейлер в панике скейлит новые ноды в нескольких пулах(а это и не важно)
- ну ок, ну поднялись новые ноды и новые поды - коннекшнов то блять нет всё равно, у них тоже лайвнес пробы на базу стоят
- ну класс, у нас теперь целое стадо умирающих лебедей на новых нодах, на старых нодах с не срабатывающими лайвнес пробами
- вся реальная нагрузка бизнеса ложится на хрупкие плечи тех подов, кто остался на старых нодах, имеют коннекшны и они начинают дико яростно жрать все ресурсы, уходят в лимит и дико троттлят.
- кублету надоедает этот блядский цирк с бородатыми женщинами, конями и тупорылым стеком, он включает шизу и по хардэвикшну киляет все старые поды с троттлингом со старых нод.
- конекшны освобождаются, на новых нодах новые поды начинают работать, берут на себя часть нагрузки, сервис стартует
- глупый SRE инженер два дня копает не туда, зачем то залезая в кишочки API и кублета, пытаясь понять что там было за 10-20 секунд околодаунтайма, приплетая сюда ещё и CNI,который смотрит на него с недоумением совы, к которой ночью без спроса лезут в гнездо

Тот гэп, между этапом "вся нагрузка лежит только на старых подах, с троттлингом по CPU и, иногда, с нагрузкой по памяти, упирающаяся в ООМ, у которых ещё есть коннекшны к базе" и "кублет кильнул старые поды по OOM, новые поды в новых нодах получили свободу и коннекшны и подключились к базе, балансир после прохождения проб переключил на них трафик, взяли бизнес нагрузку" и есть мой ёбанный аутейдж. Сраные секунды аутейджа.

Мой старый отзыв на PMM + Kubernetes.
Продублирую тут для истории.
https://docs.percona.com/percona-monitoring-and-management/2/index.html

Всё же опишу наши боли про pmm и k8s.
Хоть и не пятница, но настрочу, настало время всратых стори.

Представьте себе такую ситуацию: у вас десяток кластеров Kubernetes, а в моем случае их ещё больше. В каждом из них несколько баз данных, которые разворачиваются с помощью оператора. У каждой базы данных есть свой FQDN, доступный только в приватной сети. Креденшалы хранятся в секретах, как всегда. Пока всё хорошо, как и у всех.

Теперь, мы хотим всё это мониторить и находим супер продукт - Percona PMM.
Потыкали мышкой, и кажется, что это то, что надо. Ну наконец-то, идеальное решение!

Далее, ставим PMM сервер в кластер, используя чарт, Terraform, Helm или Argo - выбирайте по вкусу говна.
Затем нужно зарегистрировать базы данных через PMM клиент на PMM сервере. И тут перед нами два "великолепных" варианта:
- натыркать всё мышкой в UI.🤡
- поднять деплоймент для каждого агента через GitOps или другой любимый инструмент.

Оба варианта, конечно, идеально подходят для динамически меняющихся баз данных в кубере.

Думаем: «Ну ок, наверняка ребята из Перконы сделали автодискавери». И тут сюрприз!
Автодискавери и авторегистрации нет - ни по лейблу, ни по какому-либо другому признаку.

Решаем поднять сайдкар (через оператора), который будет регистрировать базу каждый раз, когда она добавляется, и при этом работает для существующих баз данных. Кажется, отличная идея. Создаём сайдкар, который говорит PMM серверу подключаться к БД через FQDN.
В итоге видим в админке PMM сервера попытку регистрации, но вместо FQDN клиент видит внутренний IP адрес в Kubernetes. 🤡
И регистрация не проходит.

Оказывается, проблема в gRPC и ингрессе(на двух контроллерах).
Какая-то бага, что в чарте, что без него (issue не открывали, лень, признаю, не прав).
Стоит заменить внешний адрес на адрес service - проблема с регистрацией уходит. То есть рега в кубере работает только с k8s service.
Это не очень удобно, так как визуально название в UI сервера будет некрасивым и многие девелоперы, кто подключатся к pmm не сразу матчат свою бд с не очень семантическим названием сервиса.
Это не самая большая проблема, можно закрыть глаза.
Если у вас нетворк полиси, запрещающий обращение к сервисами в других неймспейсах, то у вас новые проблемы(БД то в разных ns).
Стоит ли говорить про удобство, когда вы хотите один PMM сервер на сразу несколько кластеров из БД в разных неймспейсах, а не pmm на каждый из кластеров и решение через регистрацию по имени сервиса это не очень ок.

Так же остаётся проблема с самим IP. Адрес может поменяться быстрее, чем @gecube триггерится на сообщения в чате с кодом без бектиков.
И мониторинг накрывается женским половым органом, бежишь как сельский дурачок вручную делаешь перерегистрацию.

И ещё 2-3 бага в подарок нашли, но, справедливости ради. это не связано напрямую с кубером.

workaround solution - либо пилить своего оператора, который будет следить за svc и по лейблам добавлять авто регистрацию, авто обновление по IP и авто удаление БД, либо пока не переходить на PMM мониторинг в кластерах Kubernetes, либо, как мы, спиздить борды у PMM и перетащить их в свою графану, немного допилив и адаптировав. Так же надо научить сервис скрейпер/прометеус забирать метрики не только постгри, но ещё и патрони(в случае с постгрей). С кластерами mysql там вообще пизда весело.

Вывод: хочешь мониторить базы данных в Kubernetes с помощью Percona PMM? - готовьтесь к захватывающим приключениям и тратой времени по трекеру на таски с этим.
Или просто подождите, пока ребята из Перконы наконец-то добавят нужный функционал для вообще самой концепции "много бд, всё в кубере, много кластеров, хотим один пмм сервер".

Хочу отметить, что сам пмм мне нравится, он хорошо подходит для статик бд, например в ажуре или амазоне, но для БД с операторами в кубах - никак пока что.

#pmm #kubernetes

Пятничные микро истории.

В далёком 2022 году, на пике волны импортозамещения, я хотел с ноги ворваться в российский финтех со своими решениями.
Было три основных направления и я сделал 3 MVP по каждому из них. Ходил тихо по кулуарам, писал письма, пилил демо.
Конечно же всё было зря, просто так зайти в кормушку нельзя, никого не интересовали реальные решения для инженеров, всем были более интересны откаты, схематозики да переклейка логотипов известных продуктов.
Мне быстро дали понять, что меня тут не ждут, всё полянки поделили до меня.

Один из MVP проектов, а точнее мелкую его часть, я выставлял публично для тест попытки внедрения в один банк.
Ну вообще это удобно или нет. Ок или не ок.
Декрипт/енкрипт values файлов для helm.
https://github.com/kruchkov-alexandr/yaml-encrypter-decrypter
Можете особо не заходить по ссылке, он заброшен давно и надолго в связи с потерей моего интереса.

Сейчас этот проект взял под своё крыло совсем другой инженер, по нашей договорённости он его форкнул и начал развивать.
Надеюсь у него получится сделать из него что-то приличное, вполне возможно будет не форк, а полностью самостоятельное не заброшенное решение.
https://github.com/atlet99/yaml-encrypter-decrypter
Можете заходить, если вдруг интересует тема енкрипшн/декрипшна.
Если не интересует, то просто скипните пост.😅

🎄
В сербском языке есть достаточно популярная в разговорной речи фраза
Као усран голуб
Чаще всего в практике используется для обозначения потерянных/растерянных/несчастных/неуверенных людей.
Так же используется для подавленно выглядящих людей или мающихся по комнате.
Шта ти је, што седиш ту као усран голуб?

Знаю, что очередной прошедший 2024 год был как всегда тяжелым для всех, так что
Желим ти да у новој години не будеш као усран голуб!
🎄

Простите, моя фантазия с поздравлениями в этом году весьма ограничена😅

Утро второго января начинается под хруст уже слегка несвежих салатов и бутербродов девопса с икрой и красной рыбой с просеко на завтрак.
Затем, под легкий и приятный хмель, приходит мысль "а чойта мы давно код не писали" и желанием написать свой велосипед.

❕Я в курсе про экспортёры и в частности https://github.com/webdevops/helm-charts

Задача: мониторить протухшесть аппрегистрейшн в ажуре.
Сложности: тенантов десятки и в каждом из них десятки/сотни сабскрипшнов.
Идея:
- сделать единый мультитенанси аппрегистрейшн
- напилить скриптом по нужным нам тенантам(а вот так ещё усложним, что нужно часть, а не все) сервиспринципл
- раскинуть всем сервиспринципал права на сбор метрик по протухшести кердов и не более
- напилить приложение, которое при помощи кредов подключается ко всем тенантам и их сабскрипшнам
- приложение умеет отдавать стандартные метрики прометеус и отдавать на http эндпойнт
Реализация:
- первичная инициация AR + SP + Permissions (я не стал писать код автоматизации, достаточно скрипта в ридми, это же один раз)
https://gist.github.com/kruchkov-alexandr/bd0bd7289d984751f3a92e7f4981c286
- Dockerfile с массивным azure cli и реквайрментс для питона
https://gist.github.com/kruchkov-alexandr/25817a9d2ed0c5daa713cedb1e3da0a1
- сам питон скрипт
https://gist.github.com/kruchkov-alexandr/8c41c33aff606463a17315447e62c25f
- можем смело отслеживать алёрты типа

app_credential_expiry_days < 15

Дальше пихаем его куда угодно, хоть на виртуальную машину, хоть в кубернетисы и забираем метрики на 8000 порту.
Раз в 30 минут по циклу опрашивает срок жизни всех токенов всех сабскрипшнов и тенантов, куда есть доступ.
Затем этим метрики забирает виктория метрикс.

Практической ценности этот код не имеет, лишь тренировка "давно мы ничего не писали и, судя по коду, лучше и не надо".