Aks | The .NET Blog

Aspire 13.3 : Support Kubernetes, Journaux du Navigateur et la Compétence Aspireify

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

Cinq semaines, ce n’est pas beaucoup pour une version, mais Aspire 13.3 ne le semble pas. Les éléments principaux sont significatifs : déploiement Kubernetes et AKS de première classe avec Helm, une compétence d’intégration assistée par agent appelée Aspireify, la capture des journaux du navigateur directement dans le dashboard et des résultats de commandes structurés. En plus, 45 nouvelles fonctionnalités, 134 améliorations et 93 corrections de bugs.

Passons aux points saillants.

Aspireify : Intégration Assistée par Agent

Ajouter Aspire à un projet existant semble simple — ajoutez un AppHost, c’est fait. En pratique, cela implique beaucoup d’archéologie : quels ports comptent, quelles variables d’environnement sont de vraies dépendances, quels services Docker Compose doivent correspondre aux intégrations Aspire.

La nouvelle compétence Aspireify donne à votre agent de code un flux de travail guidé précisément pour cela. Quand aspire init crée un AppHost squelette, la compétence Aspireify aide l’agent à inspecter le dépôt, à comprendre comment il fonctionne déjà et à câbler l’AppHost pour s’adapter à l’application — pas l’inverse.

La posture par défaut est “minimiser les modifications de votre code.” Si votre application lit déjà DATABASE_URL, l’agent le mappe avec WithEnvironment() au lieu de vous demander de réécrire votre configuration. Si un port est codé en dur, la compétence indique à l’agent quand le préserver.

C’est le type d’outillage IA qui fait réellement gagner du temps plutôt que de générer plus de travail à revoir.

Déploiement Kubernetes et AKS de Première Classe

Celui-là était sur la liste de souhaits depuis un moment. Aspire 13.3 inclut le support de déploiement Kubernetes et AKS de première classe avec Helm. Vous pouvez maintenant cibler AKS comme destination de déploiement directement depuis les outils Aspire.

Pour les équipes qui exécutent déjà des charges de travail de production sur AKS, cela comble un écart significatif. Votre modèle d’application Aspire a maintenant un chemin propre du développement local vers Kubernetes sans rédaction manuelle de charts Helm.

Journaux du Navigateur dans le Dashboard

C’est une de ces fonctionnalités qui semblent mineures jusqu’à ce que vous déboguiez un problème frontend.

La nouvelle API WithBrowserLogs() attache une ressource de navigateur suivie à toute ressource capable d’endpoints. Aspire lance Chromium en utilisant un pipe CDP privé et diffuse les journaux de console, les requêtes réseau et les erreurs directement dans le flux de journaux de la ressource :

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

L’AppHost TypeScript prend en charge la même chose :

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

Erreurs de console, requêtes réseau échouées, exceptions côté client — tout visible dans le même dashboard où vous regardez déjà les traces et métriques. Plus besoin de changer d’onglet vers les DevTools du navigateur pour les bases.

Résultats de Commandes Structurés

Les commandes de ressources ont reçu une mise à niveau significative. Jusqu’à présent, les commandes renvoyaient succès/échec. Maintenant elles retournent des résultats structurés : texte, JSON ou markdown qui circule à travers le modèle, l’interface du dashboard, la CLI et les outils MCP.

Le dashboard relie tout cela avec un nouveau centre de notifications dans l’en-tête. Les résultats des commandes apparaissent sous forme de notifications horodatées avec rendu markdown et une action “Voir la réponse”.

Cela rend les commandes de ressources véritablement composables. Une intégration peut maintenant exposer une commande qui renvoie une sortie significative — comme une URL de tunnel — plutôt que de simplement changer d’état quelque part.

En Résumé

Aspire 13.3 vaut la mise à jour ne serait-ce que pour le support Kubernetes. Les journaux du navigateur et les résultats de commandes structurés ressemblent au type d’améliorations de qualité de vie qui s’accumulent rapidement dans un flux de travail de développement quotidien.

