На Build 2026 Microsoft вывалила сразу несколько обновлений для Azure Kubernetes Service, и общий смысл у них довольно прямой: AKS для ИИ компания хочет превратить не в побочный сценарий, а в штатную платформу для обучения моделей, инференса и крупных cloud-native систем. Для русскоязычной IT-аудитории это важно по простой причине: Kubernetes окончательно перестает быть فقط оркестратором микросервисов и все чаще становится тем самым слоем, на котором считают GPU, раскатывают модели и держат под контролем гибридную инфраструктуру.
Как пишет InfoQ, в пакет анонсов вошли AKS on Bare Metal в публичном превью, Azure Kubernetes Fleet Manager для Arc-enabled кластеров в статусе general availability, managed-сервис Anyscale on Azure для Ray-нагрузок в публичном превью, а также дальнейшее развитие связки AI Runway и Kubernetes AI Toolchain Operator (KAITO) для вывода моделей в прод. Если убрать маркетинговую упаковку, Microsoft пытается ответить на вполне практичный вопрос: можно ли запускать тяжелый ИИ на Kubernetes без самодельного зоопарка из отдельных сервисов, скриптов и ручного администрирования. Судя по анонсам, ставка теперь именно на это.
Первая линия обновлений касается базовой эксплуатации кластеров. Microsoft объявила о доступности Managed System Node Pools в AKS Automatic и Azure Container Linux. В первом случае системные компоненты Kubernetes отделяются от прикладной нагрузки, а Azure берет на себя управление емкостью, патчами и масштабированием. Для AI-сценариев с GPU это не косметика: если системные сервисы начинают конкурировать с workload за ресурсы, проседают и производительность, и предсказуемость. Azure Container Linux, в свою очередь, подается как легковесная ОС, которую сама Microsoft поддерживает и оптимизирует под контейнерные нагрузки. Смысл тот же, что и у многих аналогичных инициатив облачных провайдеров: чем меньше дрейф конфигураций и ручной возни в кластере, тем проще держать в узде большой парк сред.
Самый технически интересный анонс в этой истории, пожалуй, AKS on Bare Metal. Сервис убирает слой виртуализации и дает рабочим нагрузкам прямой доступ к железу, включая NVLink, RDMA и высокопроизводительную сеть. Для обучения крупных моделей и чувствительного к задержкам инференса это звучит гораздо важнее любого ребрендинга: каждая лишняя абстракция на таком стеке стоит денег, а иногда и пропускной способности, которой потом не хватает в самый неподходящий момент. Microsoft прямо говорит, что виртуализация дает гибкость, но может вносить заметные штрафы по производительности для части ИИ-нагрузок. Логика понятна: оставить операционную модель Kubernetes, но приблизить ее по эффективности к выделенному железу. Для компаний, которые считают TCO на кластерах с дорогими GPU, даже небольшой прирост эффективности быстро перестает быть мелочью.
Вторая большая тема - управление не одним кластером, а целым хозяйством. Azure Kubernetes Fleet Manager для Arc-enabled кластеров стал общедоступным и теперь распространяет централизованное управление не только на Azure, но и на on-premises и гибридные окружения. Заявлены fleet-wide policy enforcement, размещение нагрузок, поэтапные rollout'ы и RBAC-управление на уровне всего парка кластеров. Это довольно трезвый взгляд на зрелость Kubernetes: проблема давно уже не в том, чтобы поднять один хороший кластер, а в том, чтобы десятки кластеров в разных регионах и средах вели себя одинаково предсказуемо. Для платформенных команд и IT-директоров здесь самое важное не слово fleet, а попытка собрать governance, операции и выкладку в одну модель. Когда AI-приложения живут сразу в нескольких облаках и еще частично остаются on-prem, ручное управление быстро превращается в дорогое хобби.
Третья часть анонсов касается уже не самого Kubernetes, а того, как поверх него собирать инфраструктуру для моделей. Anyscale on Azure, доступный в публичном превью, приносит managed Ray в экосистему AKS и позволяет оркестрировать распределенные AI-нагрузки на CPU и GPU в автоматически масштабируемых кластерах. Для команд, которые уже смотрят в сторону Ray, это попытка снять часть боли с самостоятельного управления инфраструктурой и вписать ее в стандартные подписки, политики и governance Azure. Параллельно Microsoft продолжает продвигать AI Runway, представленный ранее в 2026 году, как Kubernetes-native слой для деплоя моделей: выбор модели, проверка требований к GPU, оценка стоимости развертывания и запуск production-endpoint'ов через знакомые абстракции. Под капотом KAITO поднимает ресурсы, запускает оптимизированные рантаймы вроде vLLM и стыкуется с такими компонентами, как KEDA и Gateway API. Иначе говоря, Microsoft не прячет Kubernetes за красивой кнопкой, а пытается сделать так, чтобы platform engineering не развалился при первом же выходе модели в прод.
В более широком контексте это еще и ответ на усиливающуюся конкуренцию между облаками за статус основной платформы для AI-инфраструктуры. AWS наращивает связку EKS и Bedrock, Google Cloud вкладывается в GKE и собственные AI-native сценарии, а open-source стек вокруг Ray, vLLM, KubeRay и Gateway API быстро взрослеет. На этом фоне подход Microsoft выглядит не как попытка изобрести еще один полностью закрытый оркестратор, а как сборка из уже признанных open-source компонентов с управляемыми сервисами, политиками и корпоративной обвязкой. Для разработчиков это хороший сигнал: инвестиции в Kubernetes, сетевые API и инструменты платформенной автоматизации не выглядят ставкой на экзотику. Для бизнеса сигнал другой: облачные провайдеры начинают продавать не просто GPU и endpoint'ы, а цельную операционную модель для ИИ.
Главный вопрос теперь не в том, подходит ли Kubernetes для моделей, а в том, где проходит граница его удобства и экономической оправданности. Microsoft явно считает, что AKS для ИИ уже дорос до роли базовой платформы. Если этот расчет верен, в ближайшие релизы рынок будет сравнивать облака не по громкости AI-анонсов, а по куда более скучным и важным метрикам: сколько стоит inference на реальной нагрузке, насколько предсказуемо ведут себя GPU-кластеры и можно ли управлять всем этим без армии людей, которые чинят YAML по ночам.