#azure #aks
Просто сохраню это тут, мои мессаджи с другого телеграм канала.

* я до конца не уверен, что я на 100% верно и корректно описал всё происходящее во время проблемы, но я на 100% решил проблему на всех кластерах с данным уровнем понимания.

Коллеги со связкой Azure AKS/ AWS EKS + ArgoCD.

У кого-то после последних апдейтов(просмто смена версии, автосесурити апдейт) поломал ли чего в кластере при взаимодействии ArgoCD -> k8s API?
Дикий бурст насилия.
Если кто сталкивался и решил - напишите плиз.

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

ТЛДР: ажур конченные спидораковые ублюдки свинособачьих шлюх.

После автоматического и не отключаемого обновления AKS в API-сервере появился строгий рейт-лимит, которого раньше либо не было, либо он был мягче. Это вызвало неожиданный эффект: ArgoCD стал чаще дёргать апи и это вызвало нагрузку на API до 40-80 тысяч RPS на каждом из кластеров, увеличив латентность и количество запросов.
Отключение контроллеров Argo не сразу спасло ситуацию - нагрузка держалась из-за накопившейся очереди.
Даже базовые операции (GET, PUT, PATCH) застревали, уходя в retry, а метрики показывали код 409 (Conflict) из-за одновременных попыток обновить ресурсы.
Admission-контроллеры тоже вставали в очередь, усугубляя хаос.

воркэраундсолюшн: отключить ArgoCD/Kyverno, вебхуки и другие активные компоненты, пока нагрузка не упадёт до 30–50 RPS. После этого можно постепенно включать их обратно - ArgoCD зальёт кучу watch-запросов, GET-ов и патчей для синхронизации(чего он там сперва пушит в апиху) и кластер стабилизируется.
Если же Argo и/или киверно не выключать, он уходит в бесконечный retry storm, перегрузка API сохраняется, а метрики с пиками точёными ошибок 409.
Дольше всего ушло времени на трублшутинг, из-за моей тупости не было сразу понимания, что при вырубании просто арго/киверно и других говн, ещё и хуки ж насильничают апи и надо ещёёёёё время, чтобы всё рассосалось.

#aws #eks #kubernetes
Задача уровня junior+/middle-

Ну вот подключил ты Karpenter/Cluster Autoscaler + SPOT инстансы через разные node group.
Всё даже работает, ты проверяешь в EKS web консоли.

Задача: как быстро и удобно понять когда/сколько у тебя on-demand нод, а когда spot нод?
Для аналитики использования и вообще для удобства.
Перебираешь все метрики и не видишь ничего сходу.
А сходу их и нет. (а, ну или мне сейчас накидают горелых пирожков с гусятками в мою печурку в комментариях)
Прометей/VM не знает ничего про споты или не споты.
А давайте мы сделаем всё сами.

Сперва в наших существующих нод группах вешаем лейблы

resource "aws_eks_node_group" "on-demand-group" {
...
  labels = {
    "node-type" = "on-demand"
...
  }
...
}


resource "aws_eks_node_group" "spot-group" {
...
  labels = {
    "node-type" = "spot"
...
  }
...
}

Задеплоили, проверяем, есть ли лейблы

kubectl get nodes -L node-role,node-type

NAME                           STATUS   ROLES    AGE   VERSION               NODE-ROLE        NODE-TYPE
ip-10-1-123-114.ec2.internal   Ready    <none>   70d   v1.31.4-eks-aeac579   infrastructure   on-demand
ip-10-1-14-194.ec2.internal    Ready    <none>   42m   v1.31.6-eks-aad632c   applications     on-demand
ip-10-1-24-165.ec2.internal    Ready    <none>   52s   v1.31.6-eks-aad632c   applications     spot

Видим свои лейблы:
- NODE-TYPE, тип ноды - нам нужно как раз это
- - spot
- - on-demand

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

Дальше нам нужно научить "какой-то" компонент обсервабилити кубернетиса собирать его.
У нас есть метрика с именем kube_node_labels от компонента kube-state-metrics
Компонент kube-state-metrics вы можете ставить разными способами: от оператора, отдельный манифест, стак набор, да не важно.
Смотрим в прометиусе/ВМ - метрика есть, но наших новых лейблов нет.
Как бы вы его не ставили, добавьте в его конфиг такой параметр