Notes de version complètes : What’s New in Aspire 13.3

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous construisez des agents IA avec .NET en ce moment, vous avez probablement remarqué quelque chose : il y a beaucoup de façons de les héberger sur Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — et tous semblent raisonnables jusqu’à ce que vous ayez réellement besoin d’en choisir un. Microsoft vient de publier un guide complet sur l’hébergement d’agents IA sur Azure qui clarifie tout ça, et je veux le décomposer du point de vue pratique d’un développeur .NET.

Les six options en un coup d’œil

Voici comment je résumerais le paysage :

Option	Idéal pour	Vous gérez
Container Apps	Contrôle total des conteneurs sans complexité K8s	Observabilité, état, cycle de vie
AKS	Conformité entreprise, multi-cluster, réseau personnalisé	Tout (c’est le but)
Azure Functions	Tâches d’agents événementielles et courtes	Presque rien — vrai serverless
App Service	Agents HTTP simples, trafic prévisible	Déploiement, config de scaling
Foundry Agents	Agents sans code via portail/SDK	Presque rien
Foundry Hosted Agents	Agents framework personnalisé avec infra gérée	Uniquement votre code d’agent

Les quatre premières sont du compute généraliste — vous pouvez y exécuter des agents, mais elles n’ont pas été conçues pour ça. Les deux dernières sont natives aux agents : elles comprennent les conversations, les appels d’outils et les cycles de vie des agents comme des concepts de première classe.

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

C’est ce qui a attiré mon attention. Les Foundry Hosted Agents se situent pile au milieu : vous obtenez la flexibilité d’exécuter votre propre code (Semantic Kernel, Agent Framework, LangGraph — peu importe) mais la plateforme gère l’infrastructure, l’observabilité et la gestion des conversations.

La pièce clé est le Hosting Adapter — une fine couche d’abstraction qui connecte votre framework d’agents à la plateforme Foundry. Pour Microsoft Agent Framework, ça ressemble à ça :

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

C’est toute votre histoire d’hébergement. L’adapter gère la traduction de protocoles, le streaming via server-sent events, l’historique de conversation et le traçage OpenTelemetry — tout automatiquement. Pas de middleware personnalisé, pas de plomberie manuelle.

Le déploiement est vraiment simple

J’ai déployé des agents sur Container Apps avant et ça fonctionne, mais on finit par écrire beaucoup de code de colle pour la gestion d’état et l’observabilité. Avec Hosted Agents et azd, le déploiement c’est :

# Installer l'extension agent IA
azd ext install azure.ai.agents

# Initialiser depuis un template
azd ai agent init

# Construire, pousser, déployer — terminé
azd up

Ce seul azd up construit votre conteneur, le pousse vers ACR, provisionne le projet Foundry, déploie les endpoints de modèle et démarre votre agent. Cinq étapes condensées en une seule commande.

Gestion de conversations intégrée

C’est la partie qui fait gagner le plus de temps en production. Au lieu de construire votre propre store d’état de conversation, les Hosted Agents le gèrent nativement :

# Créer une conversation persistante
conversation = openai_client.conversations.create()

# Premier tour
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Deuxième tour — le contexte est préservé
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Pas de Redis. Pas de store de sessions Cosmos DB. Pas de middleware personnalisé pour la sérialisation des messages. La plateforme gère tout simplement.

Mon framework de décision

Après avoir passé en revue les six options, voici mon modèle mental rapide :

Vous avez besoin de zéro infrastructure ? → Foundry Agents (portail/SDK, pas de conteneurs)
Vous avez du code d’agent personnalisé mais voulez un hébergement géré ? → Foundry Hosted Agents
Vous avez besoin de tâches d’agents événementielles et courtes ? → Azure Functions
Vous avez besoin d’un contrôle maximum des conteneurs sans K8s ? → Container Apps
Vous avez besoin de conformité stricte et multi-cluster ? → AKS
Vous avez un agent HTTP simple avec un trafic prévisible ? → App Service

