Aks | The .NET Blog

On hauríeu d'allotjar els vostres agents d'IA a Azure? Una guia pràctica de decisions

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

Si esteu creant agents d’IA amb.NET ara mateix, probablement heu notat alguna cosa: hi ha * moltes * maneres d’allotjar-los a Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents, i tots semblen raonables fins que realment n’has de triar un. Microsoft acaba de publicar una guia completa per a l’allotjament d’agents d’Azure AI que ho aclareix, i vull desglossar-ho des d’una perspectiva pràctica del desenvolupador.NET.

Les sis opcions d’un cop d’ull

Així és com resumiria el paisatge:

Opció	El millor per	Tu gestiones
Aplicacions de contenidors	Control total del contenidor sense complexitat K8s	Observabilitat, estat, cicle de vida
AKS	Compliment empresarial, multi-clúster, xarxes personalitzades	Tot (aquest és el punt)
Funcions d’Azure	Tasques d’agent de curta durada i impulsades per esdeveniments	No gaire, veritat sense servidor
Servei d’aplicacions	Agents HTTP simples, trànsit previsible	Desplegament, configuració d’escalat
Agents de Foundry	Agents opcionals de codi a través del portal/SDK	Gairebé res
Agents allotjats de Foundry	Agents de marc personalitzats amb infraestructures gestionades	Només el vostre codi d’agent

Els quatre primers són càlculs de propòsit general: podeu executar-hi agents, però no estaven dissenyats per a això. Els dos últims són nadius dels agents: entenen les converses, les trucades d’eines i els cicles de vida dels agents com a conceptes de primera classe.

Foundry Hosted Agents: el lloc ideal per als desenvolupadors d’agents.NET

Aquí és el que em va cridar l’atenció. Els agents allotjats de Foundry se situen al centre: teniu la flexibilitat d’executar el vostre propi codi (nucli semàntic, marc d’agents, LangGraph, el que sigui), però la plataforma gestiona la infraestructura, l’observabilitat i la gestió de converses.

La peça clau és l’Adaptador d’allotjament: una capa d’abstracció fina que connecta el vostre marc d’agent amb la plataforma Foundry. Per a Microsoft Agent Framework, té aquest aspecte:

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()

Aquesta és tota la vostra història d’allotjament. L’adaptador gestiona la traducció del protocol, la transmissió mitjançant esdeveniments enviats pel servidor, l’historial de converses i el seguiment d’OpenTelemetry, tot automàticament. Sense programari intermedi personalitzat, sense fontaneria manual.

El desplegament és realment senzill

Abans he desplegat agents a Container Apps i funciona, però acabeu escrivint molt codi de cola per a la gestió de l’estat i l’observabilitat. Amb Hosted Agents i azd, el desplegament és:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

Aquest únic azd up crea el vostre contenidor, l’envia a ACR, subministra el projecte Foundry, desplega els punts finals del model i inicia el vostre agent. Cinc passos es van col·lapsar en una ordre.

Gestió de converses integrada

Aquesta és la peça que estalvia més temps en la producció. En lloc de crear el vostre propi magatzem d’estat de conversa, els agents allotjats ho gestionen de manera nativa:

# Create a persistent conversation
conversation = openai_client.conversations.create()

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

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No hi ha botiga de sessions de Cosmos DB. No hi ha programari intermediari personalitzat per a la serialització de missatges. La plataforma només ho gestiona.

El meu marc de decisió

Després de revisar les sis opcions, aquí teniu el meu model mental ràpid:

Necessites zero infraestructura? → Agents de Foundry (portal/SDK, sense contenidors)
Tens un codi d’agent personalitzat però vols un allotjament gestionat? → Agents allotjats de Foundry
Necessiteu tasques d’agent de curta durada i basades en esdeveniments? → Azure Functions
Necessites el màxim control dels contenidors sense K8? → Aplicacions de contenidors
Necessites un compliment estricte i múltiples clústers? → AKS
Teniu un agent HTTP senzill amb trànsit previsible? → Servei d’aplicacions

