Облачные вычисления *

Команда 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, а не внешний сервис.

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

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

В этот раз поговорим о китайской компании Z.ai и о ее новом поколении линейки GLM, а также об агентной среде разработки ZCode 3.0, ориентированной на написание кода. Заменит ли она привычные Cursor и Open WebUI, став полноценным агентом «все в одном» — разберемся ниже.

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

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

Java уже какое-то время витает в облаках. Всё больше приложений и сервисов переходят на облачную архитектуру. Мы решили не отставать и проверить один из главных проектов для разработки производительных облачных приложений на Java — Quarkus.

Китайские модели дешевле или это ловушка? Разбираемся, как не переплачивать за токены и почему цена в прайсе — еще не вся правда о расходах на ИИ.

Система многофакторной аутентификации находится на критическом участке корпоративной инфраструктуры. Через нее проходят практически все сценарии доступа пользователей: подключение к VPN, вход в виртуальные рабочие столы, корпоративную почту, внутренние веб-приложения, облачные сервисы и административные панели. Если сервис аутентификации становится недоступным, сотрудники не могут начать работу независимо от того, насколько исправно функционируют остальные информационные системы.

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

За последние несколько лет мы реализовали обе модели. MULTIFACTOR используется как классическое on-premise решение внутри инфраструктуры заказчиков и одновременно существует как облачный сервис, который ежедневно обслуживает более миллиона пользователей. За это время стало очевидно, что вопрос «облако или коробка» уже не отражает реальную картину. Гораздо важнее понять, какие требования предъявляются к системе и каким образом должна быть построена ее архитектура.

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

Но вот какова правда: для корректной работы продьюсеров в событийно-ориентированной системе не обязательно упорядочивать события. Действительно не обойтись без свойств, обеспечивающих правильный контекст — такой информации, как номера версий, метки времени updatedAt и идентификаторы объектов, по которой потребители могут самостоятельно судить о свежести и согласованности событий.

Нейросети работают на GPU — это вроде бы очевидно. А что, если я вас скажу, что аж в 2018 году группа из UCLA напечатала нейросеть на 3D‑принтере из обычного пластика. Пять пластин. И никаких транзисторов. Никакой памяти. Никакого электричества. Причем, точность распознавания рукописных цифр — 91.75%.

И оно, чудо это — работало.

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

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

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

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. Он работает как десктопное приложение или внутри кластера, а через систему плагинов кто угодно может добавить полноценные представления для пользовательских ресурсов.

Что такое гиперскейлер и в чем его неотъемлемая связь с облачными вычислениями и советскими НИИ?

Сегодня мы попробуем ответить на этот вопрос, а также рассказать, как развитие технологий позволило AWS, Google Cloud, MS Azure и российским Yandex Cloud и Cloud.ru стать крупнейшими облачными провайдерами. 

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен 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, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

Привет! Я Артур Валиев. Мы с командой EvertyDesk размышляем над экспериментальным режимом для игрового стриминга и хотим обсудить не очередной ползунок качества, не новый пресет битрейта и не надпись Ultra Low Latency на главном экране.

Нас интересует более странный вопрос:

Привет! Меня зовут Александр Титов. Я директор Ассоциации профессионалов индустрии облачно-ориентированных технологий «АОТ», организатор сообщества DevOps Moscow и генеральный директор «Фланта». В этом посте я расскажу, как получилось так, что я не только занимаюсь предпринимательством, но и руковожу некоммерческой ассоциацией, которая развивает облачно-ориентированные технологии в России, и почему, на мой взгляд, сегодня отрасли нужна именно такая форма работы.

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

Стройку видно не по чертежам, а по бетону. У энергоцентра в Марфино появилось то, с чего начинается любая стройка, — фундамент.

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

Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?

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

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

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

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