В продолжении предыдущего поста оставлю тут парочку вопросов, на которые я не услышал ответ... ни разу? Ну может пару раз что-то приблеженное к ответу...

Вопрос 1: Чем отличается HTTP/1 от HTTP/2? (а иногда я спрашиваю и про HTTP/3, но, честно, на HTTP/2 уже никто не отвечает)
Комментарий: Хотя бы раз кто-нибудь сказал бы про двоичность в http2. Но нет. Все мимо. Все отвечают: "HTTP2 быстрее работает", а почему - никто не понимает.

Вопрос 2: Можно ли в Kubernetes создать поды, которые нельзя удалить через Kubernetes API?
Комментарий: Залочить удаление pod'a можно многими путями. Finalizers, Admission Controllers (Validation Webhook, который отлавливает DELETE POD события и лочит их). А еще есть static pod'ы, но все говорят куда-то мимо.

Вопрос 3: Что такое Pause Container и зачем он нужен?
Комментарий: Тут самая магия. Все знают, что есть такой монстр, как Pause Container, но никто не понимает на кой черт он нужен(

#zvlb_musle

Думаю все концептуально понимают чем отличается nginx (или angie) restart от reload. Но все же давайте разберем отличия и подводные камни.

Базово:
systemctl restart nginx - по сути делает stop → start.
То есть Nginx Master процесс получает сигнал SIGTERM, что приводит к моментальному убийству всех воркеров. Клиенты активных на момент рестарта соединений получают ошибки Connection reset

nginx -s reload в свою очередь отправляет Master процессу сигнал SIGHUP. Nginx Не убивает Master и его Worker-процессы, а стартует новый Master с новой конфигурацией, который начинает обрабатывать все новые соединения. Старые процессы завершаются только после обработки всех актичных соединений (graceful shutdown).

Но самое интересно происходит на "пограничных" ситуациях.
Что будет происходить, если у вас есть запросы с долгими (условно вечными) соединениями? (websocket? gRPC?)
А если у вас часто изменяется конфигурация и часто выполняется reload?

А будет следующее:
1. Старые воркеры не завершатся, пока клиенты не закроют соединения.
2. Будут запускаться новые воркеры с обновлённым конфигом.
3. Итог: В системе теперь два набора воркеров — старые (с висящими соединениями) и новые (для новых запросов).

А если делать reload каждую минуту? Через час у вас будет 60 наборов воркеров, жрущих память и CPU. Красота)

Возможные решения:

1. Настроить пару параметров для обработки долгих соединений:

proxy_read_timeout 1h;  # Закрывать соединение, если данные не приходят час.
keepalive_timeout 10m;  # Не давайте соединениям висеть сутками.

2. Если обрывы долгих соединений приводят к проблемам в эксплуатации - это на 99.9% проблема кода и обработки разрыва соединений.

3. Если вам действительно нужно часто делать reload возможно стоит вынести изменяемые параметры в Lua

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

Почитать подробнее про обработку Nginx'ом различных сигналов можно ТУТ

#nginx #zvlb_article

Решил закрыть тему собеседований (хотя может и не закрыть) списком своих вопросов, которые я люблю спрашивать про Kubernetes.

Раньше я задавал довольно прямые вопросы из личного типичного списка вопросов. "Из каких компонентов состоит Control Plane?", "Как контролировать использование ресурсов для контейнеров?", " Что такое CRI?".
Все это - скучные вопросы, которые можно позадавать Junior-специалисту. Однако все у нас тут Senior'ы и о реальном уровне знаний ответы на эти вопросы ничего не скажут)

Вот мои вопросики:
Что происходит под капотом, когда пользователь Kuberentes выполняет команду `kubectl apply -f manifest.yaml`, если в применяемом манифесте описан Deployment?
Отвечая на этот вопрос мы сразу понимаем представление кандидата о компонентах Control Plane и их взаимодействии. Копая глубже по каждому пункту можно найти границу знаний кандидата. Куча дополнительных вопросов по пути можно задать:
- А что если манифест был написал с ошибкой?
- Аутентификация? Авторизация?
- А как именно Deployment-контроллер узнает, что появилась новая запись с Deployment в etcd?
- А как Scheduler выбирает ноды?
- Как kubelet на нужной ноде узнает, что ему надо развернуть контейнеры?
- CSI? CRI? CNI?
Это не вопрос, а кроличья нора)