kube-state-metrics:
...
  extraArgs:
    - --metric-labels-allowlist=nodes=[node-type,node-role]

Тем самым, мы разрешаем обогащать метрику новыми лейблами из списка.
* Звездочку писать не рекомендую - этим вы лишь будете занимать сильно больше лишнего места в хранилище прометиуса/викиторииметрикс.
Применяем, смотрим в графане - красота(скриншот).

sum(kube_node_labels) by (label_node_type)

Результат: пару простых движений и у нас есть график в графане сколько каких нод у нас было в нужный момент времени.
Видим график и понимаем "ага, нам есть над чем работать, надо сделать тюнинг спот инстансов больше, чем он деманд, чтобы платить меньше", но об этом мы поговорим в следующий раз.

* параметр extraArgs может отличаться синтаксисом вашего чарта, читайте документацию по тому способу, как вы ставили куб стейт метрикс.

#одинденьизжизни #longread #kubernetes

Импровизация.
Лонгрид.

Да-да, часть моей работы это импровизация.
Зачастую бывает ситуация, что мне надо что-то решить, а я ну воообще не понимаю что это такое.

Сложилась такая ситуация, что у нас перестал работать стабильно некий сервис.
Пользователи/коллеги жалуются: "при работе с фронтенд приложением видим ошибку ****, помогает рестарт нескольких подов в кубере".
Речь идёт про DEV, но потенциально может аффектить и PROD часть.
Продакшн нам нельзя ломать, иначе меня уволят и мне нечем будет хвастать в интернетах успехами своих успехов.

Идём разбираться.
Какая ошибка? Ошибка в вебе звучит примерно так

{
    “errorCode”: “ERR_DIRECT_INVOKE”,
    “message”: “failed to invoke, id: REPLACEMESERVICENAME, err: failed to resolve address for ‘REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local’: lookup REPLACEMESERVICENAME-dapr.REPLACEMENAMESPACE.svc.cluster.local on 10.0.12.10:53: no such host”
}

Я честно говоря хер знает что такое инвоук, что такое дапр и уж тем более не знаю почему такая ошибка возникает.
И почему тут вообще ресолв, с*ка. Причем тут внутренний DNS. Вы поехавшие что-ли?

В подобных случаях я строго не рекомендую пользоваться нейронками.
Во-первых конкретно в подобных случаях вы не знаете проект(как я), во-вторых, не знаете все 500 вводных, что важны для промпта и вы их просто пропускаете и нейронка не даст ни-ког-да вам точного ответа. Я не знаю примерно ничего, даже с чего начать и нейронка тут не поможет, лишь запутает.

Ок, смотрим что такое DAPR.
Читаем официальную документацию. https://dapr.io/
На основании документации выносим для себя определение что это.
DAPR (Distributed Application Runtime) - это фреймворк для упрощения разработки микросервисов, предоставляющий готовые решения для обмена сообщениями, управления состоянием и взаимодействия сервисов. Используется для создания масштабируемых и устойчивых распределённых приложений.
Ага, нихера не понятно. Очередная всратость для кубернетеса.
Что-то должна упростить, осталось понять кому она упрощает и как.
Смотрим, а что же у нас есть.

У нас есть отдельный неймспейс, в котором стоит
- dapr оператор
- dapr dashboard
- dapr-sidecar-injector
- dapr-scheduler
и всякое подобное.
Почитал логи, порестартил поды, посмотрел ивенты. Ничего не понятно.
Не понимаю чем это должно мне помочь, читаю дальше и разбираюсь по коду.

А как деплоится этот проблемный сервис?

>ky pods REPLACEMESERVICENAME-7766b4d5c-w66vc
apiVersion: v1
kind: Pod
metadata:
  annotations:
    dapr.io/app-id: REPLACEMESERVICENAME
...
    dapr.io/enabled: "true"
...
  labels:
    app: REPLACEMESERVICENAME
...
    dapr.io/app-id: REPLACEMESERVICENAME
    dapr.io/metrics-enabled: "true"
    dapr.io/sidecar-injected: "true"
...
    metrics_scrape_enabled: "true"
    metrics_scrape_from_pods: "true"
    pod-template-hash: 7766b4d5c
    release: REPLACEMESERVICENAME
    tier: web
    track: stable