Pour la plupart des développeurs .NET qui construisent avec Semantic Kernel ou Microsoft Agent Framework, Hosted Agents est probablement le bon point de départ. Vous obtenez le scale-to-zero, OpenTelemetry intégré, la gestion des conversations et la flexibilité de framework — sans gérer Kubernetes ni monter votre propre stack d’observabilité.

Pour conclure

Le paysage de l’hébergement d’agents sur Azure mûrit rapidement. Si vous démarrez un nouveau projet d’agent IA aujourd’hui, je considérerais sérieusement Foundry Hosted Agents avant de recourir à Container Apps ou AKS par habitude. L’infrastructure gérée fait gagner un temps réel, et le pattern hosting adapter vous permet de garder votre choix de framework.

Consultez le guide complet de Microsoft et le repo Foundry Samples pour des exemples fonctionnels.

KubeCon Europe 2026 : Ce que les développeurs .NET devraient vraiment retenir

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous connaissez cette sensation quand un énorme post d’annonces tombe et que vous scrollez en pensant « cool, mais concrètement ça change quoi pour moi » ? C’est moi à chaque saison KubeCon.

Microsoft vient de publier son récapitulatif complet de KubeCon Europe 2026 — écrit par Brendan Burns en personne — et honnêtement ? Il y a du vrai contenu ici. Pas juste des cases à cocher, mais des améliorations opérationnelles qui changent votre façon de gérer les choses en production.

Laissez-moi décortiquer ce qui compte vraiment pour nous développeurs .NET.

mTLS sans la taxe du service mesh

Voici le truc avec les service meshes : tout le monde veut les garanties de sécurité, personne ne veut la charge opérationnelle. AKS comble enfin cet écart.

Azure Kubernetes Application Network vous donne le TLS mutuel, l’autorisation consciente de l’application et la télémétrie du trafic — sans déployer un mesh complet avec sidecars. Combiné avec Cilium mTLS dans Advanced Container Networking Services, vous obtenez une communication chiffrée pod-à-pod utilisant des certificats X.509 et SPIRE pour la gestion des identités.

Ce que ça signifie en pratique : vos APIs ASP.NET Core qui communiquent avec des workers en arrière-plan, vos services gRPC qui s’appellent mutuellement — tout chiffré et vérifié au niveau réseau, sans aucune modification de code. C’est énorme.

Pour les équipes qui migrent depuis ingress-nginx, il y a aussi Application Routing avec Meshless Istio avec support complet de Kubernetes Gateway API. Pas de sidecars. Basé sur les standards. Et ils ont livré des outils ingress2gateway pour une migration incrémentale.

Observabilité GPU qui n’est pas une pensée après coup

Si vous exécutez de l’inférence IA aux côtés de vos services .NET (et soyons honnêtes, qui ne commence pas ?), vous avez probablement rencontré l’angle mort du monitoring GPU. Vous aviez de super dashboards CPU/mémoire et ensuite… rien pour les GPU sans configuration manuelle d’exporteurs.

AKS expose maintenant les métriques GPU nativement dans Prometheus et Grafana managés. Même stack, mêmes dashboards, même pipeline d’alertes. Pas d’exporteurs custom, pas d’agents tiers.

Côté réseau, ils ont ajouté de la visibilité par flux pour le trafic HTTP, gRPC et Kafka avec une expérience Azure Monitor en un clic. IPs, ports, workloads, direction des flux, décisions de policies — tout dans des dashboards intégrés.

Et voici celle qui m’a fait regarder deux fois : agentic container networking ajoute une interface web où vous pouvez poser des questions en langage naturel sur l’état réseau de votre cluster. « Pourquoi le pod X n’atteint-il pas le service Y ? » → diagnostics en lecture seule depuis la télémétrie en direct. C’est vraiment utile à 2h du matin.

Networking cross-cluster sans avoir besoin d’un doctorat

