ZVLB. Tech

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

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

#zvlb_article #virtualization

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

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

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

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

#zvlb_video #Kubernetes #Gitlab

В канале про 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

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

Все давно натренировались на вопросы по 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

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

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

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

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

#Grafana #Kubernetes

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

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

#Kubernetes #golang #garbage_collector #zvlb_article

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

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

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

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

#Linux #Dubug #prof

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

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

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

Одно из важных изменений второй версии 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

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

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

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

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

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

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

#Kubernetes #Dashboard

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

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

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

#Kubernetes

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

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

#Kubernetes #cni

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

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

#Kubernetes

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

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

#Kubernetes

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

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

#Kubernetes

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

Небольшая зарисовка о том, как работают Kubernetes информеры

#Kubernetes #Golang

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

Интересный и подробный RoadMap на тему погружения в практики DevOps инженеров

#DevOps

https://roadmap.sh/devops

Ухххх. Если вы живете на linux'e (не важно baremetal или виртуализация) и шифруете свои диски (с помощью dm-crypt), то при увеличении нагрузки но ноды (нагрузка = частота поднятия подов), то вы можете столкнуться с тем, что этот шифрователь дисков был изначально написан для HDD дисков, и на SSD он сильно влияет на производительность.

Проблема актуальна для всех ядер, но для ядра 5.9 был выпущен патч (https://www.thomas-krenn.com/en/wiki/Dm-crypt_Performance). Однако по умолчанию этот патч не включен!

#Kubernetes #disk

Вот тут про это подробно написано - https://blog.cloudflare.com/speeding-up-linux-disk-encryption/