Kubernetes *

Привет, Хаброжители! «Паттерны Kubernetes» — это не очередной справочник по настройке кластеров или описанию API. Это фундаментальный труд, который отвечает на самый главный вопрос: как эффективно проектировать и строить приложения, предназначенные для работы в Kubernetes? Авторы систематизировали лучшие практики, преобразовав их в паттерны. Книга учит не просто использовать Kubernetes, а мыслить категориями платформы, комбинируя примитивы для создания отказоустойчивых, масштабируемых и удобных в эксплуатации систем. Это must-read для любого разработчика, который хочет выйти за рамки простого деплоя контейнеров и овладеть всеми возможностями Kubernetes.

Kubernetes-операторы давно стали привычным инструментом автоматизации и управления сложными системами. Однако на практике их поведение далеко не такое предсказуемое, как в примерах из документации. Небольшие отклонения в логике цикла согласования, обработке ошибок или обновлении статуса быстро превращаются в зацикливание, дублирование ресурсов и прочие сюрпризы, которые трудно отладить. Новичкам полезно понимать, почему так происходит, а опытным разработчикам — помнить, какие принципы стоит держать в голове при проектировании оператора.

Меня зовут Стас Иванкевич, я техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. В управляющий слой входят установщик кластера, консоль, API, другие компоненты и самое релевантное для этой статьи — наши многообразные операторы.

За последние несколько лет мы разработали целую пачку операторов — на один-два контроллера или сразу на множество. В ходе работы мы собрали и упорядочили лучшие практики, проверенные реальной эксплуатацией, а также подводные камни и типичные ошибки. И сегодня хотим поделиться нашей подборкой с вами.

Всем привет! Меня зовут Артемий, я работаю SRE-инженером в команде RTP (real time processing) Clickstream в Авито. Сегодня мы хотим поделиться нашей историей о том, как мы переехали в Kubernetes, развернув Apache Flink с помощью Flink k8s operator.

В Istio всё начинается с маленькой «удобной» идеи — прокси рядом с каждым подом. А заканчивается тем, что XDS разносит по кластеру тонны Listener’ов, Route’ов и Cluster’ов, дублируя конфиги для сервисов, которые вы даже не трогаете. Память тает, GC злится, а апдейты сервисов превращаются в шторм.

В статье пойдет речь о том, как мы в проде с 20K+ подов «урезали аппетит» сайдкаров на гигабайты. Обсудим, где работает жёсткое ограничение видимости, когда спасает Ambient Mesh, зачем нужен ленивый XDS и почему «волшебной кнопки» нет — но есть комбинации, дающие двузначную экономию. Эта статья написана по мотивам моего доклада для конференции Saint HighLoad++.

В статье — проверенные практики от сообщества Kubernetes: от выбора версии API и работы с YAML до управления подами и лейблами. Плюс несколько советов от команды Deckhouse по работе с ресурсами и автомасштабированием.

Год назад я не знал о Kubernetes практически ничего. Сегодня у меня свой pet-проект развернут в облачном кубере, и я чувствую себя достаточно уверенно, чтобы делиться опытом. Что изменилось? Я начал преподавать в МАИ и проходить сертификацию по работе.

Звучит парадоксально, правда? Обычно всё наоборот - сначала учишься, потом учишь других. Но в моем случае именно преподавание стало катализатором интенсивного обучения. И в этой статье я расскажу, как это работает и какой путь я прошел.

Мы тут в Cozystack в очередной раз решаем проблему курицы и яйца: как задеплоить CNI и kube-proxy через Flux, но при этом обеспечить работу самого flux без CNI и kube-proxy.

Сам Flux запустить без CNI и kube-proxy можно используя проект flux-aio (от создателя Flux), который запускает единый deployment со всеми контроллерами настроенными на коммуникацию друг с другом через localhost.

