#troubleshooting #одинденьизжизни

Часть 2 из 2.

Собираемся удалять сертификаты..

Так, стоп-стоп, а почему у нас был алёрт по рестартам пода, но не было по протухшести сертификата?
Значит мы почему-то это не мониторим.
Пока время есть давайте настроим хоть какой мониторинг/алертинг, а то через года снова траблы будут постфактум.
Гуглим, читаем про метрики, но по факту для быстроты я просто добавил 1 endpoint в blackbox exporter

---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMProbe
...
spec:
...
  targets:
    staticConfig:
      targets:
......
        - https://opensearch-cluster.NAMESPACE.svc:9200

Смотрим появился ли этот хост и проверяем в Grafana explore

probe_ssl_earliest_cert_expiry{} < time() + 30 * 24 * 60 * 60

Супер. Метрика пошла, мы видим за что зацепиться, пилим алёрт (а у нас его и не было, блллл 🐒)

- alert: SSLBlackBoxExporter
  expr: probe_ssl_earliest_cert_expiry{} < time() + 30 * 24 * 60 * 60
  ...
  annotations:
    summary: "SSL `{{ labels.instance }}` is expiring in {{ .Value | humanizeDuration }}"

Алерт прилетает, всё ок, возвращаемся к сертификатам.
Не глядя удаляем все сертификаты, на которые была ошибка.

kubectl delete certificate  CERTNAME1 CERTNAME2 

Видим новые пересоздались(оператором, которые прочитал про пересоздания наш конфиг кластера).
Делаем рестарт подов мастеров

kubectl delete pod -l=opensearch.role=cluster_manager

и.. и ничего - та же ошибка.
Ладно, удаляем все серты, которые TLS и которые для опенсёрча.
Удалили, рестарт подов мастера и.. и та же ошибка TLS.

Ладно, мы же уже опытные инженеры, смотрим а что у нас с secrets?

kubectl get secrets

и видим, что секрет не был пересоздан.
Ну, скорее всего баг - удаляем и secrets и certificates( естественно только те, что связаны с TLS, другие секреты мы не удаляем), серты пересоздаются, секреты пересоздаются, делаем рестарт подов мастера и..
и снова та же ошибка.
Смотрим внутри мастер пода

kubectl exec -it -- bash 

- да, серт новый монтируется.

Чего мы имеем:
- у нас НЕТ сертификатов со старым сертом
- у нас НЕТ секретов со старым сертификатом
- в под мастеров монтируется новый серт
- у нас уже есть алерт ❤️
- НО у нас есть ошибка TLS при старте мастеров

Ну ведь магии не бывает, может быть эээммммээ может соседние поды - warm + cold +dashboards имеют проблемы с сертом?
Смотрим на рестарты - рестартов у них нет.
Смотрим в логи, блл, стактрейс, java и снова переворачиваем монитор вертикально 🐒 - та же ошибка с сертом, но рестартов уже нет.
Странная фигня, но ладно, публикуем в slack канале ЩА ЛОГИ БУДУТ НЕДОСТУПНЫ ПАДАЖИТЕ
и рестартим ВСЕ поды всего опенсёрча по общему лейблу

kubectl delete pod -l opster.io/opensearch-cluster=opensearch-cluster

Происходит рестарт всех 17 POD-ов и.. и проблема ушла.

Итог:
- у нас появился алерт по протухшести на будущее (есть другие, на nginx контроллеры, но тут, внутренний ресурс по 9200 не было 🤡)
- опенсёрч сволочь такая на java, у него под капотом какая-то магия, с протухшим сертом мастера делают рестарт, а остальные нет и серт нужен всем (я хз для чего, да мне и не интересно) и рестарт всем для перемонтирования
- мы разобрались чуток и можно списать время в трекер джиры
- научились мастерски крутить монитором как рулём авто

#helm #devops

Валидации, проверки, линтеры.
Как много мы о них говорим, но и как это иногда важно.

У меня есть helm chart.
После изменения любых параметров или темплейтов я его проверяю.
- unit tests (ооооооочень редко и не всем нужно)

helm unittest ./helm-chart

- linter

helm lint helm-chart

Дальше публикация и куда-то релиз.

helm package helm-chart

Чарт готов, чарт проверен в пайплайне и пре-коммит хуками.

А что с values файлами на стороне приложений?
У меня же есть прекрасные коллеги с ровными руками.
Они могут в values файлах своих репозиториев при использовании нашего общего чарта допустить ошибку.
Ну так бывает, все ошибаются.
Могут написать "true" вместо true, могут не там сделать indent или вообще половину indent(1/3).
Которые при любых проблемах обвиняют девопсов 😮🫵😮.
Как быть тут?