Представьте, что вы устроились в новую компанию, где только собираются внедрять Kubernetes. Вам пришла задача настроить Kubernetes и все нужные для него компоненты, чтобы с ним было удобно работать. Что вы установили в свой Kubernetes?
Тут тоже кроличья нора. Тут мы узнаем с какими задачи в Kubernetes кандидат работал и как их решал. CNI? Mash? Авторизация? Логирование? Мониторинг? Интеграция с Continues Delivery интрументами? И т.д.

Пользователь Kubernetes развернул в кластере набор манифестов. Все прошло успешно и он ожидает, что по определенному URL будет доступен сайт. Однако сайт не открывается. Что могло пойти не так и как найти проблему?
Тут мы смотрим как кандидат будет дебажить проблему и перечисляя возможные ошибки будем понимать с какими ситуациями тот сталкивался и как их решал.

Что такое Service в Kuberentes и как работает?
Единственный прямой вопрос про Kuberentes, который я задаю. Ибо он максимально веселый и иногда я слышу от кандидатов суперскую трешанину. + Тут можно поспрашивать про eBPF и узнать мысли на эту тему.

#zvlb_musle #собеседования

Когда интегрируешь Gitlab и Kuberentes с помощью Gitlab Agent'а одна из основных проблем, которую надо решить - это выдача доступа конкретному репозиторию, который использует agent, в кластере Kubernetes.

Если правильно настроить агент, то, при исполнении каких-либо запросов в KubeAPI, они будут имперсонироваться и запрос будет исполняться от Username gitlab:ci_job:<JOB_ID>, а в Groups будет куча информации по проекту. Например ID проекта (gitlab:project:<PROJECT_ID>) или группы в которых проект состоит (gitlab:group:<GROUP1_ID>, gitlab:group:<GROUP2_ID>). И чтобы Job мог выполнить какие-то запросы в KubeAPI - ему необходимы права.

У Gitlab'а не было никаких инструментов, чтобы такие права выдавать, по этому мы костылили как могли:
- Парсили конфиги Gitlab Agent'ов, доставая от туда IDшники заинтегрированных репозиториев
- Ходили в это репозитории и доставали от туда member'ов уровня выше developer
- Подвязывались на системные webhook'и Gitlab'a, чтобы ловить события изменения member'ов проекта или добавления нового проекта в группу, к которой привязан Gitlab Agent.
- Автоматом на всей собранной информации генерировали Tenant'ы и раздавали нужные права в этих tenant'ах как для пользователей (Devops/Dev команды), чтобы у них доступ был, так и для системных учеток, (тот самый gitlab:project:<PROJECT_ID>) от которых шел деплой.

Мы несколько раз переделывали эту схему. Специально интегрировали самопальный DEX, который при авторизации пользователя в Kuberentes собирает в каких группах в Gitlab'e тот состоит, что бы не собирать эти группы при генерации тенантов и разгрузить Gitlab API. Еще что-то... Еще что-то...

Но, похоже, наши боли подходят к концу, т.к. во вчерашнем (20.02) релизе Gitlab'a наконец-то добавили Gitlab-managed Kuberentes resources. Теперь при интеграции Gitlab Agent'a с каким-то репозиторием можно определить какие-то ресурсы, которые будут автоматои созданны для этого репозитория. (Namespace, RoleBinding, Flux Resources). Функционал, который мы внедрили с Dex'ом в нашей схеме все равно остается важным, но все автоматизацию по созданию ресурсов наконец-то, можно будет удалить.

Почитать подробнее про новый функционал можно тут. В общем - УРА