Специфика Cozystack заключается в том, что на каждый кластер мы деплоим внутри небольшой HTTP-сервер с Helm-чартами и другими ассетами используемыми в платформе. Flux эти чарты читает и устанавливает в систему.

Но вот как организовать доступ флюксу к внутреннему HTTP-серверу, запущенному как под внутри того же кластера?

Привет, Хабр! Меня зовут Миняйлов Лев, я DevOps-инженер в ИТ‑холдинге Т1.

В этой статье предлагаю рассмотреть эволюцию методов развертывания в Helm от v2 к v4, и дополнительно уделить внимание порядку обновления ресурсов в кластере и возможностям влиять на него через хуки.

Статья для тех, кто пытался поставить k3s на Arch Linux и столкнулся с зависающим установщиком, проблемами DNS и отсутствующими systemd юнитами. Полное руководство по ручной установке с реальными командами и решениями.

Команда Go for Devs подготовила краткий разбор новинок GoLand 2025.3. В этот раз IDE получила анализатор утечек ресурсов, встроенный Terraform, улучшенную работу с Kubernetes, поддержку нескольких ИИ-агентов и заметный прирост производительности.

Привет, Хабр!

В последнее время меня часто спрашивают (интересно, и кто эти люди) про Kubernetes и виртуализацию, точнее про разные варианты совмещения того и другого, и можно без хлеба в одном флаконе. Проще говоря, что лучше, интереснее и эффективнее: прикрутить к Kubernetes дополнительную фичу, например, KubeVirt, чтобы можно было с помощью оркестратора Kubernetes управлять не только контейнерами, но и виртуальными машинами, или же взять классическую среду виртуализации, управляющую виртуальными машинами, и добавить в нее Kubernetes для управления контейнеризированными приложениями. Вопрос непраздный, да к тому же непростой, поэтому давайте разбираться по порядку. За подробностями добро пожаловать под кат.

В данной статье я покажу, как на Windows развернуть кластер Kubernetes из одного узла с поддержкой GPU и time-slicing, используя WSL.

В итоге получится удобная домашняя Kubernetes-лаборатория.

На носу 2026 год, а я хочу поделиться своим путешествием по переводу приложения на инфраструктуру Kubernetes. Самой сложной и интересной частью была настройка автоскейлинга. Не слишком ли заезженная тема? Думаю нет, потому что я буду рассказывать именно с позиции разработчика приложения, а не девопса. Мне повезло, я без понятия как это всё настраивается. Я буду рассказывать как это всё работает. Конфигов кубера будет минимум, рассуждений и погружений в метрики максимум. В конце оставил TL;DR. Поехали?

Привет! Меня зовут Александр, я ведущий разработчик VK Tech в команде, которая занимается сервисом Kubernetes в нашем публичном облаке. Все чаще провайдеры отказываются от модели, где пользователь получает полный контроль над кластером и всеми управляющими компонентами, в пользу управляемых (managed) решений. В такой архитектуре вы остаетесь администратором внутри своего кластера — создаете неймспейсы, деплоите приложения, настраиваете RBAC, — но инфраструктура, control plane и системные компоненты полностью управляются провайдером и скрыты от глаз пользователя. 

В начале декабря наша команда выпустила новый сервис managed-k8s, в котором как раз реализован такой подход. Я расскажу вам про то, как выглядит наш Kubernetes с точки зрения архитектуры и каким образом Gatekeeper делает архитектуру безопасной.

Представьте ситуацию: ваше приложение в Kubernetes работает стабильно, но внезапно начинается пиковая нагрузка. Поды пытаются масштабироваться, HPA увеличивает их количество, но... они висят в статусе Pending. Почему? Потому что в кластере недостаточно ресурсов на нодах. Cluster Autoscaler должен добавить новые ноды, но процесс занимает много времени, иногда нода не создается из-за проблем с облаком. За это время пользователи уже получают ошибки 503, а вы теряете деньги. Знакомо?

