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

TL;DR. Мы выкатили Татарнетес — национальную обёртку над Kubernetes, где команды, сообщения, ошибки и даже перерывы на чай с чак-чаком и т.п. на татарском. Рядом — TatarOS Linux (обёртка над Talos, которая поднимает кластер с Татарнетесом) и Татарнетес UI (панель на фоне татарского келәма). Всё под собственной лицензией Tatarch 2.0.

Под капотом i18n на чистом bash 3.2 без единой зависимости, три системы письма (кириллица, яңалиф, гарәп язуы), детерминированный чайный график (кластер рандомно останавливается на попить чай с молоком и бабушкиными кыстыбыями) и первый черновик татарской IT-терминологии Kubernetes. А ещё мы прогнали всё на реальном кластере CozyStack — с живыми kubectl/talosctl, RBAC, метриками и одним пойманным багом.

Репозитории tatar-ncf: tatarnetes · tataros · tatarnetes-ui. Лицензия — Tatarch 2.0.

Проект посвящается Саше, Роме, Максу и Рамилю из одного замечательного кубер-чатика.

Лето на площадке в Марфино выдалось насыщенным. Собрали в одном выпуске всё, что произошло за эти месяцы, — и рассказываем, как продвинулась стройка.

Я архитектор и до сих пор отхожу от VMware: Kubernetes дался мне не сразу. Как выяснилось, я не один такой. С этим сталкиваются разработчики в нашей команде, которым нужно быстро освоить Kubernetes для повседневной работы. С этим же сталкиваются ИТ-специалисты широкого профиля у заказчиков: они десятилетиями эксплуатировали vSphere, а теперь уходят от него, потому что всё больше ПО поставляется в контейнерах.

Люди приходят к одному вопросу: с чего действительно начать изучение Kubernetes?

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

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

Команда VK Cloud перевела статью о том, как начать изучать 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-платформа была готова к эксплуатации ИИ-нагрузок.

Крупные дата-центры требуют все больше электричества, а системы охлаждения — еще и воды. Строить ЦОД можно далеко не везде: требуются свободные мощности в энергосети, быстрые каналы связи. А ведь еще нужно покупать/арендовать землю, на которой строятся объекты. Это крайне дорого. Поэтому некоторые компании начали всерьез обсуждать перенос части вычислений в космос. Почему и зачем? 

На орбите спутниковые ЦОД могут почти постоянно получать свет, землю покупать не нужно, а тепло отводится через радиаторы. Вроде все отлично, но есть два огромных «но»: апгрейд и ремонт. Об этом сегодня и поговорим.

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

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

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

«Просто арендую сервер помощнее». Так я думал, когда пет-проект внезапно оброс людьми.

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

Я изучил, как похожие проблемы решают крупные компании, и применил эти принципы на практике.

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

Есть проверенный закон вселенной: если у чего-то есть экран и хоть немного памяти, рано или поздно на этом запустят DOOM. Запускали на осциллографах, на тесте на беременность, на кофемашине и на тракторе. Мы в Sheet-Native Computing Foundation тоже решили побыть в этом уже достаточно запылившемся тренде и запустить DOOM в контейнере, упакованном в ячейки электронной таблицы. То есть образ контейнера с игрой физически лежит в ячейках, оттуда собирается обратно в Docker-образ, проверяется по sha256 и запускается.

В первой статье я рассказывал про Sheeternetes — оркестратор контейнеров, у которого весь control plane (Deployments, Nodes, Pods, Events) живёт внутри Google Таблицы или Excel, а на другом конце крутятся настоящие Docker-контейнеры. Там же мельком был упомянут наш формат образов — SICF (Sheet-Native Image Container Format). Эта статья как раз про него: как он устроен, как всё это воспроизвести у себя, как оно работает на bare metal (то есть в эксельке, а не гугл-таблице) без интернета и какие неожиданно интересные находки вылезли, когда мы начали пихать всё это дело в ячейки Google Sheets.

Спойлер: DOOM — настоящий (Chocolate Doom плюс свободный Freedoom, всё в Linux-контейнере, играется в браузере с клавиатуры).

В одном чате по куберу меня спросили единственное, что реально важно, когда ты собрал оркестратор контейнеров внутри таблицы: а сколько оно вообще тянет? Сколько подов, пока не ляжет. Какой образ влезает в ячейки. Сколько кластеров держит одна машина. И — раз уж мы фонд с серьёзным лицом — как это смотрится рядом с настоящими: Kubernetes, Docker Swarm, Nomad.

Поэтому мы провели честное нагрузочное тестирование. Четыре измерения, два бэкенда (.xlsx на диске и живая Google-таблица), синтетика на ноутбуке и реальные Docker-образы на облачной виртуалке. А потом поставили цифры рядом со взрослыми оркестраторами.

Короткая версия: по каждой оси, которая имеет значение, мы проигрываем на 3–5 порядков. По осям, которые значения не имеют, — выигрываем вчистую. И один наш давний «факт» оказался неверным — бенчмарк нас поправил. Поехали.