На помощь мне приходит schema validation.
То есть на базе template мы генерируем schema.yaml файл, по которому будет идти сравнение values.yaml файлов у коллег.

Для начала я потренируюсь на кошках и возьму классный чарт отличного продукта
https://github.com/cloudnative-pg/charts
Клонирую его себе

git clone git@github.com:cloudnative-pg/charts.git

Затем мне надо написать схему.
Буду ли я просить нейронки?
👎Да пошли они в хер, с ними голова вообще перестала работать.🐒
Буду ли я сам писать схему?
Да щас 🤣.

Иду в awesome helm репу, ищу есть ли чего у нас там для скима валидейшн.
https://github.com/cdwv/awesome-helm
Нахожу поиском там генератор (второй депрекейтед)
https://github.com/dadav/helm-schema
Читаю - всё ок, отлично подходит под мою задачу.
Качаю, распаковываю и так далее

wget https://github.com/dadav/helm-schema/releases/download/0.18.1/helm-schema_0.18.1_Linux_x86_64.tar.gz
tar -xvf helm-schema_0.18.1_Linux_x86_64.tar.gz
chmod +x helm-schema
sudo cp helm-schema /usr/local/bin/

Теперь иду в свой склонированный cnpg репозиторий

cd ~/GIT/INTERNET/cnpg/  #(у вас путь другой будет само собой)

и просто запускаю бинарь

helm-schema

Результатом будет json файл(ы) в каждом чарте.
Один из файлов выглядит так
https://gist.github.com/kruchkov-alexandr/dc4cf3e4ac9af5719fb435d42e1873e6

Чарт есть, генератор схема валидейшн есть, схема есть.
Осталось научиться проверять.

У меня есть три основных варианта использования схемы:
- подсунуть комментарии-аннотации в values.yaml
- в VSCode мышкой клацнуть на схему и сам vscode будет подсвечивать ошибки
- команда в терминале в CICD

Мне больше нравится последний вариант автоматизации.
Немного душноты:
- команда helm template генерирует(рендерит) YAML манифесты.
- если есть файл JSON со схемой, то helm template проверяет ещё и схему!

#helm #devops

Поехали проверять.

helm template alexk-test charts/cluster/

Всё ок, нет проблем, куча манифестов срендерилось.
Теперь иду в файл charts/cluster/values.yaml
и меняю

  endpointCA:
    create: false

на

  endpointCA:
    create: "false"

Снова запускаю и получаю ошибку

helm template alexk-test charts/cluster/
Error: values don't meet the specifications of the schema(s) in the following chart(s):
cluster:
- recovery.endpointCA.create: Invalid type. Expected: boolean, given: string

Отлично, у меня есть
- мой чарт/чарты
- автоматическая генерация схемы путем pre-commit и/или CICD команды схемы для чарта до релиза чарта
То есть когда мы что-либо меняем в своём чарте, то у нас и автоматическая проверка идёт и автоматически генерируется и в гите обновляется схема.

Дальше я свой общий pipeline для приложений коллег добавляю шаг helm template и он до релиза проверяет values.yaml файлы пользователей и коллег.

Так, а что у нас с GitOps ArgoCD подходом?
Ведь мы там не используем helm в чистом виде и нет понятия релиза.
Читаю документацию
https://argo-cd.readthedocs.io/en/stable/user-guide/helm/
Ура, под капотом ArgoCD использует как раз helm template, а значит мы при syncing увидим не просто ошибку, а ошибку в каком конкретно месте у нас ошибка.

Итог:
- в самом чарте появилась схема, к тому же она автоматически обновляется при каждом изменении чарта
- при использовании helm для релизов в моём pipeline я добавляю helm template для проверки корректности values.yaml файлов разработчиков
- в случае работы с ArgoCD у меня так же проверяется схема, снижая количество человеческих ошибок
- и со стороны чарта и со стороны репозиториев разработчиков есть pre-commit hooks (если на них забивают🐒)

Поздравляю - мы снова добавили какую-то очередную хероту автоматизацию и валидацию 🤣

#aws #devops #EKS #IRSA

На одном проекте пришла задача избавиться от IAM-кредов в подах и перейти на роли.

Есть три давно созданных EKS-кластера. Я написал Terraform-код: полиси, роль, policy attachment, service account, OIDC и всё остальное. Поправил Helm-чарт, добавив service account. Прокатил изменения по всем кластерам - всё ок.