#zvlb_musle #Kubernetes #Gitlab

Продолжаем про базу. Про виртуализацию вспомнили, а чтобы понять что такое контейнеризация надо разобраться в 2 понятиях: Cgroup и Linux Namespace.

Начнем с Cgrouр. По ссылке статья на эту тему)

https://zvlb.github.io/blog/containerization-cgroups/

#zvlb_article #containerization #cgroup

С 1 апреля 2025 года все пользователи с подписками Pro, Team или Business получат неограниченное количество запросов (pull) в Docker Hub с условием добросовестного использования. Для неаутентифицированных пользователей и пользователей с бесплатной личной учётной записью (Personal) действуют следующие ограничения:

Неаутентифицированные пользователи: 10 запросов в час.

Аутентифицированные пользователи с бесплатной учётной записью: 100 запросов в час.

https://docs.docker.com/docker-hub/usage/

Я и с лимитами, которые сейчас, и проксирующе-кеширующим нексусом периодически встречаю чертову ошибку:

toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Видимо ошибку буду встречать чаще... Надо хотя бы все свои проекты увести с Docker Hub'a. Ибо бесят...

#zvlb_musle #docker #news

Ну и заканчиваем с темой Контейнеризация.

С Виртуализацией разобрались. С Cgroup'ами тоже. Остались Linux Namespace. О них и поговорим.

https://zvlb.github.io/blog/containerization-namespaces/

#zvlb_article #containerization #linux_namespaces

Нас тут собралось уже 110 человек. Спасибо.

А ведь именно эта цифра указана в инструкции по настройке больших инсталяций Kuberentes как число подов на ноде, которое желательно не прeвышать. Но почему?

Например в одном из управляемых мной baremetal Kubernetes недавно был поднят этот лимит до 500 подов на ноду и из наблюдаемых проблем немного отстреливает в колено только PLEG (об этом как-нибудь отдельно поговорим, но если интересно, то вот ссылка раз, а вот ссылка два), но до 300х подов вообще никаких проблем не наблюдается. Так почему 110? Откуда это число?

Если посмотреть историю коммитов в инструкцию по настройке Large Kuebrnetes кластеров - увидим, что изначально рекомендовали 100 подов на ноду, а потом обновили до 110 с комментарием:

Это обновление изменяет рекомендацию "pods-per-node" в соответствии с настройкой Kubernetes по умолчанию, которая составляет 110 подов на узел.

Значит нам надо посмотреть почему у kubelet'а в дефолте стоит 110. Копаем-копаем и приходим к тому, что значение 110 было установлено 15го Июля 2017 года с очень конструктивным комментарием: f

То есть на всех устанавливаемых кластерах Kubernetes по дефолту стоит ограничение 110 pod'ов на ноду. И это значение не рекомендуется превышать... Потому что... f. Вот почему :)

Недавно в одном из чатиков (коих орда и маленькая тележка) активно обсуждали работу Kubernetes Informer'ов.

Решил акутализировать одну из своих статеек про Kuberentes Infofmer'ы. C описанием функционала и примерами кода на Go, как с этим работать.

https://zvlb.github.io/blog/kubernetes-informers

#Kubernetes #Informers #zvlb_article

За более чем 10 лет в моем EverNote Notion Obsidian скопилось очень много всякого говна связанного с работой. Некоторое из этих говн я решил немного переформатировать и выкинуть сюда, ибо... почему нет?

Когда-то давно я делал внутренные runbook'и для алертов, чтобы у людей, которые видят алерты сразу была информация, что эти алерты значат и как на них реагировать. Сначала я хотел продублировать свои наброски, но зачем? Начиная с 2021 года команда разработчиков Prometheus публикует свои RunBook'и, которые поддерживает сообщество.

Хорошая практика, если вам не хватает какого-то алерта сделать одно из двух:
- Определить, что этого алерта не хватает всему сообществу и сделать MR в kube-prom-stack
- Если алерт сильно кастомный - сделать для него небольшой RunBook во внутренней системе хранения знаний и привязать его к алерту

