Kubernetes *

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

Переход уже начался. По данным CNCF 2025 Annual Cloud Native Survey, 66% организаций, которые размещают генеративные ИИ-модели, используют Kubernetes для части или всех инференс-нагрузок. Однако ежедневно развёртывают ИИ-модели лишь 7% организаций. Этот разрыв показывает разницу между запуском ИИ-нагрузок в Kubernetes и платформой, которая готова непрерывно эксплуатировать ИИ в production.

Проблема заметна и внутри платформенных команд. Исследование 2025 State of AI in Platform Engineering2 показало, что 35% таких команд всё ещё не оркестрируют ИИ-нагрузки. Это говорит о разрыве между внедрением ИИ и зрелостью операционных платформ, необходимых для его масштабной поддержки.

ИИ не требует от платформенных команд отказываться от Cloud Native-практик. Kubernetes, GitOps, observability, автоматизация и самообслуживание по-прежнему составляют ценный фундамент. Однако ИИ предъявляет дополнительные требования к вычислительным ресурсам, планированию, доставке моделей и эксплуатации.

Команда VK Cloud перевела статью о том, что должно измениться, чтобы Kubernetes-платформа была готова к эксплуатации ИИ-нагрузок.

Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разбирали стратегический вопрос: что проще и выгоднее — собирать самостоятельно или брать готовый ПАК (на примере ПАК Скала^р)? Поговорили и о том, что именно заказчик узнает о самосборе — не на этапе закупки, а через полгода эксплуатации. 

Сегодня же переместимся на следующий уровень: поговорим про аппаратный стек.

Структура статьи такова: для каждого слоя железа — GPU, питание, охлаждение, хранение — я покажу, какую инженерную задачу мы решали при проектировании ПАК и почему приняли именно такие решения, а не другие. Там, где это уместно, приведем цифры, которые помогут понять пороги: когда одно решение заменяется другим и что это означает по деньгам и по производительности.

Поехали!

Классическая ситуация: Go-сервис падает с panic: runtime error: invalid memory address or nil pointer dereference, Nuxt-фронтенд логирует NUXT_UNHANDLED: unhandled rejection. Клиент видит лишь общее «что-то сломалось» — точный текст ошибки остаётся только в логах.

Решение — алертинг по логам. Связка VictoriaLogs + Vector + vmalert + Alertmanager следит за потоком, и как только приложение пишет panic, log.Fatal или NUXT_UNHANDLED, в Telegram уходит алерт. Ниже — как поднять эту связку в Kubernetes без лишней нагрузки на хранилище.

От YAML-манифеста до работающих контейнеров: разбираемся, что Kubernetes делает после kubectl apply.

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

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

Виртуализация позволяет запускать на одном физическом сервере несколько виртуальных машин. Каждая из них имеет собственную операционную систему, настройки и окружение. Это обеспечивает высокий уровень изоляции и гибкости, но требует больше вычислительных ресурсов.

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

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

Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах. Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно.

В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов.

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

Денис, добрый день! После изучения вашей анкеты, к сожалению, мы не готовы пригласить вас к дальнейшему рассмотрению на обучение в компании. У нас очень большой поток кандидатов на курсы. В данный момент взяли в рассмотрение участников с показателями выше. Ваша анкета будет сохранена, возможно, вернемся к вашей кандидатуре, при наборе на следующий поток. Благодарим за внимание к нашей компании.

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Добавление физического сервера в кластер Kubernetes требует ручных действий: подключиться по SSH, установить пакеты, добавить параметры подключения и секреты, сконфигурировать kubelet, проверить, что узел появился в кластере, повторить для следующего сервера.

Привет, Хабр! Меня зовут Андрей Волков, я руководитель SRE в команде Managed Service for Kubernetes в Yandex Cloud и мы добавили возможность подключать BareMetal-серверы в кластер Kubernetes одной кнопкой.

Привет, Хабр! Наши sheet-ербьюторы не спят и продолжают развивать экосистему даже утром в субботу, когда сон для усталых взрослых людей. Теперь к делу!

Sheeternetes держит кластер контейнеров, у которого control plane — электронная таблица. Этот пост — про то, как заставить два таких кластера работать как один: on-prem-кластер поверх локального Excel-файла и облачный поверх Google-таблицы — по сети, с общей ёмкостью, живой миграцией и рантаймом, которому не нужен Docker. Всё воспроизводимо; код — один небольшой репозиторий.

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.