На DEV я убрал IAM-креды из секретов, чтобы CDK перешёл на роль - всё ок. Сто раз всё проверил: секреты почистил, аппликейшены передеплоил, в AWS-консоли видно, что роль используется, IAM-креды - нет. Удалил IAM для DEV - всё работает. Повторил на STAGE - тоже всё ок.

И тут прод. Удалил креды - и всё рухнуло к чертям. Поды начали использовать роль ноды 🤡, у которой, естественно, нет доступа ко всем ресурсам AWS. Вернул креды, откатил, прод поднял, получил по щщам и начал дебажить.

Сто раз перепроверил Terraform-код - всё идентично. Проверил OIDC, IRSA, роли - всё совпадает, проблем нет. Но почему-то на проде поды не берут нужную роль.

Нырнул в документацию и пошёл шаг за шагом. Это был скучный этап, просто читал, как всё это работает в кишках. Через пару часов упёрся в мутейшн хуки.

Проверил mutatingwebhookconfigurations:
dev

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook                   

stage

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
pod-identity-webhook                   

prod

kubectl get mutatingwebhookconfigurations | grep pod-identity-webhook
hui

Кто-то (или что-то) когда-то как-то удалил pod-identity-webhook на проде. Как так вышло - история умалчивает, это останется тайной. Жаль только часов дебага, когда я матчил код, роли, OIDC и IRSA, не подозревая, что мутейшн хука просто нет. 🚶‍♀
Что делает этот вебхук? (текст украден из чата кубера):
- Добавляет переменные среды:

AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount
AWS_ROLE_ARN (значение берётся из аннотации к SA)

Добавляет в волумы:

- name: aws-iam-token
  projected:
    defaultMode: 420
    sources:
    - serviceAccountToken:
        audience: sts.amazonaws.com
        expirationSeconds: 86400
        path: token
...
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
  name: aws-iam-token
  readOnly: true

И всё. Дальше куб сам выписывает SA-токен с aud: sts.amazonaws.com.

Принял быстрый фикс:
Установил cert-manager (если его не было):

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.18.2/cert-manager.yaml

Склонировал и развернул:

git clone https://github.com/aws/amazon-eks-pod-identity-webhook
cd amazon-eks-pod-identity-webhook
make cluster-up IMAGE=amazon/amazon-eks-pod-identity-webhook:latest

Проверил логи:

kubectl logs -n default -l app=pod-identity-webhook

Запустил тест:

kubectl run irsa-test --image=amazon/aws-cli -n production --overrides='{"spec":{"serviceAccountName":"new-sa"}}' --command -- sh -c "aws sts get-caller-identity && sleep 3600"

Получил:

{
    "UserId": "54252523:botocore-session-2345452354",
    "Account": "2345452345",
    "Arn": "arn:aws:sts::234534524:assumed-role/expected-new-role/botocore-session-345235"
}

Ура, теперь поды используют новую роль. Убил тестовый под. Удалил IAM-креды, накатил снова - всё ок.
Задача решена.🎉

.....
Прошло пару дней.
.....

Сижу, значит, пишу этот текст-заметку, пока не забыл, и задумался: неужели такое возможно в 2025? Зачем? Зачем, мистер Андерсон, вообще руками что-то ставить в кластер, kubectl apply -f??

Читаю за утренним кофе документацию, пока жена не видит:
- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
- https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html
Дошёл до:
- https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_pod_identity_association
.
..
...
Прочитал, промолчал, набычился, посмотрел на пол, закатил глаза, надел kubectl apply -f клоунский нос 🤡 и отправил пост в телеграм.

#azure #docker #opersource

OpenSource. Latest. Apache.
Да, пусть заметка называется Apache.

Прихожу на работу, а там десяток алёртов жалоб пользователей и всё UI нерабочий.
Просто не работает, и никаких алёртов.
Ладно.

На этом проекте уже не первый день, знаю, что в кишках там внутри проекты с Apache SuperSet.
https://superset.apache.org/
Иду в UI - да, какая-то ошибка (неизвестная мне). Ошибка говорит проблемы с подключением к каталогу Trino
https://trino.io
По ссылкам можно зайти, только если это интересно, в целом хватает триггера - Apache.

Ошибка говорит о том, что невозможно подключится к trino по http(а его и нет), везде написано https(только он и есть).
Явно баг.