Per a la majoria de desenvolupadors de.NET que creen amb Semantic Kernel o Microsoft Agent Framework, Hosted Agents és probablement el punt de partida adequat. Obteniu una escala a zero, OpenTelemetry integrada, gestió de converses i flexibilitat de marc, sense gestionar Kubernetes ni connectar la vostra pròpia pila d’observabilitat.

Tancant

El paisatge d’allotjament d’agents a Azure està madurant ràpidament. Si inicieu un nou projecte d’agent d’IA avui, m’agradaria considerar seriosament els agents allotjats de Foundry abans d’arribar a Container Apps o AKS per costum. La infraestructura gestionada estalvia temps real i el patró de l’adaptador d’allotjament us permet mantenir la vostra elecció de marc.

Consulteu la guia completa de Microsoft i el repositori de mostres de Foundry per obtenir exemples de treball.

KubeCon Europe 2026: què haurien de preocupar-se realment als desenvolupadors.NET

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

Coneixes aquesta sensació quan cau una publicació d’anunci massiva i t’estàs desplaçant per ella pensant “genial, però què canvia això realment per a mi”? Soc jo cada temporada de la KubeCon.

Microsoft acaba de publicar el seu resum complet de KubeCon Europe 2026, escrit pel mateix Brendan Burns, i sincerament? Aquí hi ha substància real. No només inclouen les caselles de selecció, sinó també el tipus de millores operatives que canvien la manera d’executar les coses en producció.

Permeteu-me desglossar el que realment importa per als desenvolupadors de.NET.

mTLS sense l’impost de malla de servei

Això és el que passa amb les malles de servei: tothom vol les garanties de seguretat, ningú vol la sobrecàrrega operativa. AKS finalment està tancant aquesta bretxa.

Azure Kubernetes Application Network us ofereix TLS mutu, autorització conscient de l’aplicació i telemetria de trànsit, sense desplegar una malla plena de sidecars. Combinat amb Cilium mTLS a Advanced Container Networking Services, obteniu una comunicació xifrada de pod a pod mitjançant certificats X.509 i SPIRE per a la gestió d’identitats.

Què significa això a la pràctica: les vostres API ASP.NET Core parlen amb treballadors en segon pla, els vostres serveis gRPC es trucen entre ells, tot xifrat i verificat per la identitat a nivell de xarxa, sense canvis en el codi de l’aplicació. Això és enorme.

Per als equips que migren des de ingress-nginx, també hi ha Application Routing with Meshless Istio amb suport complet de l’API de Kubernetes Gateway. Sense sidecars. Basat en estàndards. I van enviar eines ingress2gateway per a la migració incremental.

Observabilitat de la GPU que no és una idea posterior

Si utilitzeu una inferència d’IA juntament amb els vostres serveis.NET (i siguem sincers, qui no comença a fer-ho?), probablement heu arribat al punt cec de supervisió de la GPU. Obtindreu grans taulers de CPU/memòria i després… res per a les GPU sense una fontaneria d’exportació manual.

AKS ara mostra les mètriques de la GPU de manera nativa a Prometheus i Grafana gestionats. Mateixa pila, mateixos taulers de comandament, mateix canal d’alertes. Sense exportadors personalitzats, ni agents de tercers.

Al costat de la xarxa, van afegir visibilitat per flux per al trànsit HTTP, gRPC i Kafka amb una experiència d’Azure Monitor amb un sol clic. IP, ports, càrregues de treball, direcció del flux, decisions polítiques, tot en taulers integrats.

I aquesta és la que m’ha fet fer una doble presa: xarxa de contenidors agent afegeix una interfície d’usuari web on podeu fer preguntes en llenguatge natural sobre l’estat de la xarxa del vostre clúster. “Per què el pod X no arriba al servei Y?” → diagnòstics de només lectura de la telemetria en directe. Això és realment útil a les 2 del matí.

Xarxes entre clústers que no requereixen un doctorat

Històricament, Kubernetes multiclúster ha estat una experiència de “porta la teva pròpia cola de xarxa”. Azure Kubernetes Fleet Manager ara s’envia xarxes entre clústers mitjançant la malla de clúster de Cilium gestionada:

Connectivitat unificada entre clústers AKS
Registre global de serveis per a la descoberta entre clústers
Configuració gestionada de manera centralitzada, no repetida per clúster

Si utilitzeu microserveis.NET en diferents regions per a la seva resiliència o compliment, això substitueix una gran quantitat de fontaneria personalitzada fràgil. El servei A a l’oest d’Europa pot descobrir i trucar al servei B a l’est dels EUA a través de la malla, amb polítiques d’encaminament i seguretat coherents.

Actualitzacions que no requereixen valentia

Siguem sincers: les actualitzacions de Kubernetes en producció són estressants. “Actualitzar i esperar” ha estat l’estratègia de facto per a massa equips, i és el principal motiu pel qual els clústers es queden endarrerits en les versions.

Dues noves capacitats canvien això:

Les actualitzacions del grup d’agents blau-verd creen un grup de nodes paral·lels amb la nova configuració. Valideu el comportament, canvieu el trànsit gradualment i manteniu un camí de retrocés net. No més mutacions in situ als nodes de producció.

La recuperació de l’agrupació d’agents us permet revertir una agrupació de nodes a la seva versió anterior de Kubernetes i a la imatge de node després d’una actualització de costat, sense haver de reconstruir el clúster.

En conjunt, finalment donen als operadors un control real sobre el cicle de vida de l’actualització. Per als equips.NET, això és important perquè la velocitat de la plataforma controla directament la rapidesa amb què podeu adoptar nous temps d’execució, pedaços de seguretat i capacitats de xarxa.

Les càrregues de treball d’IA s’estan convertint en ciutadans de primer nivell de Kubernetes

El treball de codi obert amunt és igual d’important. L’assignació dinàmica de recursos (DRA) acaba de passar a GA a Kubernetes 1.36, fent que la programació de la GPU sigui una funció adequada de primera classe en lloc d’una solució alternativa.

Alguns projectes que val la pena veure:

Projecte	Què fa
AI Runway	API comuna de Kubernetes per a la inferència: implementeu models sense conèixer els K8, amb el descobriment d’HuggingFace i les estimacions de costos
HolmesGPT	Resolució de problemes d’agent per als nadius del núvol: ara un projecte Sandbox CNCF
Dalec	La imatge de contenidor declarativa es construeix amb la generació SBOM: menys CVE en l’etapa de creació

La direcció és clara: la vostra API.NET, la vostra capa d’orquestració del nucli semàntic i les vostres càrregues de treball d’inferència s’han d’executar en un model de plataforma coherent. Hi arribem.

Per on començaria aquesta setmana

Si esteu avaluant aquests canvis per al vostre equip, aquí teniu la meva llista de prioritats honesta:

Observabilitat primer: activeu les mètriques de la GPU i els registres de flux de xarxa en un clúster que no sigui de producte. Mira què t’has perdut.
Proveu les actualitzacions blau-verd: proveu el flux de treball de retrocés abans de la propera actualització del clúster de producció. Generar confiança en el procés.
Pilota de xarxes conscients de la identitat: trieu una ruta de servei interna i activeu mTLS amb Cilium. Mesureu la sobrecàrrega (spoiler: és mínim).
Avalueu el gestor de flotes: si executeu més de dos clústers, la xarxa entre clústers es compensa amb una cola personalitzada reduïda.

Petits experiments, feedback ràpid. Aquest és sempre el moviment.

Tancant

Els anuncis de KubeCon poden ser aclaparadors, però aquest lot realment mou l’agulla dels equips.NET a AKS. Millor seguretat de xarxes sense sobrecàrrega de malla, observabilitat real de la GPU, actualitzacions més segures i bases d’infraestructura d’IA més sòlides.

Si ja esteu a AKS, aquest és un bon moment per endurir la vostra línia de base operativa. I si teniu previst traslladar les càrregues de treball.NET a Kubernetes, la plataforma s’acaba de preparar molt més per a la producció.