Kubernetes *

Когда речь заходит о проверках безопасности в Kubernetes, на ум в первую очередь приходят готовые средства: Pod Security Admission, OPA Gatekeeper, Kyverno. Они хорошо закрывают базовый уровень: привилегированные контейнеры, отсутствие лимитов, запуск от root. Однако реальные требования ИБ редко умещаются в набор из десятка предустановленных проверок.

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

Поскольку у нас в ЛК все строится вокруг безопасности, то защита Kubernetes — первостепенная задача, и я решил поделиться в этой статье нашим с коллегами опытом по защите Runtime в K8s.

Для моих задач Prometheus ел слишком много памяти, и я стал искать альтернативу. Нашёл Deckhouse Prom++, у которого заявлена экономия памяти в 7,8 раза, и решил проверить это на своём стенде. Сравнил его с Prometheus 3.15.0 и 2.55.1 на 500 000 активных серий, 12 прогонов за два дня. Получилось 4,4 раза по памяти, 3,8 по процессору и около 24% по скорости запросов при 16 клиентах. Рассказываю, как мерил, где ошибся и почему цифры отличаются от заявленных.

Мы внедрили HolmesGPT — open-source SRE-агента — в шести Kubernetes-кластерах на трёх проектах. Теперь через несколько минут после алерта рядом с ним в чате лежит гипотеза: что происходит, почему и что проверить. Дежурный не начинает расследование с нуля.

Готовой связки с Alertmanager в открытой версии HolmesGPT нет, поэтому мы написали и открыли свой инструмент — holmes-alert-bridge. Ниже — как это устроено, сколько стоит и чему мы научились за первый месяц.

Что произойдёт, если удалить один из трёх Pod? Kubernetes создаст замену. Во второй части «Kubernetes просто лабы» проверим это на практике.

Продолжим работу в учебном кластере: опишем Deployment в YAML, запустим три реплики nginx и разберёмся, как связаны Deployment, ReplicaSet и Pod. Затем удалим один Pod, понаблюдаем за появлением нового, изменим количество реплик и научимся выбирать Pod по меткам.

За 20–30 минут увидим, как Kubernetes приводит фактическое состояние приложения к желаемому. Всё пошагово: команды, пояснения и пиксельные иллюстрации.

Доля респондентов, которым сложно использовать Prometheus и OpenTelemetry вместе, за два года сократилась с 29% до 10%. Почти половина участников опроса сочетает подходы Prometheus и OTel к инструментированию инфраструктуры, не переходя полностью на один из них. Команда VK Tech перевела статью с результатами опроса, которые пригодятся SRE и платформенным инженерам при выборе способа инструментирования инфраструктуры и приложений.

Авторы опросили пользователей OpenTelemetry и Prometheus о том, как они собирают, обрабатывают и хранят метрики. Они хотели на основе реальных данных об использовании понять, насколько продвинулась экосистема и по-прежнему ли совместимость вызывает трудности.

Данная статья не претендует на какую-либо техническую глубину, и лишь призвана немного помочь коллегам, регулярно сталкивающимся с необходимостью выполнять миграцию своих кластеров kubernetes/openshift, вне зависимости от причин этой миграции - смены техстеха, переезда в другие ЦОДы, разделения систем и т.д. За пять лет использования алгоритма нигде не видел детального описания предлагаемого процесса. Иногда, решение в лоб - изменить DNS записи выведенных для потребителей эндпоинтов - не всегда оправдано, во-первых из-за лага применения новых значений в DNS, а во-вторых - из-за вероятности возникновения необходимости отката на старый кластер. Иметь же перед кластером некий выделенный шлюз/балансировщик, где получилось выполнить перенаправление запросов - не всегда оправдано/технически возможно.

В SBOM-отчёте оказались уязвимости компонентов, которых даже нет в вашем софте. Ничего необычного: просто сканер безопасности подтянул все непрямые зависимости и усложнил вам жизнь.

Расскажу, как избавиться от шума ложных срабатываний сканера в CI/CD — решение можно реализовать Open Source-инструментами на любой инфраструктуре.

Для этого используем sh скрипт, который выполняет несколько действий: устанавливает k3d и Helm, скачивает необходимые docker образы и создает локальные теги для них, которые будут использоваться через локальный реестр.

DNS в Kubernetes может годами работать без нареканий, а затем внезапно начать добавлять по пять секунд к запросам. Причина порой скрывается в стандартных настройках резолвера, которые создают лишний трафик и повышают вероятность потери пакетов. Разбираемся, как ndots:5 связан с таймаутами, где искать источник задержек и какие способы решения действительно помогают.

Этот цикл статей стал результатом попытки посмотреть на Kubernetes как на ядро Linux: что, если K8s будет аналогом Linux Kernel и инженеры начнут работать не с ванильным Kubernetes, а с готовыми дистрибутивами, не отвлекаясь на настройку и подгонку компонентов. Именно вокруг этой мысли и возникли эти материалы.