#zvlb_musle

Проводил сегодня очередной внутренний митап посвященный ArgoCD.
- Как работает
- Из каких компонентов состоит
- Как сделать HA развертывание
- Узкие места при масштабировании и как с ними работать
- Как настроен Git-репозиториц, с которого катятся все наши инфраструктурные компоненты на кластера.

Отличный получился митап. Вопросики все позадовали. Всем понравился.
Пошел монтировать его, чтобы выложить на ютубчик без всякого лишнего. А я это... Ну это... Запись не включил, короче (((

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

Например как виртуалки в кубе поднимать:
https://youtu.be/MYqarfqiXok?si=_YzdzsGHCzocZqSb

Или вот небольшой плейлист, посвященный Platform Engineer:
https://youtube.com/playlist?list=PL8iDDHqmj1oUyQZ2zUKJX_qFepwYV2lCh&si=zDovKBWg8gfqjnPd

Вспоминая различные Youtube-каналы, по которым можно учиться Devops технологиям я совсем забыл самого главного (для меня) индуса, который много лет подряд рассказывал про кучу технологий.
Жалко, что у него уже 4 месяца нет новых видео, сравнивая с его старым темпом - считай забросил канал, однако я уверен, что почти каждому найдется что-то интересное.

https://www.youtube.com/@justmeandopensource

P.S. Заупстить Doom в Kuberentes, чтобы при отстреле монстров умирали pod'ы - это классика хаос-тестирования

Grafana OnCall - все. Поигрались 3 годика, и хватит)

Grafana Labs объявила, что с 11 марта 2025 года OnCall (OSS) переходит в режим maintenance, а через год и вовсе отправится в архив. Для тех, кто, как и я, уже обжёгся на его настройке, это не стало неожиданностью.

Для начала пару моментов, почему, по моему мнению, OnCall не взлетел:
1. Зоопарк зависимостей
Для работы требовались Grafana, MySQL, Redis, RabbitMQ, а ещё — куча времени на их интеграцию.
2. Сложность настройки уведомлений
SMS и push-нотификации зависели от Grafana Cloud, что убивало идею self-hosted.
3. Отсутствие удобных и знакомых подходов
Лично меня сильно оттолкнуло 2 года назад, что у алертов не было никаких label'ов, по которым их можно было бы группировать и объеденять. После моих тестов этот функционал был внедрен, но для меня - уже было поздно. Первое впечатление - негатив
4. Деньги
По факту никто не отказывется от OnCall's. Просто он станет частью Grafana IRM, для пользования которым надо... Заплатить. ТО ЕСТЬ! Эти ребята выкинули в OpenSource сырой продукт. Подкрутили его вместе с сообществом, Чтобы он стал удобным, и мигрируют его в свой Cloud на платную основу. КРАСАВЦЫ! (Да. Вы можете форкнуть OnCall и самостоятельно вести его развитие, но каммон...)

___

Что значит «maintenance mode» для пользователей?
- До 24 марта 2026 OnCall (OSS) будет получать только критические фиксы (CVSS ≥ 7.0).
- Мобильное приложение IRM перестанет работать с self-hosted OnCall через год.
- SMS и push-уведомления отвалятся, так как они завязаны на Grafana Cloud.

Grafana предлагает перейти на Cloud IRM — гибрид OnCall и Incident с «единым интерфейсом». Но если вы, как и я, не хотите зависеть от облака - это не выход.

В общем, для тех, кто как и я особо не двигался с AlertManager-стека все круто. Не двигаемся дальше ;)

#zvlb_musle #grafana #oncall

Чисто я)

Вырезка с внутреннего митапчика, где я очень тихо рассказываю про Kuberentes Garbage Collector

https://www.youtube.com/watch?v=1rHMrBCCOpk

#zvlb_video #Kubernetes #garbage_collector

Тут в Nginx недельку назад приехал занимательный MR - https://github.com/nginx/nginx/pull/567