По аннотациям видно, что генерация манифеста идёт через хелмчарт.
Ага, дошёл до helm чарта, у нас есть параметр-аннотация для дапра.
Понимаю, что при добавлении

dapr:
  enabled: true

Для каждого сервиса, где включен этот параметр, добавляется сайдкар.
Круто, хоть куда то сдвинулся в понимании что есть что.

#одинденьизжизни #longread #kubernetes

Промежуточное мнение: у нас есть N сервисов, между собой они используют dapr сайдкар контейнеры, который инжектится при помощи оператора и сайдкар инжектора при добавлении параметра в values файле.
Ага, ну хоть что-то.
Смотрим а как вообще роутинг устроен:
- в пределах кубера
- за пределами кластера кубера
Внутри кубера через DAPR (ну то есть через SVC адрес), снаружи через кастомный ингресс контроллер с кучей стрёмных аннотаций и хидеров.
Давай, Алекс, решать, куда будем копать.
Логика самой первой ошибки подсказывает, что ошибка не на уровне ингресса.
И как бы мне не хотелось с кровью выкорчевать весь этот кастомный ингресс контроллер из левой репы и сделать "по нормальному", мне сейчас надо чинить сервис и траблшутить ,а не правда матку рубить и настраивать как по книжке.
ПлАчу, засовываю своё негодование в известное место и забиваю на ингресс, иду в сторону service сущностей кубера.

Что мы имеет на данный момент? В валуес файл добавили параметр, оператор добавляет сайдкар, другие сервисы обращаются по адресу service к падающему сервису и получают иногда(с*ка, да как так то??!) ошибку.
Причём рестарт пода помогает.

Методом наблюдательности глаз вижу, что у нас на самом деле ДВЕ проблемы.
Первая проблема - у некоторых подов, где параметр стоит, нет сайдкара.
Я совершенно не знаю как это случилось и почему и как такое детектировать.
Делаем рестарт пода - появляется сайдкар с dapr.
Чтобы "поиграться" в будущем с такими ситуациями, мне нужен алёрт, который будет это отслеживать и рапортовать мне в слак. Я увижу проблемную ситуацию и буду иметь возможность в реалтайме траблшутить.
Пишем алерт

- alert: DAPR_ibanni_1
  expr: |-
    (
      sum(kube_pod_annotations{annotation_dapr_io_enabled="true"}) by (cluster, exported_namespace, pod)
    ) unless (
      sum(kube_pod_container_info{container="daprd"}) by (cluster, exported_namespace, pod)
    )
  for: 5m
  annotations:
    summary: "DAPR sidecar is not running on `{{ $labels.cluster }}`/`{{ $labels.exported_namespace }}`/`{{ $labels.pod }}`"

Тут мы проверяем есть ли поды, у которых есть аннотация на сайдкар дапра и матчим это с подами, у которых нет сайдкар-контейнера с именем daprd(украл название из чарта). То есть если сайдкара нет, где он должен быть, я получу оповещение.

Вторая проблема, которую вижу - "что-то" "где-то" "как-то" происходит и перестаёт ресолвится.
Как такое детектировать? Оно же не всегда.
Идём в документацию кубернетиса. Читаем что же такое может случится, что адрес service есть, но ресолва нет.
Лейблы? Селекторы? Херекторы? Я не знаю.
Документация сходу ничего не подсказывает и вот тут я иду в нейронку и спрашиваю напрямую "какие бывают случаи, когда у меня дапр сайдкары и в какой-то момент времени service есть но ресолва нет". Помучав вопросами я понимаю, что проблема в kubernetes endpoints.
Получив ключевые слова от нейроники я снова ухожу в документацию кубернетис.
Оказывается если ПОД не реди, то из endpoints пропадает IP адрес POD и service в кубере перестаёт ресолвится.
Ура! Зацепка! Под нот реди.

Лезем в конфигурацию, тут есть и стартап пробы и лайвнесс и рединес.
Наша формула "что-то" "где-то" "как-то" приобретает очертания.
ПОД не проходит проверку лайвнес/рединесс пробы, меняет состояние на нод реди, его IP адрес удаляется из endpoints и ресолв перестаёт работать для ДРУГИХ сервисов по его имени service.
Пилим второй алёрт, чтобы детектировать (ну не буду же я постоянно сидеть с этой проблемой или ждать гневного письма босса).