Le multi-cluster Kubernetes a toujours été une expérience « apportez votre propre colle réseau ». Azure Kubernetes Fleet Manager propose maintenant du networking cross-cluster via un cluster mesh Cilium managé :

Connectivité unifiée entre clusters AKS
Registre global de services pour la découverte cross-cluster
Configuration gérée centralement, pas répétée par cluster

Si vous exécutez des microservices .NET sur plusieurs régions pour la résilience ou la conformité, ça remplace beaucoup de colle custom fragile. Le Service A en West Europe peut découvrir et appeler le Service B en East US à travers le mesh, avec des politiques de routage et de sécurité cohérentes.

Des mises à jour qui ne demandent pas du courage

Soyons honnêtes — les mises à jour Kubernetes en production sont stressantes. « Mettre à jour et espérer » a été la stratégie de fait pour trop d’équipes, et c’est la raison principale pour laquelle les clusters restent en retard sur les versions.

Deux nouvelles capacités changent la donne :

Les blue-green agent pool upgrades créent un pool de nœuds parallèle avec la nouvelle configuration. Validez le comportement, déplacez le trafic progressivement et gardez un chemin de rollback propre. Plus de mutations in-place sur les nœuds de production.

Le rollback d’agent pool permet de revenir à la version Kubernetes et l’image de nœud précédentes d’un pool après qu’une mise à jour se passe mal — sans reconstruire le cluster.

Ensemble, ils donnent enfin aux opérateurs un vrai contrôle sur le cycle de vie des mises à jour. Pour les équipes .NET, c’est important car la vélocité de la plateforme contrôle directement la vitesse à laquelle vous pouvez adopter de nouveaux runtimes, patchs de sécurité et capacités réseau.

Les workloads IA deviennent des citoyens de première classe Kubernetes

Le travail upstream en open-source est tout aussi important. Dynamic Resource Allocation (DRA) vient de passer en GA dans Kubernetes 1.36, faisant du scheduling GPU une vraie fonctionnalité de première classe plutôt qu’un contournement.

Quelques projets à surveiller :

Projet	Ce qu’il fait
AI Runway	API Kubernetes commune pour l’inférence — déployez des modèles sans connaître K8s, avec découverte HuggingFace et estimations de coûts
HolmesGPT	Dépannage agentique pour le cloud-native — maintenant un projet CNCF Sandbox
Dalec	Builds déclaratifs d’images de conteneur avec génération de SBOM — moins de CVE à l’étape de build

La direction est claire : votre API .NET, votre couche d’orchestration Semantic Kernel et vos workloads d’inférence devraient tous tourner sur un modèle de plateforme cohérent. On y arrive.

Par où commencer cette semaine

Si vous évaluez ces changements pour votre équipe, voici ma liste de priorités honnête :

L’observabilité d’abord — activez les métriques GPU et les logs de flux réseau dans un cluster non-prod. Voyez ce que vous avez manqué.
Testez les blue-green upgrades — essayez le workflow de rollback avant votre prochaine mise à jour de cluster en production. Construisez la confiance dans le processus.
Pilotez le networking identity-aware — choisissez un chemin de service interne et activez mTLS avec Cilium. Mesurez l’overhead (spoiler : c’est minimal).
Évaluez Fleet Manager — si vous gérez plus de deux clusters, le networking cross-cluster se rentabilise tout seul en réduisant la colle custom.

Petites expériences, feedback rapide. C’est toujours le bon choix.

Pour conclure

Les annonces KubeCon peuvent être accablantes, mais cette fournée fait vraiment bouger les choses pour les équipes .NET sur AKS. Meilleure sécurité réseau sans overhead de mesh, vraie observabilité GPU, mises à jour plus sûres et des fondations d’infrastructure IA plus solides.

Si vous êtes déjà sur AKS, c’est un excellent moment pour renforcer votre baseline opérationnel. Et si vous prévoyez de migrer des workloads .NET vers Kubernetes — la plateforme vient de devenir nettement plus prête pour la production.