Как работает Garbage Collector в Kubernetes? Чем он занимается? Какие механизмы лежат в его основе? Как его можно ускорить?
В новой статье я ответил на все эти вопросы, рассмотрел нюансы работы GC и дал практические рекомендации.

Читать вот тут: 🔗 zvlb.github.io/blog/kubernetes-garbage-collector

#Kubernetes #golang #garbage_collector #zvlb_article

Grafana в рамках своей GrafanaCON проводит прекрасное мероприятие - Golden Grot Awards

Golden Grot Awards - это конкурс среди пользовательских DashBoard'ов. И он прекрасен тем, что можно оценить как и кто использует Grafana в различных целях (не только IT)

Например в 2024 году победили dashboard'ы для контроля качества стальных сплавов и аналитика состояния погоды/трафика/рассписания поездов и т.д. для быстрого анализа как лучше добираться на работу.

Ну и на фоне всего этого решил выложить свой Dashboard по Kubernetes, который состряпал где-то год назад и неимоверно ему рад - вот он)

#Grafana #Kubernetes

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

Все давно натренировались на вопросы по Kubernetes. 70% кандидатов легко отвечают на классические вопросы, ответы на которые можно найти в курсах Mumshad’а (которые, похоже, прошли все). Но настоящее собеседование начинается, когда мы углубляемся дальше.

У меня есть классический вопрос:
“Как вы интегрируете свой GitLab (Jenkins/TeamCity) с Kubernetes?”

И тут начинается крах.
- Только ~20% кандидатов вспоминают про интеграцию по сертификатам (которая, кстати, депрекейтнута уже три года!).
- 0% знают про официальный подход, который пропагандирует сам GitLab — GitLab Agent.

Но самое страшное — это то, как люди реализуют доступ GitLab’а в Kubernetes:
1. GitLab Runner с Kubernetes Executor — и ему просто дают Cluster Admin права.
2. (ТОП-решение) — на Control Plane ноде запускают GitLab Runner с shell executor, а job деплоя копирует манифесты на ноду и применяет их напрямую с админским kubeconfig’ом.

Это жесть. 😅

#трэш #Gitlab #Kubernetes

В канале про GitOps (@gitops_ru) периодически возникает вопрос:
“Что лучше: развернуть отдельный ArgoCD в каждом кластере Kubernetes или использовать один централизованный ArgoCD для всех кластеров?”

По умолчанию в чате ответ всегда один — используйте Flux (fluxcd.io) 😅

Но лично я придерживаюсь второго подхода: у меня в контуре централизованный ArgoCD (точнее, несколько), который подключает все доступные кластеры Kubernetes и управляет ими.
Сейчас у меня 34 кластера и примерно 1500 ArgoCD Applications.

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

https://telegra.ph/Centralizovannyj-vs-Decentralizovannyj-ArgoCD-02-07

#Kubernetes #ArgoCD #zvlb_article

Вырезка с внутреннего вебинара на тему интеграций Gitlab'a и Kubernetes.

Тут теория, так же будет вторая часть, где именно про практику

https://youtu.be/60XXak1t7ig?si=SUgm-mWdfdF6vzxL

#zvlb_video #Kubernetes #Gitlab

Немного про базу, которая, лично для меня, становится все более актуальна, т.к. kubeVirt с ноги залетает в мою рабочую повседневность.

Статейка про базовые примитивы Виртуализации. Какие типы бывают, как работает и т.д.

#zvlb_article #virtualization

https://zvlb.github.io/blog/virtualization/

ИТшники, видимо, оклемавшись от нового года (Да. В середине февраля), начали активно шерстить рынок вакансий. Что в свою очередь привело к тому, что у меня сейчас собеседование за собеседованием senior специалистов.

И чего я сказать-то хочу... Ну это... Ну какой вы, блин, senior, если вы 5-10-20 лет подряд устанавливали различное ПО по схеме "далее-далее-установить-готово"?

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

И ведь ничего супер сложного. Вот пару примеров:
Вопрос: "Как бэкапить Grafana?"
Ответ: "А зачем бэкапить? Она не падает"
Комментарий: "Я согласен, что Grafana крайне стабильный продукт и просто так не падает. Но быть настолько уверенным в Grafana и железе, на которой она поднята - мне бы такой уровень похуистичности"

Вопрос: "Как сделать отказоустойчивый Prometheus?"
Ответ: "А зачем?"
Комментарий: "Prometheus - это бинарь, который не умеет в HighLoad и если кандидат никогда не настраивал и не думал о повышении доступности Prometheus'а - это значит, что он никогда не работал с большим набором метрик или не думает о контролируемых им продуктах и их работе"

#zvlb_musle

P.S. Сегодня прислали кандидата. 23 годика, 3 года опыта работы, +-классический стек без углубления, хотел 500к рублей на руки. Что у вас там с рынком ИТ в России? С ума сошли?

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

Вопрос 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