Kubernetes *

Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина в новой для себя области. Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.

Рассмотрим нестандартный вариант установки Kubernetes, а именно установка кластера без control-plane ноды как таковой в стандартном ее восприятии. Установим кластер Kubernetes где слой control-plane будет просто хостом без CRI, только базове systemd сервисы. "Спрячем" control-plane от лишних глаз.

Есть паттерн, который я вижу почти в каждом кластере, куда прихожу: liveness-проба, скопированная из туториала, которая годами тихо делает продакшен хуже. Не «не помогает» — именно делает хуже: превращает локальные замедления в каскадные рестарты и красивые инциденты на ровном месте.

Тезис статьи простой: liveness-проба — это не «проверка здоровья». Это заявление «если этот запрос не ответил — процесс нужно убить». И в большинстве конфигураций, которые я встречал, это заявление ложно.

Последние несколько месяцев я пристально слежу за тем, как растет и меняется Flux CD. Для тех, кто с ним еще не сталкивался: Flux CD — это набор GitOps-контроллеров для Kubernetes. Он непрерывно следит за Git-репозиторием и приводит кластер к тому состоянию, которое там описано — ставит Helm-чарты, применяет Kustomize-оверлеи, подтягивает образы и секреты. Git становится единственным источником правды, а любое изменение инфраструктуры превращается в коммит: его можно отревьюить, откатить и проследить по истории.

Flux хорош модульностью. Это не монолит, а набор небольших контроллеров — source-controller, kustomize-controller, helm-controller и другие, — каждый решает свою узкую задачу и расширяется через CRD. Благодаря этому экосистема легко прирастает сторонними контроллерами. Один из них, Tofu Controller, и станет героем этой статьи.

Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей.

В материале — ключевые практики для 2026 года: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.

Ошибки в разработке неизбежны, но они помогают расти. Я Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наша команда придерживается простого принципа: не наступать на одни грабли дважды. Из каждой ошибки стараемся извлечь урок и больше её не повторять, а ещё лучше — учиться на ошибках других. Поэтому мы развиваем культуру открытого обсуждения ошибок и не закрываем глаза на возникающие сложности.

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

Я уже рассказывал о подводных камнях и лучших практиках при разработке операторов Kubernetes: материал в трёх частях можно почитать тут, тут и тут. А в этой статье я собрал ошибки, которые часто встречались мне в реальных проектах при работе с Kubernetes-операторами. Расскажу, как мы их исправляли, какие выводы сделали и что теперь делаем иначе. Надеемся, наш опыт будет полезным для вас и поможет их не повторить.

Нагрузка в кластере растёт, PV распухают, IaC-инструменты перестают справляться. В какой-то момент всё начинает тормозить так, что уже мешает нормально работать.

Команда Cloudflare столкнулась с такой ситуацией и нашла решение — изменить одну маленькую дефолтную настройку в Kubernetes.

В статье — шаги по аудиту кластера и изменению настроек. Особенно пригодится тем, у кого есть кластеры с крупными PV.

Высокий приоритет пода в Kubernetes должен повышать устойчивость сервиса, но при ошибочной настройке ресурсов может запустить противоположный сценарий: вытеснения, каскадные перезапуски и бесконтрольное масштабирование кластера.

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

У обычной ноды Kubernetes жёсткий потолок в 110 подов (формально настраиваемый kubelet-флаг --max-pods, но поднимать его руками не рекомендуется даже апстримом: упирается в размер Pod CIDR на ноду, и выше 110 Kubernetes просто не валидируют, так что на практике это потолок дефакто), плюс налог на каждый контейнер: containerd или CRI-O (справедливости ради, у CRI-O ~20 МБ, но на хост, и около 1 МБ на под), ~20 МБ containerd-shim на каждый контейнер, а сам CRI добавляет заметный delay в операциях. На мощном железе это заставляет выбирать между недоутилизацией и гипервизорным слоем (KubeVirt, Kata) с его собственным налогом на microVM. На слабых VPS стандартный стек тяжёл ещё даже до первого workload: kubelet + containerd + kube-proxy + CNI — это уже 300-600+ МБ RSS прежде, чем в кластере появится хоть один рабочий под.

У меня была мечта: Kubernetes + systemd. Я начал свой путь не зная куда это приведет, проект за время разработки сменил 7 разных направлений, думаю я нашел главную цель: освобождение Kubernetes.

Результат на двух моих машинах (Xeon E5-2690 v4 + Intel N150): 1772 пода, 33 ноды, 2.5 миллиона запросов под нагрузкой с нулём ошибок и медианой 257 мкс. RSS демона — 365 МБ (замер от 04.04.26, сейчас уже ниже) на 1660 подов (~225 КБ на под).

Дальше расскажу, что такое Periapsis, как у меня появилась эта идея и что уже работает.