Иду в кубернетис, там у нас и трино и суперсет.
Методом тыка и быстрого анализа узнаю, что проблема не везде - не на всех инстансах SuperSet.
Там, где утром был автоматический апдейт AKS кластер(спасибо за неотключаемый секьюрити патч, мистар Ажур), есть проблема. Где апдейта не было - всё ок работает.
Смотрю как устанавливается суперсет - везде хелм чарт и точное указание версии чарта.
Ну пусть будет версия 3.0.0.
Но проблема есть и не стоит закрывать глаза на интуицию, что это пока Apache.
Смотрю откуда тащится чарт и приходим к GitHub, на то и опенсорс.
https://github.com/apache/superset/blob/3.0.0/helm/superset/values.yaml#L178
Сук, as is это приведёт к latest тегу.

Бегу сравнивать SHA имаджей на SuperSet где работает и где не работает.
Всё так, имаджи разные. 🤡 Хотя чарт одинаковый, как и values.yaml
Быстро пушу имадж работающий в внутренний реджистри, чтобы не проетерять в суете.

Для того, чтобы не аффектило юзеров просто меняем image путь вместо дефолтного - на внутренний registry с некрасивым tag в виде sha.
Работа сервиса восстановилась, ошибок нет, пользователи больше не кидают кизяки в нас/меня.

Есть время потраблшутить: а ну и чего у нас в докерфайле
https://github.com/apache/superset/blob/3.0.0/Dockerfile
Сук, красота с pip install но вроде не в этом дело.
Не понимаю, отупел с облаками🐒, натравливаю нейронку на репу, она говорит мне про
https://github.com/apache/superset/blob/3.0.0/setup.py
Ага, значит у нас где-то есть прикрученная к забору версия, а где-то нет. Красиво.
Предполагаю в этом причина
https://github.com/apache/superset/blob/3.0.0/setup.py#L177

Начинаю гуглить по всем связанным репозиториям(чтобы сократить вероятность, что копну не туда), хотя я мог бы это сделать с самого начала и не ковыряться в докерах шмокерах.🤡
https://github.com/trinodb/trino-python-client/issues/557

То есть проблема не в самом суперсете, а сторонней библиотеке, которая ставится через trino>=0.324.0 и тянет за собой ещё и клиента само собой. И при каждом обновлении докеримаджа для трино каждый раз пере собирается новый, сук, имадж, который по latest идет к ЛЮБОЙ версии чарта.

Варианта у нас два(нет, больше, но пусть будет проще так):
- ждать исправление бага и нового чарта хелма от суперсет
- перетащить всё к себе и впоследствии менеджить самому

Ещё раз с коллегами оценили опенсорс, риски и решили перетащить докерфайл к себе.
Создаю новый репозиторий, пихаю туда докерфайл, пайплайн для CICD со сборкой имаджа и публикация по тегам во внутреннем реджистри, requriments.txt

Докерфайл простой (тут уже версия выше, но это другая история)

FROM apachesuperset.docker.scarf.sh/apache/superset:4.1.2
USER root
COPY requirements.txt /app/requirements.txt
RUN pip install -r /app/requirements.txt
USER superset 

Открываю тот самый рабочий supserset имадж, и командами docker run ... смотрю версии библиотек (вроде команда pip list).

Копирую всё оттуда, хардкорю версии в requirements.txt ровно то, что было в рабочем образе.
Локальная сборка, тест, коммит, пуш, тегируем 0.0.1.

Сперва dev, потом stage/uat/prod - меняю путь до локального реджистри и тега.
Проблема решена и ура, теперь у нас + новый форк имаджа.

#azure #docker #opersource

В последствии оказалось, что это было на 100% верное решение, потому что у библиотек выходило ещё пару багов и были проблемы другие, а так менеджить свой докерфайл это удобнее, потому что можно добавлять свои библиотеки.
Например штатно ни в одной из версий SuperSet не хватает psycopg2 🐒
Да, это можно добавить в bootstrap, но потом мы захотели включить алертинг, а это подтянуло ещё и selenium webdriver и многое многое другое.
https://superset.apache.org/docs/configuration/alerts-reports/
Удобнее в форке держать и это ок.


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

Как узнать есть ли у тебя новая таска?

- прочитать в новостях https://github.com/bitnami/charts/issues/35164

- похихикать над картиночками https://xn--r1a.website/devops_untraveled/1879

- нахмурить брови и проверить у себя на проде

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep bitnami | wc -l

36

ну или точнее таргеты

kubectl get deployment,statefulset,daemonset,job,cronjob --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.kind}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep bitnami

