Статья о том, как работают Эфимерный контейнеры и как использовать kubectl debug

#Kubernetes

https://zvlb.github.io/blog/ephemeral-containers-kubectl-debug/

Немного информации на тему, почему kubectl get all не показывает ВСЕ ресурсы и что нужно сделать, чтобы увидеть ВСЕ ресурсы.

#Kubernetes

https://zvlb.github.io/blog/get-all-in-kubernetes/

Начиная с релиза 1.26 Kubernetes’а в stable перешла новая фича - контроль HugePages. В данной статье мы рассмотрим что это такое, зачем оно нужно и как с этим работать.

#Kubernetes

https://zvlb.github.io/blog/huge-pages-in-kubernetes/

Интересный подкаст на тему сетей в Kubernetes

#Kubernetes #cni

https://linkmeup.ru/podcasts/2343/

Короче нихуя-нихуя, а тут вдруг и статья о том, как писать Kubernetes Operator'ы с Admission Webhook'ами и не сойти с ума)

#Kubernetes

https://zvlb.github.io/blog/kubernetes-admission-webhook/

В рамках подготовки к срачу с DevOps’ами накидал статью об организации работы в Git'е и релизной модели DevOps Branching Strategy (Feature branching)

https://zvlb.github.io/blog/CD-practices/

С выходом версии 7, Kubernetes Dashboard сильно изменился. Раньше это было простое решение в одном контейнере. Теперь это три контейнера: web, api, auth. Но самое интересное — у такого простого приложения появилась жесткая зависимость от внешнего решения — Kong.

❓ Почему это вызывает проблемы?

• Усложнение инфраструктуры: теперь нужно больше контейнеров и ресурсов.
• Зависимость от внешних решений: добавляет сложности в настройке и поддержке.

Kubernetes Dashboard был хорош именно своей простотой, и это изменение ставит под вопрос его удобство.

Ну и самое сладкое. Новая версия Dashboard'a реально медленно работает.

P.S. 6 секунд на картинке - это загрузка информации о deployment'ах, после которого (ПОСЛЕДОВАТЕЛЬНО) выполнится такой же запрос о Pod'ах, а потом обо всем остальном, связанным с выбранным namespace. Красота

#Kubernetes #Dashboard

Одно из важных изменений второй версии cgroup - это переработка memory-контроллера (добавили политики memory.min и memory.high.

memory.min обеспечивает для процессов в одной cgroup’e всегда будет доступно определенное количество оперативной памяти и никакие другие процессы, не состоящие в cgroup, не смогут ее использовать. А memory.high намного жестче регулирует сколько именно оперативной памяти могут использовать процессы в cgroup’е.

Разрабы Kubernetes начали внедрять это вот все. Даже бету реализовали, которая включается по featureGates.

Однако на этапах тестирования отказались от этого функционала, так как тесты показали, что новый функционал контроллера memory работает "нестабильно"

https://github.com/kubernetes/enhancements/tree/a47155b340/keps/sig-node/2570-memory-qos#latest-update-stalled

#Kubernetes #cgroup

Я честно пытался использовать telegra.ph для статеек, которые сюда собирался выплевывать, но это анрил.

Это бархло тупит слишком жестко(

Буду дальше пользоваться своим сайтиком)

Вчера ребята из Yandex выложили в Open Source свой инструмент для централизованной профилировки CPU на Linux-машинах — Perforator.

По сути, они реализовали обработку снимков состояния потоков на стороне userspace, а не kernelspace (спасибо eBPF),
плюс добавили инфраструктуру, позволяющую собирать снимки с множества серверов и сохранять их в ClickHouse и S3.

Честно говоря, держать эту систему в проде на постоянной основе (то есть, когда Perforator Agents постоянно снимают потоки, анализируют их и отправляют куда-то) — довольно спорное решение. (Хотя, по словам инфраструктурщиков Яндекса, они именно так и сделали.)

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

#Linux #Dubug #prof

Как работает 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 #собеседования