Медиана зарплаты DevOps-инженера в 2026 году держится в районе от 220 000 до 250 000 ₽, но разброс внутри одного грейда огромный: у Senior вилка идёт от 300 000 до 850 000 ₽.

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

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

Разбудите меня ночью и спросите «что нельзя делать с ИИ», и я отвечу «грузить конфиденциальные данные». Это правило должно быть записано у нас на подкорке как таблица умножения. Должно, но не факт, что оно срабатывает во всех 100% случаев, тем более если играться с ИИ не в рабочих, а личных целях. Ну что такого может случиться, если я просто попрошу модель перевести кусок текста с эльфийского синдарина на обычный человеческий?

Если вы такой же тревожный параноик, как я, то внутри для вас несколько простых настроек для чатов с ИИ, чтобы спать спокойно. Да, это не абсолютная гарантия, что ничего никуда не утечет и модель ничему от вас не научится, но, как говорится, береженого Бог бережет.

А еще я покажу полный цикл подключения вашего ключа в ИИ-клиент (сноска: приложение, в которое можно подключить сразу несколько ИИ-моделей от разных поставщиков и работать с ними в одном интерфейсе) на примере ChatBox. Будет интересно тем, кто только начинает свое знакомство с миром ИИ и хочет попробовать безопасно внедрить его в свои процессы.

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

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

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

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

Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.

Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.

Привет, Хабр. Меня зовут Сергей Врулин, я Team Lead в команде агентов VK AI Space — корпоративной платформы для создания и запуска AI-агентов.

В июле 2026 года VK AI Space представила многоуровневую память для корпоративных AI‑агентов. Она позволяет агентам сохранять и переиспользовать информацию на всех этапах работы — в текущем диалоге и в рамках долгих проектов. Потенциально это позволит ускорить подготовку ответов и уменьшить число повторных задач.

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

Apache Kafka — популярная система потоковой обработки событий, предназначенная для сбора, хранения и передачи больших объемов данных в режиме реального времени. Она используется тысячами компаний и разработчиков для построения высокопроизводительных, отказоустойчивых и масштабируемых решений в области аналитики данных, IoT, микросервисов и многих других сфер.

Однако у Kafka есть один важный нюанс: «из коробки» у нее нет графического интерфейса (GUI), что затрудняет понимание текущего состояния кластера, диагностику неполадок и эффективное управление инфраструктурой и самим сервисом, особенно для начинающих пользователей или тех, кому сложно взаимодействовать с консольными инструментами.

Поэтому для комфортной работы с Apache Kafka активно используются специализированные UI-инструменты. Например, ранее для облачного сервиса Managed Kafka от VK Cloud мы использовали Provectus Kafka UI, но в рамках развития сервиса решили заменить UI на более современный и функциональный.

Меня зовут Никита Суровегин. Я продукт-менеджер в команде VK Data Platform, VK Tech. В этой статье я расскажу, с чего мы стартовали, какие инструменты проанализировали и что выбрали в итоге.

Состояние российского рынка дистанционного зондирования Земли на август 2026 года

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

Одновременно государство начинает выступать не только владельцем космической инфраструктуры, но и крупным заказчиком данных у различных поставщиков. По оценке руководства Роскосмоса, потенциал российского рынка данных ДЗЗ после запуска новой модели закупок может вырасти более чем в шесть раз — до 31 млрд рублей. При этом уже в 2026 году Роскосмос сообщил о заключении контрактов на предоставление данных ДЗЗ примерно на 5 млрд рублей для федеральных и других государственных органов.

Именно поэтому 2026 год можно считать одним из переломных для российского рынка ДЗЗ.

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

У вас, скорее всего, уже открыт десяток разнообразных вкладок: какая‑нибудь платформа с бесплатными недельными лимитами, вроде Kaggle; что‑нибудь с бесплатными возобновляемыми кредитами, на подобии Lightning AI; возможно, пара площадок со спотовыми машинами по цене чашки кофе, например Vast, но с оговоркой — никто не обещает, что машину не заберут, или у ее владельца не отвалится сеть.

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

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

Итак, приступаем...

Однажды за один вечер мне пришлось разобрать двенадцать ошибок, и почти все прятались в конфигурации и связях между компонентами. Модель отвечала пустой строкой, хотя в логах не было ни одной явной ошибки. Агент не мог достучаться до Ollama, панель не проходила авторизацию, ключ отклонялся из-за прав доступа, а gateway показывал зелёный статус, но будто не замечал изменений в конфиге.

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

Статья написана на основе моего вебинара, можно посмотреть его в записи. 

Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака. Ситуация: на сервере закончилось место. Вы увеличиваете диск, выдыхаете, а через какое-то время все повторяется. Потом приходит время переносить сервер, и вместе с ним переезжают все накопленные файлы. Перенос растягивается на выходные, а трогать эту машину лишний раз уже никому не хочется. Место на диске к этому моменту далеко не единственная проблема.

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

Дальше разберу на примере условной онлайн-школы, как меняются требования к хранению по мере роста проекта и в какой момент стоит посмотреть в сторону сетевых дисков.