- осознать, что часть напрямую чарты, а часть просто депенденси (Redis🐒) и теперь предстоит масса работы

- сказать "штош" и пойти дальше это перепиливать, ну а чё делать ещё

#пятница #aws #всратость

Буквально на пару дней был недоступен для работы.
В это время разработчикам срочно надо было для тестов фичи создать 3 бакета в 3 регионах:
us-east-1(default), us-east-2, ca-central-1.
Вообще для этого есть модуль, просто регион указать, однако они сделали по своему и клик-опсом.
Накатили, проверили, сдали бизнес-заказчику, написали всем "фича работает и проверена на бакетах в 3 регионах!".
Запилили мне таску "добавить бакеты импортом в терраформ.

Возвращаюсь на работу - вижу это 😀

#azure #всратость #troubleshooting

Утро, вторник, кофе, трёп.

Прилетает ишшуя от кастомера - не работает %фигнянейм%.
Лог приложений говорит о каких-то несовместимых полях и параметров с API MS Teams/Azure.

Традиционно проверка:
- не менялись ли переменные в коде аппликейшна
- зафиксирована ли версия base имаджа в Dockerfile
- зафиксированы ли версии библиотек
Всё ок.

Ладно. Гугл, реддит, QA Azure, нейронки.
Внезапно(!) обнаружили, что с 31 июля 2025 года multitenancy bot депрекейтед. 🤡
Ни уведомлений, ни анонса, ни писем, ни RSS, ни уведомлений в Azure console.
Ни-че-го ни-как и ни-где.

Есть несколько упоминаний: в официальной документации в сноске и community нытинг-форуме:
- https://learn.microsoft.com/en-us/azure/bot-service/bot-service-quickstart-registration?view=azure-bot-service-4.0&tabs=multitenant#bot-identity-information
- https://techcommunity.microsoft.com/discussions/teamsdeveloper/what-is-the-recommended-bot-type-for-multi-tenant-bots/4420239

Как так-то?? В чём сложность уведомить клиентов, что функционал будет скоро депрекейтед??
Подписке 4 года, боты уже 3 года.
Всратое облако, конечно.
Даже у AWS все предупреждения через почту, всплывающие окошки, куча нотификаций, слак и бьющиеся в окно голуби с инфой, что пора обновить EKS.

А, ну да - почему так произошло, почему только 5 числа?
Да просто это редкий функционал(интеграции), в пятницу 1 числа никто не использовал это, два дня выходные, в понедельник никто не раскачался, а во вторник отстрелило коленные чашечки функционалу фичи, который создавал ажур ботов.

Ну и всё, фича не работает.
Аригато, ажур штопанный.

#всратость

Приходят ко мне недавно

"мы тут придумали на коленке в метро и за два дня внедрили AI!AI!AI!AI!AI!-voice сервис, всё уже продали клиентам, уже даже заработали с него, а ты нет(лох), и поняли, что твой кубервсратос всё ломает при деплое/редеплое и связь рвётся, это всё твой кубер виноват, чини скорее, ЕТА на завтра, а то мы клиентов теряем".

Грубо говоря ситуация такая:
2 Пода в кубере.
Они/через них организуют 1 голосовой звонок.
2 пода - просто реплика. Можно сделать и 1, не принципиально.
Звонок идёт - всё ок.

Разработчики запилили релиз.
Во время релиза в кубер у нас rolling update strategy.
Когда новый под поднялся, старый завершился.
И звонок прервался.
Звонок не должен прерываться.
Это и есть проблема.

У меня очень плохо с многими областями в айти.
Чуток почитал про фреймворки, воип, сип и многое другое с голосом
Ну как почитал - спросил нейронку "все про войс за 7 абзацев". 😁
Да не, вру, я многое про войс и так знал.

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

Кишки привели меня к
- https://docs.livekit.io/
- https://github.com/livekit/python-sdks

Дальнейший совместный поиск привел к такому ОФИЦИАЛЬНОМУ решению
https://docs.livekit.io/home/self-hosting/kubernetes/#graceful-restarts

During an upgrade deployment, older pods will need to be terminated. This could be extremely disruptive if there are active sessions running on those pods. LiveKit handles this by allowing that instance to drain prior to shutting down.

И самое сладкое ❤️

We also set terminationGracePeriodSeconds to 5 hours in the helm chart, ensuring Kubernetes gives sufficient time for the pod to gracefully shut down.

Ставим таску на on-hold, отписываем это как временное решение и трекаем время за траблшутинг.

Какие времена, такой софт и такие решения... 😀