А теперь обратная ситуация: нагрузка спала, поды удалились, но ноды продолжают работать вхолостую. Вы платите за простаивающие ресурсы, потому что Cluster Autoscaler слишком консервативен в удалении нод или не может оптимально «упаковать» workloads.

Есть ли способ сделать это быстрее, умнее и экономичнее? Меня зовут Даниил Кондрашов, я разработчик Managed Kubernetes в Selectel. В этой статье познакомлю вас с Karpenter — современным решением для автоматического управления нодами в Kubernetes, которое решает эти проблемы принципиально иначе. Подробности под катом!

Привет, Хабр! Меня зовут Макарий, и как Senior SRE в Yandex Cloud я не только участвовал в разработке Managed Service for Kubernetes, но и всегда любил в свободное время посмотреть, что интересного понавыпускали для «кубика». Kubernetes, как де‑факто стандарт оркестрации контейнеров, предлагает базовые механизмы для управления вычислительными ресурсами. Однако стандартный планировщик Kubernetes (kube‑scheduler) разрабатывался с учётом общих принципов балансировки нагрузки и не специализирован для уникальных особенностей рабочих GPU‑нагрузок.

Предлагаю рассмотреть весь спектр возможностей — от встроенных механизмов шедулинга K8s до специализированных планировщиков, таких как Volcano, Apache YuniKorn и KAI‑Scheduler. Проанализирую конкретные сценарии, в которых каждый из этих инструментов демонстрирует свои преимущества, и предложу рекомендации по выбору оптимального решения для ваших рабочих GPU‑нагрузок.

Многие команды уже построили вокруг Kubernetes свои внутренние платформы, но со временем они превращаются в свалку YAML’ов и разрозненных Helm-чартов. В статье показывается, как собрать из этого аккуратный «конструктор» из трёх уровней компоновки (инфраструктура, сервисы платформы, приложения), завязать всё на GitOps через Argo CD и vCluster, а затем скрыть сложность за шаблонами и CRD, чтобы разработчику было достаточно описать один WebApp-ресурс вместо возни с десятком сущностей Kubernetes.

Построение отказоустойчивой гибридной сети между локальной инфраструктурой и облаком — одна из ключевых задач при миграции. Стандартных решений здесь не существует: выбор архитектуры и технологий зависит от требований безопасности, производительности и желания избежать vendor lock-in.

Я хочу показать один из способов решения такой задачи на примере облака VK Cloud с учетом специфики его SDN-сети. Отдельно хочется добавить, что рассматриваемый в статье подход к построению сетевой связности может быть успешно применен не только в VK Cloud.

В основу статьи легли вопросы и задачи, с которыми клиенты часто обращаются к командам Presale архитекторов и Professional services VK Cloud, когда они хотят построить надежное гибридное решение для своего бизнеса.

Мне хотелось написать статью, которая будет не научно-популярным повествованием, а практическим руководством, систематизирующим имеющиеся знания по разным продуктам и сетевым технологиям.

Всем привет! На связи Александр Синичкин, ведущий архитектор CTCS – CrossTech Container Security – решения для обеспечения комплексной безопасности контейнерных сред: от сканирования образов до контроля запуска рабочих нагрузок и реагирования на инциденты в средах выполнения. Сегодня я расскажу, как и почему мы решили разрабатывать продукт CTCS, с какими сложностями столкнулись и каких ошибок могли бы избежать, куда планируем развиваться.

Про eBPF уже сказано и написано достаточно много, поэтому я хочу сделать следующий шаг и чуть глубже рассмотреть практические аспекты работы c таким механизмом, как kprobe, который позволяет использовать функции ядра Linux для динамического запуска пользовательского кода.

Статья поможет ответить на вопросы:

- Как понять, какую функцию ядра выбрать для использования с механизмом kprobe?

- С чего начать ее поиск?

- Какими инструментами пользоваться?

kprobe — это, по сути, ловушка, или брейкпоинт, который можно установить почти в любом месте кода ядра Linux.