Суть его простая - добавить в дефолтные страницы ошибок Nginx переключение между светлым и темным режимом в соответствии с системными настройками.

Так вот. За эту веселую неделю этот MR закрывали уже раза 3. Потом переоткрывали и возвращались к обсуждению. Все начиналось более-менее лояльно, если не учитывать как "вызывающе" автор оформил сам MR, но в какой-то момент все скатилось в пассивную агрессию и личные оскорбления.

Люблю OpenSource ❤️

Вы можете наблюдать за этой веселухой практически в прямом эфире. Последний комментарий был 4 часа назад и не факт, что он последний. Вот вам пару цитат:

Do not tell me to stop. It's not your prerogative to tell me what to or not to do. Despite your interpretation, I'm not causing harm here.

No, I was planning on shutting up because you're rude and disrespectful. You seem hellbent on continuing that course.

And again, if you take one thing out of this conversation, it's that it is wholly inappropriate to tell a person who is attempting to have a civil discussion to stop or to gaslight them by telling them what they do or do not care about.

Долгое противостояние закончилось тем, что команда Nginx закрыла комментарии к PRу.

Эта битва была легендарной!

Учитывая страстный и жаркий характер этого обсуждения, мы решили закрыть комментарии к этому PR

2 дня назад Cloudflare представило AI Labyrinth — новый метод противодействия, который использует сгенерированный ИИ-контент для замедления, дезориентации и истощения ресурсов AI-краулеров и других ботов, игнорирующих директивы «не сканировать». При подключении функции Cloudflare автоматически развертывает набор связанных ИИ-сгенерированных страниц при обнаружении подозрительной активности ботов, без необходимости для клиентов создавать собственные правила.

AI Labyrinth доступен на добровольной основе для всех клиентов, включая пользователей бесплатного тарифа.

https://blog.cloudflare.com/ai-labyrinth/

У Ingress NGINX (который от сообщества Kuberenetes, а не от NGINX) вчера вышел релиз, на которой реально надо переезжать, т.к. он фиксит 5 жестких CVE, один их которых с рейтингом 9.8 (из 10. Это много. Очень)

В блоге Kuberentes есть небольшая статья на эту тему. Так же на Github есть репозиторий, где есть примеры как проэксплуатировать этот баг. (Там есть пара ошибок, но наглядко видно в чем проблема). Если вкратце - любой, у кого есть доступ к сетке pod'ов - есть возможность создавать ingress'ы. Причем обычные network policy вам не помогут, т.к. для создания ingress'а нужен доступ к namespace где развернут ingress-nginx, а все обычно дают фулл сетевой доступ к этому namespace.

Если вы, как и я, не можете по какой-то причине быстро обновить ingress-nginx есть пару лайфхаков, которые временно вас обезопасят:
1. Отключите validation webhook у ingress-nginx нафиг вообще. Именно через него эксплуатируется уязвимость.
2. Если не можете отключить - настройте networkpolicy, чтобы в namespace с ingress controller'ом нельзя было достучаться к Webhook port'у ни у кого, кроме kube-system (от туда Kuberentes API будет стучаться для валидации ресурсов)

#zvlb_musle #cve

Забавно, что F5 (компания, которая владеет NGINX) пришлось в блоге написать целую статью, что они не имеют никакого отношения к этим CVE и у них лапки :)

https://www.f5.com/company/blog/nginx/which-nginx-ingress-controllers-are-impacted-by-cve-2022-4886-cve-2023-5043-and-cve-2023-5044

Cloudflare не останавливается в радостях и интересностях для IT-сообщества.

Пару дней назад в своем блоге они представини новый tool - OPKSSH.

Мы уже давно привыкли на все системы подряд заходить используя OpenID Connect (OIDC). Причем это касается как корпоративных порталов, где используется внутренний SSO, так и всяких внешних систем, где вы можете авторизоваться с помощью, например, google-почты.

В общем теперь можно настроить аутентификацию по SSH на сервера с помощью OIDC. ОГОНЬ

#it_news #ssh #oidc