Привет, сегодня решила поделиться переводом от Маттео Бизи на вечнозеленую (как оказалось) тему — Shadow AI.

В материале про то, почему ИИ-агентов нужно моделировать как угрозу, а не просто как инструмент продуктивности.

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

Меня зовут Александр Прохоров. Я эксперт команды разработки Developer Productivity в VK Cloud. В статье расскажу, почему классическая инфраструктура тормозила развитие ИИ-проектов и какой подход к управлению вычислительными ресурсами стал ответом на эти вызовы.

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде Kubernetes Security, MWS Cloud Platform. В этой статье я расскажу об одной попытке оптимизации: как мы залезли под капот CEL и Protobuf, чтобы научить интерпретатор читать данные из бинарного формата на лету без полной десериализации, и почему в итоге от этого кода пришлось отказаться.

Почему мы вообще этим озадачились: в одном из наших микросервисов реализовано сканирование приходящих событий по k8s-манифестам. Событий летит много, а обрабатывать их надо быстро, так что, чтобы минимизировать сетевой трафик и снизить нагрузку на инфраструктуру, в качестве основного формата передачи данных мы первоначально решили использовать Protobuf, он значительно компактнее JSON.

Далее эти данные проходят через различные валидации и проверки. Для описания и выполнения таких политик мы используем CEL — наподобие Kyverno или нативных k8s Validating (и Mutating) Admission Policies. Вот тут-то Protobuf и CEL встретились, и эта встреча оказалась не такой гладкой, как мы рассчитывали, — об этом подробнее ниже.

SRE‑инженер Mindbox Дима Рыбалка рассказывает, как команда за два месяца перенесла 40 кластеров ClickHouse в Yandex Cloud. Внутри — как выбирали стратегию миграции, связывали кластеры без VPN, переключали клиентов через cutover без даунтайма и с какими столкнулись проблемами после миграции. Материал будет полезен SRE‑, DevOps‑ и DBA‑инженерам, которые работают с ClickHouse в Kubernetes.

По прогнозу Gartner, к концу 2026 года task-specific AI-агенты будут встроены в 40% корпоративных приложений против менее чем 5% в 2025-м по оценке той же Gartner. Безопасность агента обычно сводят к guardrails, промпт-фильтрам и хорошо написанной системной инструкции. Однако в июле 2025-го случился инцидент —  агент Replit удалил прод-базу SaaStr, хотя его несколько раз просили ничего не менять. А в июле 2026-го на Хабре был опубликован разбор того, как имя, работодатель и город пользователя ушли наружу через Claude без единого клика с его стороны.

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

Объём неиспользуемых ресурсов не уменьшается (хотя вроде как должен), а узлы бесконечно ротируются. Это нормально для автоскейлера или пора что-то чинить?

В статье — детально о механизме консолидации в Karpenter, а главное — можно (и нужно) ли как-то его исправлять.

Всем привет! Решил поделиться с вами опытом написания и проведения ревью аудит‑политики Kubernetes.

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

Недавно я сел перечитать собственный конфиг на 500+ строк — собирал его из нескольких источников, в первую очередь опираясь на Kubernetes Threat Matrix. Хочу поделиться не столько конкретными находками (так как они специфичны для конкретного кластера), сколько принципами и типовыми ловушками, которые всплыли в процессе ревью. Если вы пишете или проводите ревью политики аудита для своего кластера — этот чек‑лист вполне сэкономит время.

Go показывает стабильную память, heap-профиль молчит, а Kubernetes всё равно убивает под по OOM. Разберём, откуда берётся это расхождение, как на поведение под лимитами влияют cgroup, GOMAXPROCS и GOMEMLIMIT и что изменилось в последних версиях Go.

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission‑critical система «лежит», потому что истёк TLS‑сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert‑manager» — это не всегда финал истории.

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

Вторая половина выпуска для тех, кто читает сам: три класса хранения в S3, отмена удаления баз, клон приложения в App Platform, домены через Госуслуги и обновленный Kubernetes.

Разворачиваем каждый пункт ниже ↓