Осенью 2023 года на KubeCon в Чикаго Тим Хокин, один из тех, кто стоял у истоков Kubernetes, говорил со сцены о том, что Kubernetes становится сложнее с каждым релизом, и эта сложность не бесплатна, потому что каждая новая фича, нужная лишь кому‑то одному, ложится грузом на всех остальных; разработчики проекта всё хуже удерживают в голове всё целиком, а инженерам, которые его эксплуатируют, всё труднее разобраться во всех его настройках. Хокин предложил относиться к сложности как к бюджету, который у проекта есть и который можно потратить, но только один раз, а значит, надо научиться отказываться от того, что этот бюджет съест без достаточной пользы.

Меня эта мысль зацепила, потому что мне показалось, что у неё есть продолжение, о котором со сцены сказано не было. Если сложность, нужная машинному обучению, сетевым устройствам или промышленным контроллерам, не помещается в бюджет ядра проекта, то ей всё равно нужно какое‑то место, где она будет жить, никого не обременяя. В мире Linux такое место давно нашлось. Ядро там остаётся ядром, которое знают и трогают руками немногие, а вся специфика уходит в дистрибутивы, и никто не ждёт от Торвальдса, что он лично позаботится о роутерах, медицинских томографах и игровых консолях.

Всем привет! Меня зовут Петрович и я работаю техлидом java команды в небольшом международном финтехе. В прошлый раз я рассказывал, как мы меняли Redis на Hazelcast, а сегодня расскажу как мы делали свой MCP‑сервер для Jira, Confluence и GitLab (все self‑hosted). От пустого репозитория до прода прошло две недели, а сейчас у сервера уже почти 100 инструментов. Расскажу, почему не взяли готовое с GitHub, как все устроено внутри и на какие грабли мы наступили (спойлер: почти все грабли назывались null).

Привет, Хабр! Меня зовут Павел, я старший разработчик ML-платформы в Авито и последние полтора года занимаюсь MLOps. 

На прошедшей Kuber Conf я выступал с докладом про нашу платформу распределённого обучения, а теперь решил сделать на его основе статью для вас. Если вам комфортнее воспринимать такие доклады в формате видео — держите.

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

ML-платформа Авито. Как всё начиналось

В те времена, когда в Авито работало не так много дата-сайентистов, они использовали разнородные инструменты. Главным из них был так называемый DevBox — выделенная машина, на которую специалист заходил по SSH, делал свои дата-сайентистские дела, обучал модели, собирал датасеты и прочее. Время шло, число спецов росло (равно как и отделов), и мы не придумали ничего лучше, как добавить ко всему этому ещё и LLM. У неё была своя специфика в плане инструментария, и в целом жизнь она не сильно облегчила.

Так началась эволюция нашего пути — от обычного доступа к машинам по SSH, когда коллеги полностью блокировали их и выполняли задачи вручную, до нашей полноценной cloud-native-платформы, которую мы назвали Aviflow.

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

В конце июля мы с коллегами съездили в Иокогаму на KubeCon + CloudNativeCon Japan 2026. Ко второму дню я заметил, что слайды выступающих повторяются: спектр изоляции тенантов, квоты, bin packing, «GPU дорогие — давайте делить». Мы решаем в Авито ту же задачу, поэтому я разберу шесть докладов про GPU и LLM-инференс и расскажу, что из этого мы уже пробовали или собираемся попробовать. А в конце будет немного про саму Японию.

ИИ может за секунды сгенерировать аккуратный Kubernetes‑манифест, который пройдет валидацию и даже успешно запустится в кластере — а проблемы проявятся уже в production. Разбираемся, почему LLM воспроизводят устаревшие и небезопасные конфигурации и как проверять сгенерированные манифесты до деплоя.

Представьте кластер Kubernetes, в котором нет ни одной сетевой карты. Его узлы ничего не знают ни о TCP/IP, ни даже об Ethernet и перекликаются по радио короткими пакетами по 32 байта, как прорабы по рациям на стройке. Управляющий слой написан на языке конца восьмидесятых и вместе с сетевым протоколом занимает около 1250 строк. Чтобы запустить под, ничего не нужно скачивать: узел просто загружает модуль и вызывает в нём процедуру. А главное, всё это открывается во вкладке браузера: можно выдернуть узел из розетки, заглушить эфир, подсунуть кластеру поддельную команду и посмотреть, что из этого выйдет.

Такой кластер я собрал за последние несколько недель и назвал его Kube. Это управляющий слой Kubernetes, написанный на Обероне, языке Никлауса Вирта, и работает он на машинах Оберона, то есть на процессоре и операционной системе, которые Вирт спроектировал сам, от схемы до окон на экране. Узлы Kube тоже машины Оберона, и разговаривают они по радиосети из той же книги: Вирт написал эту сеть для своих рабочих станций ещё в конце восьмидесятых, а в новой редакции проекта её перевели на дешёвый радиомодуль.

