Kubernetes | The .NET Blog

Aspire 13.3: Поддержка Kubernetes, журналы браузера и навык Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Пять недель — небольшой срок для релиза, но Aspire 13.3 так не ощущается. Ключевые элементы весомые: первоклассное развёртывание Kubernetes и AKS с Helm, навык онбординга с помощью агента под названием Aspireify, захват журналов браузера прямо в дашборде и структурированные результаты команд. Плюс 45 новых функций, 134 улучшения и 93 исправления ошибок.

Давайте разберём основные моменты.

Aspireify: Онбординг с помощью агента

Добавление Aspire к существующему проекту звучит просто — добавьте AppHost, готово. На практике это требует немало исследований: какие порты важны, какие переменные окружения являются реальными зависимостями, какие сервисы Docker Compose должны отображаться на интеграции Aspire.

Новый навык Aspireify даёт вашему агенту кодирования управляемый рабочий процесс именно для этого. Когда aspire init создаёт скелетный AppHost, навык Aspireify помогает агенту проверить репозиторий, понять как он уже работает и подключить AppHost так, чтобы он соответствовал приложению — а не наоборот.

Позиция по умолчанию — “минимизировать изменения в вашем коде.” Если ваше приложение уже читает DATABASE_URL, агент сопоставляет это с WithEnvironment() вместо того, чтобы просить вас переписать конфигурацию. Если порт жёстко задан, навык указывает агенту, когда его сохранить.

Это именно тот тип ИИ-инструментов, который реально экономит время, а не генерирует больше работы для проверки.

Первоклассное развёртывание Kubernetes и AKS

Это было в списке пожеланий уже давно. Aspire 13.3 поставляется с первоклассной поддержкой развёртывания Kubernetes и AKS с Helm. Теперь вы можете указывать AKS в качестве целевого объекта развёртывания прямо из инструментов Aspire.

Для команд, которые уже запускают производственные нагрузки на AKS, это закрывает значительный пробел. Ваша модель приложения Aspire теперь имеет чёткий путь от локальной разработки до Kubernetes без ручного создания Helm-чартов.

Журналы браузера в дашборде

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

Новый API WithBrowserLogs() прикрепляет отслеживаемый ресурс браузера к любому ресурсу, поддерживающему endpoint’ы. Aspire запускает Chromium с использованием приватного CDP-пайпа и передаёт журналы консоли, сетевые запросы и ошибки прямо в поток журналов ресурса:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost поддерживает то же самое:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

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

Структурированные результаты команд

Команды ресурсов получили значительное обновление. До сих пор команды возвращали успех/неудачу. Теперь они возвращают структурированные результаты: текст, JSON или markdown, который проходит через модель, интерфейс дашборда, CLI и MCP-инструменты.

Дашборд связывает всё это с новым центром уведомлений в заголовке. Результаты команд отображаются как уведомления с временными метками с рендерингом markdown и действием “Просмотреть ответ”.

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

Итог

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

Полные заметки о выпуске: What’s New in Aspire 13.3

KubeCon Europe 2026: Что на самом деле важно для .NET-разработчиков

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальную версию можно прочитать здесь.

Знаете это чувство, когда выходит огромный пост с анонсами и вы листаете его, думая «круто, но что это на самом деле меняет для меня»? Это я каждый сезон KubeCon.

Microsoft только что опубликовала свой полный обзор KubeCon Europe 2026 — написанный лично Бренданом Бёрнсом — и честно? Здесь настоящая суть. Не просто чеклисты фич, а операционные улучшения, которые меняют подход к управлению в продакшене.

Давайте разберём, что действительно важно для нас, .NET-разработчиков.

mTLS без налога service mesh

Вот в чём дело с service mesh: все хотят гарантий безопасности, никто не хочет операционной нагрузки. AKS наконец закрывает этот разрыв.

Azure Kubernetes Application Network даёт вам mutual TLS, авторизацию с учётом приложения и телеметрию трафика — без развёртывания полного mesh с тяжёлыми sidecar. В сочетании с Cilium mTLS в Advanced Container Networking Services вы получаете зашифрованную связь между подами с использованием сертификатов X.509 и SPIRE для управления идентификацией.

Что это значит на практике: ваши ASP.NET Core API общаются с фоновыми воркерами, ваши gRPC-сервисы вызывают друг друга — всё зашифровано и верифицировано на сетевом уровне, без единого изменения в коде приложения. Это серьёзно.

