Решил закрыть тему собеседований (хотя может и не закрыть) списком своих вопросов, которые я люблю спрашивать про 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

Flant выложил в OpenSource свой Prom++
На прошлой неделе Flant открыл исходный код своей внутренней разработки — Prom++ (GitHub). Подробный разбор продукта есть на Хабре (статья).

Коротко о главном:
Prom++ позиционируется как «улучшенный Prometheus» с в 7-8 раз меньшим потреблением ресурсов

Мои мысли вслух:

1. Двойственное отношение к продуктам Flant:
С одной стороны — их решения часто топовые.
С другой — почти все их «фишки» завязаны на коммерческий продукт Deckhouse. Хотелось бы видеть больше open-source-решений, которые можно использовать независимо.

Пример: их Log Shipper — отличная штука, но без Deckhouse не работает. Пришлось делать свой Vector Operator 😅. В идеале — коллаборация сообщества и Flant, но пока их модули развиваются только «внутри» их платформы.

2. Про Prom++:
- Лицензия Apache 2.0 — пока всё открыто.
- Но... (спойлер: есть подозрение, что бесплатный сыр может оказаться в мышеловке Deckhouse 🧀. Как мы недавно наблюдали что-то похожее с Grafana On Call). Однако тут я не уверен. Через пару-тройку лет увидим.

3. Сравнение с VictoriaMetrics:
Главная «киллер-фича» VictoriaMetrics — встроенная кластеризация. Prom++ её не предлагает, а для многих проектов масштабирование важнее экономии RAM.
Личный вывод: экономия памяти в 2-3 раза — это круто, но без горизонтального масштабирования для больших инсталляций VictoriaMetrics останется фаворитом.

P.S. Всё равно попробуем задеплоить Prom++ в нашем кластере и сравнить с VictoriaMetrics.

#zvlb_musle #Prometheus #VictoriaMetrics