- alert: DAPR_ibanni_2
  expr: |-
    kube_pod_status_ready{condition!="true", exported_namespace!="velero"} > 0
    and on (pod, exported_namespace, cluster)
    kube_pod_annotations{annotation_dapr_io_enabled="true"}
  for: 30s
  labels:
    severity: critical
  annotations:
    summary: "DAPR. No route to `{{ $labels.cluster }}`/`{{ $labels.exported_namespace }}`/`{{ $labels.pod }}`"

Тут я отсеял велеро, который за каким-то рожном сюда попадал и я просто отфильтровал его, даже не хочу и 0.0001мс тратить на траблшутинг ещё и велеро.
Теперь у нас есть два алёрта, которые как минимум мне просигнализируют раньше пользователей и коллег, что у нас беда.
Уходим на обед.
.
..
...
"Тревога, тревога, волк унес зайчат!" - кричит мне слак и я бегу с кухни в кабинет.
Попался, дапр тебя подери.
Вижу ситуацию, пишу коллегам в слак "всё под контролём, Алекс всё знает и чинит уже".
А проба не проходит, вот да, видимо по ивентам, по дескрайбу, по стейту.
В некоторых случаях есть даже рестарты, exit code НЕ 137/OOM - для ДРУГИХ подов с похожей проблемой.
А что в логах? А в логах у нас ничего.
Лезем к разработчикам, смотрим, что там dotnet и включаем debug левел прям для dev стенда, а что вы мне сделаете.
Уходим допивать чай.
.
..
...
Спустя время снова алёрт.
Методом метрик понимаем, что в целом проблема с 1-2 приложениями в кубере, они как бы core часть и к ним по servicename лезут другие приложения и если этот падает или недоступен - лежит весь продукт.
Уже есть логи и мы видим, что в логах у нас outofmemory.
То есть не на уровне kubelet/кубера, а на уровне приложения внутри.
Смотрим в графане CPU/Memory usage, фильтруем по имени деплоймента и видим исторически, что все без исключения ПОДы текут по памяти как барышни на концерте Энрике Иглесиаса.
Пишем разработке "мы вроде нашли проблему, у нас память течёт".
Они снимают дамп(а я не умею(((( и научится не успел, они сняли раньше) и уходят на перекур.
Спустя пару часов выкатывают фикс, несколько часов тестирования, смотрим по метрикам - всё ок.

Проходит ещё 1-2 дня и жалобы заканчиваются, алёртов тоже нет.

Проблема, при которой не работал ресолв, решилась.
Что было: приложение текло по памяти, ничего не писало в логи, его не убивали по ООМ, он просто переставал работать. Некорректные настройки liveness probes позволяли ему 503-ть при пробах, он переходил в not ready, его IP адрес пропадал из Endpoint k8s, переставал ресолвится по service имени, весь продукт падал.
Сейчас всё ок.
Количество реплик больше 1 на конкретно данном приложении сделать нельзя, оно не масштабируется, и даже стратегия там ReCreate. Ну вот такое приложение. Это не ко мне вопрос. Только 1 реплика.

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


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

Из плюсов:
- узнал про эту технологию
- написал лонгрид о чём я думаю в такие моменты и как работает моя голова
- очередной раз доказал самому себе, что стартовать траблшутинг с нейронки не стоит, она бы 10000% завела бы меня не туда. Потом пользоваться можно, но не со старта.
- починили приложение и всё начало работать стабильно
Минусы:
- опять потратил куча времени, никто не оценит человеко-часы таких погружений

#aws #rds
Короткий материал на уровне senior+

Нырни на самое дно. Без страховки.

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

Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.

Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.

innodb_flush_log_at_trx_commit
Значение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1

innodb_trx_commit_allow_data_loss
Значение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях

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

DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).

Ну и код для примера:

resource "aws_rds_cluster_parameter_group" "this" {
...
  parameter {
    apply_method = "immediate"
    name         = "innodb_flush_log_at_trx_commit"
    value        = "2"
  }
  parameter {
    apply_method = "immediate"
    name         = "innodb_trx_commit_allow_data_loss"
    value        = "1"
  }
}

#AI #мысли

Больше года активно использую AI в работе.
Не скрываю, пробовал почти все, от локальных до платных(писал выше и не раз).
Генерация документации, кодогенерация, написание тестов всех типов, авторевью, просто чат и поиск решений.

Все новости "нас заменят AI" читаю пока со скепсисом.
Умные работодатели об AI знают не хуже нашего и они просто начинают оплачивать подписку на AI-tools(CodeRabbit, Cursor IDE etc). Руководители знают, что AI умеют.

Нас, инженеров, не скоро заменят.
У нас появится больше работы, так как привычную/простую работу мы выполняем теперь заметно быстрее.

#пятница #мысли #AI

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

#aws #aurora #eks #troubleshooting #longread

Лонгрид "история одного бага".
Часть 1 из 3.

Веселье.
Жил был стартап. Сперва на пару человек, но уже в облаке.
Пару сервисов в ECS и база MySQL.
Всем было весело и интересно.
Со временем продукт вырос, у него появилось масса нового: новые микросервисы, postgresql(а потом была удалена), Mongo и так далее. Обычный жизненный цикл любого продукта.
Стартап перешёл из этапа pre-seed в seed.
Уже есть реальные живые пользователи, кто реально платит живые деньги за продукт.
Это привело к тому, что на инфраструктуре появилась нагрузка.
Из одноинстансовой базы был совершён переход на cluster Aurora(mySQL compatible), был добавлен RDS proxy(а я не знаю зачем изначально), а ECS заменён на EKS.
На самом деле много всего было сделано, но выходе в проекте был макросервис(наполовину распиленный монолит) монорепы и десятки микросервсов.
Потом пришла series a и клиентов появилось сильно больше.
Пришла НАГРУЗКА.

Масштабирование
Продукт, не смотря на то, что это макросервис и монорепозиторий, научили в масштабирование.
Сперва было тупое через HPA и ресурсы, затем появилась KEDA и продукт научился в масштабирование по количеству сообщений в SQS или лагу в кафка топике. Стало не хватать нод, добавили автоскейлер (впоследствии заменив на карпентер).
Да и в целом было сделано на 99% масштабирование и кластеризация всего и вся.
Где-то на этом моменте продукт начал получать весьма негативные фидбеки "ЧОТА ТОРМОЗИТ ИНОГДА" и команда впервые задумалась о мониторинге.

Observability, v1.
Была добавлена графана для инфры, прометиус в куб и опенсёрч для логов(вообще не связан с историей).
Помимо всей инфры в кубах, начали мониторить и алертить стандартные метрики всех ресурсов Амзаона.
невероятно обширная работа, от 60 дашбордов, больше 400 панелей в графане по всем ресурсам стандартных графиков.
И.. и это ничего не дало.

Не верю.
Команда ничего не понимала.
Да как так-то? Все метрики есть, дашборды украдены из интернетов, но любой случай "ЧОТА ТОРМОЗИТ ИНОГДА" по метрикам и графикам не видно.
Начали копать дальше, читать про базы данных, движки, прокси и многое другое.
Стартап вырос из своих штанишек, надо было пересилить себя и разобраться.
Сложность была в том, что никто не понимал что не так то. Откуда вообще копать.
Так же всё усложнялось тем, что нет времени на раскачку и траблшутинг, проблема возникает редко, а надо пилить новые фичи, люди ждут продукт, как и инвесторы.
Шли недели и месяцы. Многие думали, что это не проблема софта, а проблема Амазон. Не верю, картинно возражали они и шли дальше пилить код.
А затем пришёл series b и пришла даже не нагрузка, а НАГРУЗИЩЕ.
х800 трафик и количество от клиентов от того, что было месяц назад.
Проблема стала так же в сотни раз чаще и пришло время её фиксировать.

Observability, v2.
Команда научилась отслеживать slow logs и реагировать на них.
https://xn--r1a.website/makebreakreflect/33
Есть запросы больше 10 секунд? Изучаем query и катим фикс.
И так до тех пор, пока слоу логи не прекратились.
И.. это не решило проблему.

Кубер/хелм/девопс во всём виноват.
Обратили внимание, что частично проблема повторятся, когда идёт деплой или скейлинг.
Проверили всё, пробы, макссёрж, количество реплик, стратеджи, перешли на KEDA с детальнейшим конфигом, пофиксили пару серёезных багов со стороны не совсем корректной настойки проб.
https://xn--r1a.website/makebreakreflect/9
И.. это не решило проблему.