Для команд, мигрирующих с ingress-nginx, есть также Application Routing с Meshless Istio с полной поддержкой Kubernetes Gateway API. Без sidecar. На основе стандартов. Плюс инструменты ingress2gateway для постепенной миграции.

Наблюдаемость GPU — не как запоздалая мысль

Если вы запускаете AI-инференс рядом с .NET-сервисами (а давайте честно, кто сейчас не начинает?), вы наверняка столкнулись со слепым пятном мониторинга GPU. У вас были отличные дашборды CPU/памяти, а потом… ничего для GPU без ручной настройки экспортёров.

AKS теперь показывает метрики GPU нативно в управляемых Prometheus и Grafana. Тот же стек, те же дашборды, тот же пайплайн алертов. Без кастомных экспортёров, без сторонних агентов.

На сетевой стороне добавлена видимость по потокам для HTTP, gRPC и Kafka-трафика с Azure Monitor в один клик. IP, порты, ворклоуды, направление потока, решения по политикам — всё во встроенных дашбордах.

А вот то, от чего я посмотрел дважды: agentic container networking добавляет веб-интерфейс, где можно задавать вопросы на естественном языке о состоянии сети кластера. «Почему под X не достигает сервис Y?» → диагностика только для чтения из live-телеметрии. Реально полезно в 2 часа ночи.

Кросс-кластерная сеть без учёной степени

Мульти-кластерный Kubernetes исторически был опытом «принеси свой сетевой клей». Azure Kubernetes Fleet Manager теперь обеспечивает кросс-кластерную сеть через управляемый Cilium cluster mesh:

Единая связность между кластерами AKS
Глобальный реестр сервисов для кросс-кластерного обнаружения
Конфигурация управляется централизованно, а не повторяется для каждого кластера

Если вы запускаете .NET-микросервисы в нескольких регионах для отказоустойчивости или соответствия требованиям, это заменяет много хрупкого кастомного клея. Сервис A в West Europe может обнаружить и вызвать Сервис B в East US через mesh, с согласованными политиками маршрутизации и безопасности.

Обновления, не требующие смелости

Давайте честно — обновления Kubernetes в продакшене — это стресс. «Обновить и надеяться» было стратегией по умолчанию для слишком многих команд и главной причиной, по которой кластеры отстают по версиям.

Две новые возможности меняют это:

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

Откат пула агентов позволяет вернуть пул нод на предыдущую версию Kubernetes и образ ноды после неудачного обновления — без пересборки кластера.

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

AI-рабочие нагрузки становятся полноценными гражданами Kubernetes

Upstream-работа в open source не менее важна. Dynamic Resource Allocation (DRA) только что стала GA в Kubernetes 1.36, сделав планирование GPU настоящей первоклассной функцией вместо обходного пути.

Проекты, за которыми стоит следить:

Проект	Что делает
AI Runway	Общий Kubernetes API для инференса — деплой моделей без знания K8s, с обнаружением HuggingFace и оценкой стоимости
HolmesGPT	Агентный troubleshooting для cloud-native — теперь проект CNCF Sandbox
Dalec	Декларативная сборка образов контейнеров с генерацией SBOM — меньше CVE на этапе сборки

Направление ясно: ваш .NET API, слой оркестрации на Semantic Kernel и ваши рабочие нагрузки инференса должны работать на одной согласованной платформенной модели. Мы приближаемся.

С чего бы я начал на этой неделе

Если вы оцениваете эти изменения для своей команды, вот мой честный список приоритетов:

Наблюдаемость в первую очередь — включите метрики GPU и логи сетевых потоков в непродакшен-кластере. Посмотрите, что вы упускали.
Попробуйте blue-green обновления — протестируйте workflow отката перед следующим обновлением продакшен-кластера. Постройте доверие к процессу.
Пилотируйте сеть с учётом идентичности — выберите один внутренний путь сервиса и включите mTLS с Cilium. Измерьте оверхед (спойлер: минимальный).
Оцените Fleet Manager — если у вас больше двух кластеров, кросс-кластерная сеть окупается за счёт сокращения кастомного клея.

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

Подводя итог

Анонсы KubeCon могут быть ошеломляющими, но эта порция реально двигает стрелку для .NET-команд на AKS. Лучшая сетевая безопасность без оверхеда mesh, настоящая наблюдаемость GPU, более безопасные обновления и более прочные основы AI-инфраструктуры.

Если вы уже на AKS, сейчас отличный момент укрепить ваш операционный baseline. А если планируете перенести .NET-рабочие нагрузки на Kubernetes — платформа только что стала значительно более готовой к продакшену.