Команда VK Cloud подготовила перевод обзора релиз-команды Kubernetes (Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor) из блога kubernetes.io. О том, что устареет, сломается и перейдёт в GA в Kubernetes v1.37, релиз которого запланирован на 26 августа 2026 года. Будет полезен тем, кто эксплуатирует кластеры Kubernetes в проде: DevOps- и SRE-инженерам, платформенным командам, которые планируют обновление.

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

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.

В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. 

Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии  4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.

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

База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

Security Gate — это наша внутренняя AppSec-платформа, объединяющая инструменты и практики для проверки безопасности кода, зависимостей и других компонентов разработки. Платформа помогает находить потенциальные проблемы безопасности, приоритизировать результаты сканирования и встраивать проверки в привычный процесс работы с кодом.

В статье разберём, из чего состоит Security Gate, как устроены приоритизация находок и интерфейс и какие возможности доступны разработчикам.

Демо нагрузки и реальная нагрузка различаются. Демо всегда быстрое — если поставить модель и прогнать пару запросов, то latency вас обрадует, а TTFT, вероятнее всего, будет приятным. Но когда сервис неделю живет под реальной нагрузкой, начинаются проблемы: p99 растет, память утекает, а однажды прилетает OOM на запросе, который вчера проходил без проблем.

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

Ниже я разберу четыре механизма, приводящие к деградации производственной среды на длительном интервале: фрагментацию KV-кэша, нехватку памяти (OOM) при работе с длинным контекстом, блокировку очереди (head-of-line blocking) внутри батча и расхождение метрик p50 и p99. Для каждого случая опишу внутреннее поведение системы, способы воспроизведения проблемы и метрики, сигнализирующие о надвигающемся инциденте.

В 2024 году была опубликована интересная статья, в которой описано, как за 54 дня обучения Llama 3 405B кластер Meta из 16 384 карт H100 пережил 419 внезапных прерываний, примерно по одному каждые три часа. 58,7% из них пришлись на GPU и их память. Процессоры за то же время отказали дважды. Свежее по такому масштабу никто ничего не публиковал, но тренд на Kubernetes с тех пор только усилился: по опросу CNCF за 2025 год, 82% пользователей контейнеров гоняют кубер в проде и 66% компаний с genAI-моделями держат на нем инференс.

Сам Kubernetes до сих пор как будто бы уверен, что отказы лечатся рестартами. Для stateless-сервиса это правда, а вот для пода с GPU нет: если контейнер упадет, то kubelet поднимет его заново на том же мертвом устройстве, и все пойдет по кругу.

Я Стас Погоржельский, технологический евангелист VK Cloud. Про то, как раздавать GPU через DRA, на Хабре уже писали, про отказоустойчивость кластеров в целом тоже. Эта статья про то, о чем обе умалчивают: что происходит после того, как выданное устройство умерло. Мы посмотрим на это наглядно: соберем отказный стенд, отберем у пода GPU и посмотрим глазами kubectl, кто и когда об этом узнает. А потом разберем механизмы 1.36, с которыми из этой ситуации впервые можно выйти без вечного Pending и без убийства ноды целиком.

Управление десятками и сотнями Helm-релизов быстро перестает быть тривиальной задачей, особенно когда появляются зависимости между релизами, CRD, несколько окружений и своя логика деплоя. 

Меня зовут Владимир Фидунин, я работаю в команде мессенджера VK WorkSpace. В статье расскажу, как мы прошли путь от Puppet + Helm до Helmwave и почему в итоге он стал для нас универсальным инструментом управления Helm-релизами. 

Kubernetes незаметно стал платформой по умолчанию для ИИ и машинного обучения. Запускаете ли вы серверы notebook-ов для дата-сайентистов, планируете распределённые задачи обучения, настраиваете гиперпараметры или оркестрируете многоэтапные ML-пайплайны. Эти нагрузки всё чаще оказываются в кластере Kubernetes. Kubeflow — один из самых популярных способов собрать этот стек, причём Kubernetes-нативным путём: каждая возможность описана как CRD (Custom Resource Definition, описание пользовательского типа ресурса Kubernetes).