Если вы последние пару лет следили за развитием сетевой подсистемы Kubernetes, то наверняка заметили, что вокруг Gateway API сложился странный консенсус: «все согласны, что это будущее, но почти никто толком не понимает, какую именно реализацию брать и зачем уходить от привычного Ingress». В этой статье я попробую рассказать про ключевые отличия Gateway API от Ingress (на примере самого популярного — NGINX Ingress Controller), сравнить между собой основные реализации Gateway API и поговорить о нюансах кастомизации, интеграции и производительности.

Linux даёт мощные механизмы безопасности уровня ядра — seccomp, SELinux и AppArmor, — которые ограничивают возможности контейнеризированных рабочих нагрузок. Если коротко: seccomp фильтрует системные вызовы процесса, SELinux и AppArmor накладывают мандатные политики доступа к файлам, сети и возможностям. Каждый из них работает через профили, которые описывают разрешённое поведение, но писать, распространять и поддерживать такие профили вручную утомительно и легко ошибиться.

Security Profiles Operator (SPO) снимает эту боль: профилями безопасности можно управлять как пользовательскими ресурсами Kubernetes, записывать их с работающих нагрузок и декларативно привязывать к подам.

С выходом v1.0.0 Security Profiles Operator переводит все восемь своих API типа Custom Resource Definition (CRD, определение пользовательского ресурса Kubernetes) на версию v1. Это первый стабильный релиз проекта, подкреплённый сторонним аудитом безопасности, полным циклом работ по усилению защиты и путём миграции без простоя с любой предыдущей версии API.

Команда VK Cloud перевела статью о том, как проект Security Profiles Operator за шесть лет довёл свои API до версии v1, прошёл сторонний аудит безопасности и теперь влияет на развитие самого Kubernetes. Это будет полезно тем, кто отвечает за безопасность кластеров — DevOps- и SRE-инженерам, специалистам по ИБ и разработчикам, которые пишут профили seccomp, SELinux и AppArmor для контейнеров.

Разберем KEDA именно как практический FinOps-гардрейл для Kubernetes: где HPA уже не хватает, как устроен ScaledObject, как безопасно подходить к scale-to-zero, какие ограничения ставить через maxReplicaCount и какие метрики собрать до пилота, чтобы потом доказать эффект цифрами.

Если вы применяете в своей инфраструктуре GitOps-подход, то вам точно знакомы такие решения по автоматизации доставки для Kubernetes, как FluxCD и ArgoCD. Это популярные инструменты, которые позволяют синхронизировать наполнение отслеживаемого Git-репозитория и отобразить его в кластере Kubernetes.

Сегодня воздержимся от их сравнения и сконцентрируемся на разговоре о том, какие удобства при работе может предоставить FluxCD.

Команда VK Cloud перевела разбор запуска self-hosted (размещаемого на собственных мощностях), read-only ИИ-агента внутри кластера Kubernetes, где всю цепочку CI/CD обслуживают GitHub Actions и Argo CD Image Updater. Никакие данные не покидают кластер, облачные ИИ-провайдеры не задействованы.

Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый».

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

Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами.

Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике.

Если ваша команда управляет слишком большим количеством кластеров или строит платформу для безопасного обслуживания нескольких команд — это руководство, которого мне так не хватало в начале пути.

Миграция — риск даже для небольших инфраструктур. А когда у вас больше миллиарда пользователей и петабайт данных, права на ошибку нет вообще. Но выход всё равно один — грамотно спланировать переезд и... взять и сделать.

В статье — о том, как Reddit перешёл на Kubernetes: почему они отказались от Amazon EC2, какие ограничения им пришлось учитывать и чем их опыт может быть полезен в других проектах.

Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито. 

В статье рассказываю, как мы строим ML-платформу на базе Kubeflow. От первых DevBox-решений мы пришли к набору небольших юнит-платформ, которые разные команды развивали под свои бизнес-задачи и связывали между собой. Со временем возникла задача объединить эти решения в единую платформу. Поделюсь, как мы это делали, с какими проблемами столкнулись и как их решили. И немного о том, как должны выглядеть агентские платформы, когда за управление инфраструктурой отвечают агенты. 

Статья будет полезна не только тем, кто разрабатывает и использует платформы в больших компаниях, но и тем, кто работает на DevBox-машинах или небольших платформах для юнит-команд от 10 до 100 человек.

Приглашаем на вебинар, где разберём, как с помощью Axiom JDK Certified внедрять криптографию по ГОСТ без сложной настройки и лишнего кода. На вебинаре покажем живую демонстрацию: как Java-сервисы внутри Kubernetes устанавливают защищённое mTLS-соединение с использованием Axiom JDK Certified, КриптоПро/JTLS (ГОСТ TLS).

Что будет на вебинаре:

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

Меня зовут Даниил Рахновский, я ведущий архитектор в Orion soft. В этой статье мы поговорим о том, почему опасно доверять секреты контейнерам, рассмотрим, как упорядочить работу с секретами в Kubernetes с помощью системы управления секретами и какие встроенные инструменты в этом помогают.