В этой части разберём, зачем Kubernetes понадобился Gateway API, если уже существует Ingress. На простом примере посмотрим, как Gateway и HTTPRoute разделяют точку входа и маршрутизацию, зачем нужен GatewayClass и почему такая модель удобна, когда кластер и приложения обслуживают разные команды.

Есть у меня несколько проектов, которые начинались как шутка в чате про Kubernetes и почему-то не остановились. Например, Sheeternetes родился из спора о том, можно ли сделать оркестратор контейнеров в электронной таблице, и оказалось, что можно. Tatarnetes вырос из желания, чтобы kubectl заговорил по-татарски (и из татарских мемов). Kyvernetria попыталась честно ответить на вопрос, как выглядел бы Kubernetes, если бы его поведение строилось на подтверждённых наукой средних различиях между мужчинами и женщинами, а не на стереотипах. Ну а Mansplainetes и Misogynetes появились как сатира на тех, кто в такие стереотипы свято верит.

Всё это время проекты жили на уровне «работает, но у меня на ноутбуке». В эти выходные я наконец довёл их до нормальных релизов, и их набралось сразу семь. Расскажу, что в каждом нового и почему некоторые из этих шуток, к моему собственному удивлению, оказались полезными.

Раньше инфраструктурные модули в Nova устанавливали с помощью YAML-манифестов. Например, чтобы развернуть в Kubernetes-кластере систему хранения данных Longhorn, администратор находил нужный манифест в документации и копировал его в Nova Console. Затем менял параметры под свой кластер, указывал названия нод и при необходимости применял патчи. Если что-то не работало, шёл обратно в документацию и искал пропущенное или неправильно заполненное поле.

За развёртывание инфраструктурных модулей в Nova Container Platform отвечал Apps Operator. В нём были собраны семь манифестов (Custom Resource) для разных сервисов, а сам Apps Operator подтягивался вместе с кластером, даже если заказчику требовалась только часть компонентов.

Со временем такой монолит перестал подходить и пользователям, и команде. Версии инфраструктурных компонентов были привязаны к релизам платформы. Для обновления одного из них заказчику приходилось обновлять весь кластер, а изменение даже одного модуля влекло за собой полное регрессионное тестирование Apps Operator. Изначально он не выглядел будущим монолитом. Манифесты компонентов хранились отдельно в Git внутри кластера, а для их доставки использовали FluxCD. Сам оператор задумывался как лёгкая обёртка над GitOps-системой, но со временем разросся. Этот опыт показал, что хранение манифестов за пределами оператора само по себе не защищает его от превращения в монолит.

Привет, Хабр! Меня зовут Никита Лось, я — системный аналитик Nova Container Platform в компании Orion soft. В статье я расскажу, почему мы взяли за основу OperatorHUB из проекта Operator Framework, что пришлось изменить под Nova и как переносили работающие кластеры с монолитного Apps Operator на набор независимых операторов.

В классическом CI/CD пайплайн заканчивается деплоем, но дальше состояние Kubernetes‑кластера может незаметно разойтись с конфигурацией в Git. Разбираемся, как ArgoCD обнаруживает и исправляет такой дрейф, как настроить синхронизацию и где автоматизация GitOps требует особенно осторожного подхода.

28 августа Tech Times вынес в заголовок сразу две новости: бету gang scheduling в Kubernetes 1.37 и «экономию на простое GPU по умолчанию». За день этот заголовок разошёлся по лентам. Через одиннадцать дней авторы функции написали в блоге проекта: «Все перечисленные здесь бета- и альфа-функции по умолчанию выключены; их нужно включать вручную». 

В этом расхождении между заголовком и первоисточником — вся суть релиза. Группу подов впервые описали в 2018 году и тогда же решили реализовать вне ядра Kubernetes. Следующие восемь лет функцию развивали Volcano, YuniKorn, Kueue и отдельные плагины. В Kubernetes 1.37 групповое размещение стало бетой в kube-scheduler, но по умолчанию оно выключено.

Некоторые обзоры называют бету включённой. Из этого легко сделать вывод, что внешний планировщик больше не нужен. Но KEP передаёт ядру только размещение группы. Очереди и квоты по-прежнему остаются задачей Kueue и Volcano — это прямо указано в документе.

Инженерам здесь пригодится разбор работы кластера с GPU и внешним планировщиком. Администраторам платформы — список feature gates, которые нужно открыть пользователям. Руководителям — критерии, по которым можно решить, стоит ли после обновления отказываться от Volcano. В каждом разделе указано, для кого он предназначен.