Такая архитектура подарок операторам кластера: ML-нагрузки можно наблюдать и управлять ими теми же примитивами, что и всем остальным в кластере. Но на практике специализированные ML-дашборды, которые поставляются с этими платформами, скрывают лежащий под ними слой Kubernetes. Когда notebook застревает или задача обучения падает, оператор часто вынужден откатываться к kubectl, чтобы выяснить, что на самом деле произошло на уровне Pod.

Команда VK Cloud перевела статью о плагине Headlamp Kubeflow, который закрывает этот разрыв и выводит пользовательские ресурсы Kubeflow прямо внутри универсального Kubernetes UI. Это проработанный пример паттерна, которому может следовать любая насыщенная CRD платформа: встречать операторов там, где они уже работают, и показывать им истину на уровне кластера.

Сам Headlamp это расширяемый веб-UI для Kubernetes, поддерживаемый в рамках Kubernetes SIG UI и лицензированный под Apache 2.0. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто.

В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы.

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

В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях.

Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

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

Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

Команда VK Cloud перевела заключительную часть цикла Cilium про защиту цепочки поставок. Часть 1 была про контроль доступа, часть 2 — про укрепление зависимостей. Эта же часть о том, как изолировать секреты CI и продакшена за разными окружениями GitHub, подписывать каждый релиз без долгоживущих ключей через Sigstore Cosign, и какие пробелы безопасности остаются открытыми. Отдельно — разбор дорожной карты безопасности GitHub Actions на 2026 год и того, как платформенные изменения соотносятся с уже выстроенными контролями. Полезно DevOps- и SRE-инженерам, специалистам по безопасности и мейнтейнерам OSS-проектов.

Команда VK Cloud перевела второй пост из серии трёх частей о том, как Cilium укрепляет свой CI/CD-конвейер. Первая часть рассказывала про управление доступом: кто может запускать сборки и какой CI-код разрешено исполнять. Этот пост про уровень зависимостей: какой код эти сборки подтягивают и как мы убеждаемся, что его не подделали.

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 для контейнеров.

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

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье разберем, почему каталог — это не первый шаг к порядку, а скорее мультипликатор уже существующей зрелости и что необходимо сделать, чтобы его внедрение принесло реальную пользу.

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

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

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

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

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

Привет, Хабр. Меня зовут Дмитрий Сергеев. Я менеджер продукта «виртуальные серверы» (GPU) в компании VK Tech.

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

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

Привет, Хабр! Меня зовут Андрей Орлов, я QA‑инженер в команде Tarantool Database, VK Tech. Я занимаюсь функциональным тестированием: проверяю новые фичи и изменения, поддерживаю и развиваю автотесты, разбираю инциденты, анализирую логи и метрики. Нагрузочное тестирование и стресс‑тестирование тоже входит в мои задачи — в том числе для проверки поведения Tarantool Database на больших конфигурациях. В этой статье я расскажу, как мы организовали и провели тестирование Tarantool Database на 640 инстансах, какие подходы и инструменты использовали и какие выводы сделали.

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

VK Cloud активно использует РЕД ОС от РЕД СОФТ — в том числе в VK Secure Cloud, аттестованном контуре для значимых объектов критической информационной инфраструктуры (ЗОКИИ). На ее примере покажу, как поднять производительность гипервизора, просто обновив легаси и не трогая железо. Вместе с дистрибутивом на ноду приезжает свежий стек целиком: ядро, эмулятор, клиент хранилища, системные библиотеки. Каждый слой подтягивает свой кусок. А для тех, кто застрял на CentOS, ушедшем в EOL, у истории есть вторая часть: обновление закрывает технический разрыв и регуляторику одним движением. Ниже разберу механику по слоям с командами, которые можно выполнить на своей системе.

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

Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.

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