Cloud-Native | The .NET Blog

azd-Hooks in Python, TypeScript und .NET: Schluss mit Shell-Skripten

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Wer schon einmal ein vollständig in .NET geschriebenes Projekt hatte und trotzdem Bash-Skripte für azd-Hooks schreiben musste, kennt den Schmerz. Warum in Shell-Syntax wechseln für einen Pre-Provisioning-Schritt, wenn der Rest des Projekts C# ist?

Diese Frustration hat jetzt eine offizielle Lösung. Die Azure Developer CLI hat Multi-Sprachen-Unterstützung für Hooks eingeführt, und es ist genauso gut wie es klingt.

Was sind Hooks?

Hooks sind Skripte, die an wichtigen Punkten im azd-Lebenszyklus ausgeführt werden — vor dem Provisioning, nach dem Deployment und mehr. Sie werden in azure.yaml definiert und ermöglichen die Injektion von benutzerdefinierter Logik ohne Änderungen an der CLI.

Bisher wurden nur Bash und PowerShell unterstützt. Jetzt kann man Python, JavaScript, TypeScript oder .NET verwenden — und azd erledigt den Rest automatisch.

Wie die Erkennung funktioniert

Man verweist den Hook auf eine Datei, und azd leitet die Sprache aus der Dateiendung ab:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Keine zusätzliche Konfiguration. Bei mehrdeutigen Endungen kann man kind: python (oder die entsprechende Sprache) explizit angeben.

Sprachspezifische Details

Python

Eine requirements.txt oder pyproject.toml neben dem Skript ablegen (oder in einem übergeordneten Verzeichnis). azd erstellt automatisch eine virtuelle Umgebung, installiert Abhängigkeiten und führt das Skript aus.

JavaScript und TypeScript

Dasselbe Muster — eine package.json in der Nähe des Skripts, und azd führt zuerst npm install aus. Für TypeScript wird npx tsx verwendet, ohne Kompilierungsschritt und ohne tsconfig.json.

.NET

Zwei Modi verfügbar:

Projektmodus: Liegt eine .csproj neben dem Skript, führt azd automatisch dotnet restore und dotnet build aus.
Single-File-Modus: Ab .NET 10+ können eigenständige .cs-Dateien direkt via dotnet run script.cs ausgeführt werden. Kein Projektdatei erforderlich.

Executor-spezifische Konfiguration

Jede Sprache unterstützt einen optionalen config-Block:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Warum das für .NET-Entwickler wichtig ist

Hooks waren der letzte Ort in einem azd-basierten Projekt, der einen Sprachwechsel erzwang. Jetzt kann die gesamte Deployment-Pipeline — App-Code, Infrastrukturskripte und Lifecycle-Hooks — in einer einzigen Sprache leben. Bestehende .NET-Utilities lassen sich in Hooks wiederverwenden, gemeinsame Bibliotheken referenzieren, und Shell-Skript-Pflege entfällt.

Fazit

Einer dieser Änderungen, die klein klingen, aber täglich Reibung aus dem azd-Workflow nehmen. Multi-Sprachen-Hook-Unterstützung ist jetzt verfügbar — alle Details im offiziellen Post.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 findet am 18. April 2026 im Kinépolis Diversia in Alcobendas, Madrid statt. Es ist das größte Community-Azure-Event in Spanien, mit 38 Speakern auf 3 parallelen Tracks zu KI-Agenten, Azure-Netzwerken, Cosmos DB, Fabric, IoT, Sicherheit und vielem mehr.

Das Event läuft von 08:30 bis 18:30 und beinhaltet Keynote, Kaffeepausen, Mittagessen und eine Abschluss-Q&A-Session.

Highlights der Agenda

Domando Agentes de IA: Governance, Tools und APIs mit Azure AI Foundry und Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: Multi-Agenten-Systeme in Aktion
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Die Anmeldung erfolgt als symbolische Spende — der gesamte Ticketpreis geht direkt an Plan International für Kinderrechte und Gleichstellung weltweit. Begrenzte Kapazität, also sicher dir rechtzeitig einen Platz.

Azure Tour 2026

Neben Madrid umfasst die Global Azure Tour 2026 auch Stationen in Zaragoza, Teneriffa und Sevilla.

Aspire 13.2 bringt MongoDB EF Core und Azure Data Lake — Zwei Integrationen, die einen Blick wert sind

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Aspire 13.2 ist gerade erschienen mit zwei neuen Datenbank-Integrationen, die eure Aufmerksamkeit verdienen: MongoDB Entity Framework Core und Azure Data Lake Storage. Wenn ihr EF Core mit MongoDB in einer Aspire-App nutzen wolltet, oder Data-Lake-Workloads mit ordentlichem Service Discovery anbinden müsst, liefert dieses Release beides.

MongoDB trifft EF Core in Aspire

Das ist die Integration, auf die ich mich am meisten freue. Aspire hat MongoDB schon länger unterstützt, aber es war immer der rohe Treiber — kein EF Core, kein DbContext, keine LINQ-Abfragen gegen eure Dokumente. Jetzt bekommt ihr die volle EF-Core-Erfahrung mit MongoDB, plus Aspires automatische Health Checks und Service Discovery.

Die Einrichtung folgt dem typischen Aspire-Muster. Im AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Dann fügt ihr in eurem konsumierenden Projekt die EF Core Integration hinzu:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Und registriert euren DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Ab da ist es Standard-EF-Core. Definiert eure Entities, nutzt euren DbContext wie mit jedem anderen Provider. Die Integration übernimmt Connection Pooling, OpenTelemetry-Traces und Health Checks im Hintergrund.

Für .NET-Entwickler, die MongoDB mit dem rohen Treiber genutzt und Connection Strings manuell verdrahtet haben, ist das ein schönes Upgrade. Ihr bekommt die volle EF-Core-Abstraktion, ohne Aspires Service Discovery zu verlieren.

Azure Data Lake Storage ist mit dabei

Die zweite große Neuerung ist eine Azure Data Lake Storage (ADLS) Integration. Wenn ihr Datenpipelines, ETL-Prozesse oder Analyseplattformen baut, könnt ihr Data-Lake-Ressourcen jetzt genauso anbinden wie jede andere Aspire-Abhängigkeit.

Im AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Im konsumierenden Projekt:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Keine manuelle Connection-String-Verwaltung, keine Credential-Suche. Aspire provisioniert Ressourcen und injiziert sie. Für diejenigen von uns, die cloud-native .NET-Apps bauen, die sowohl operative Daten als auch Analyse-Workloads berühren, fühlt sich der Data Lake damit wie ein erstklassiger Bürger im Aspire-Modell an.

Die kleinen Verbesserungen, die zählen

Neben den Hauptfeatures gibt es ein paar Verbesserungen, die erwähnenswert sind:

MongoDB Connection String Fix — der Schrägstrich vor dem Datenbanknamen wird jetzt korrekt behandelt. Falls ihr einen Workaround dafür hattet, könnt ihr ihn entfernen
SQL Server Exports — Aspire.Hosting.SqlServer exportiert jetzt zusätzliche Serverkonfigurationsoptionen für feingranulare Kontrolle
Emulator-Updates — ServiceBus Emulator 2.0.0, App Configuration Emulator 1.0.2, und der Preview-Emulator von CosmosDB enthält jetzt einen Readiness Check
Azure Managed Redis — nutzt jetzt standardmäßig rediss:// (Redis Secure), sodass Verbindungen von Haus aus verschlüsselt sind

Der letzte Punkt ist subtil, aber wichtig — verschlüsseltes Redis als Standard bedeutet eine Sache weniger, die man in Produktion konfigurieren muss.

Fazit

Aspire 13.2 ist ein inkrementelles Release, aber die MongoDB EF Core und Data Lake Integrationen füllen echte Lücken. Wenn ihr auf ordentlichen EF-Core-Support mit MongoDB in Aspire gewartet habt, oder Data Lake als erstklassige Abhängigkeit braucht, upgradet auf 13.2 und probiert es aus. Der aspire add Befehl erstellt alles, was ihr braucht.

Lest die vollständigen Release Notes für mehr Details und schaut euch die Integrationsgalerie für die komplette Liste an.

Azure Smart Tier ist GA — Automatische Kostenoptimierung für Blob Storage ohne Lifecycle-Regeln

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du jemals Zeit damit verbracht hast, Azure Blob Storage Lifecycle-Richtlinien zu optimieren und dann zugesehen hast, wie sie auseinanderfallen, sobald sich die Zugriffsmuster geändert haben, ist das hier für dich. Microsoft hat gerade die allgemeine Verfügbarkeit von Smart Tier für Azure Blob und Data Lake Storage angekündigt — eine vollständig verwaltete Tiering-Funktion, die Objekte automatisch zwischen Hot-, Cool- und Cold-Tiers basierend auf der tatsächlichen Nutzung verschiebt.

Was Smart Tier tatsächlich macht

Das Konzept ist einfach: Smart Tier wertet kontinuierlich die letzte Zugriffszeit jedes Objekts in deinem Speicherkonto aus. Häufig abgerufene Daten bleiben in Hot, inaktive Daten werden nach 30 Tagen nach Cool verschoben und nach weiteren 60 Tagen nach Cold. Wenn auf die Daten erneut zugegriffen wird, werden sie sofort wieder auf Hot hochgestuft. Der Zyklus beginnt von vorne.

Keine Lifecycle-Regeln zu konfigurieren. Keine Vorhersagen von Zugriffsmustern. Kein manuelles Tuning.

Während der Preview berichtete Microsoft, dass über 50% der von Smart Tier verwalteten Kapazität automatisch in kühlere Tiers verschoben wurde — basierend auf tatsächlichen Zugriffsmustern. Das ist eine deutliche Kostenreduzierung für große Speicherkonten.

Warum das für .NET-Entwickler wichtig ist

Wenn du Anwendungen baust, die Logs, Telemetrie, Analysedaten oder irgendeine Art von wachsendem Datenbestand erzeugen — und mal ehrlich, wer tut das nicht? — summieren sich die Speicherkosten schnell. Der traditionelle Ansatz war, Lifecycle-Management-Richtlinien zu schreiben, sie zu testen und dann neu anzupassen, wenn sich die Zugriffsmuster deiner App geändert haben. Smart Tier eliminiert diesen gesamten Workflow.

Einige praktische Szenarien, in denen das hilft:

Anwendungstelemetrie und Logs — Hot beim Debuggen, nach ein paar Wochen kaum noch abgerufen
Datenpipelines und ETL-Ausgaben — während der Verarbeitung stark genutzt, danach meistens Cold
Benutzergenerierte Inhalte — aktuelle Uploads sind Hot, ältere Inhalte kühlen allmählich ab
Backup- und Archivdaten — gelegentlich für Compliance abgerufen, meistens inaktiv

Einrichtung

Smart Tier zu aktivieren ist eine einmalige Konfiguration:

Neue Konten: Wähle Smart Tier als Standard-Zugangstier während der Erstellung des Speicherkontos (zonale Redundanz erforderlich)
Bestehende Konten: Wechsle den Blob-Zugangstier von deiner aktuellen Standardeinstellung zu Smart Tier

Objekte kleiner als 128 KiB bleiben in Hot und verursachen keine Überwachungsgebühr. Für alles andere zahlst du die Standard-Kapazitätstarife für Hot/Cool/Cold — ohne Tier-Übergangsgebühren, ohne Gebühren für vorzeitige Löschung und ohne Datenabrufkosten. Eine monatliche Überwachungsgebühr pro Objekt deckt die Orchestrierung ab.

Der Kompromiss, den du kennen solltest

Die Tiering-Regeln von Smart Tier sind statisch (30 Tage → Cool, 90 Tage → Cold). Wenn du benutzerdefinierte Schwellenwerte brauchst — zum Beispiel nach 7 Tagen für eine bestimmte Workload nach Cool verschieben — sind Lifecycle-Regeln weiterhin der richtige Weg. Und mische nicht beides: Vermeide es, Lifecycle-Regeln auf von Smart Tier verwaltete Objekte anzuwenden, da sie in Konflikt geraten können.

Fazit

Das ist nicht revolutionär, aber es löst ein echtes operatives Problem. Wenn du wachsende Blob-Storage-Konten verwaltest und es leid bist, Lifecycle-Richtlinien zu pflegen, aktiviere Smart Tier und lass Azure sich darum kümmern. Es ist heute in fast allen zonalen Public-Cloud-Regionen verfügbar.

Wo solltest du deine KI-Agenten auf Azure hosten? Ein praktischer Entscheidungsleitfaden

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du gerade KI-Agenten mit .NET baust, hast du wahrscheinlich etwas bemerkt: Es gibt viele Möglichkeiten, sie auf Azure zu hosten. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — und alle klingen vernünftig, bis du tatsächlich einen auswählen musst. Microsoft hat gerade einen umfassenden Leitfaden zum Azure KI-Agenten-Hosting veröffentlicht, der das klärt, und ich möchte ihn aus der praktischen Perspektive eines .NET-Entwicklers aufschlüsseln.

Die sechs Optionen auf einen Blick

So würde ich die Landschaft zusammenfassen:

Option	Am besten für	Du verwaltest
Container Apps	Volle Container-Kontrolle ohne K8s-Komplexität	Observability, State, Lifecycle
AKS	Enterprise-Compliance, Multi-Cluster, Custom Networking	Alles (das ist der Punkt)
Azure Functions	Event-getriebene, kurzlebige Agenten-Tasks	Kaum etwas — echtes Serverless
App Service	Einfache HTTP-Agenten, vorhersehbarer Traffic	Deployment, Scaling-Config
Foundry Agents	Code-optionale Agenten über Portal/SDK	Fast nichts
Foundry Hosted Agents	Custom-Framework-Agenten mit verwalteter Infra	Nur dein Agenten-Code

Die ersten vier sind General-Purpose Compute — du kannst Agenten darauf ausführen, aber sie wurden nicht dafür entwickelt. Die letzten zwei sind agenten-nativ: Sie verstehen Konversationen, Tool-Aufrufe und Agenten-Lifecycles als First-Class-Konzepte.

Foundry Hosted Agents — der Sweet Spot für .NET-Agenten-Entwickler

Das hat meine Aufmerksamkeit geweckt. Foundry Hosted Agents sitzen genau in der Mitte: Du bekommst die Flexibilität, deinen eigenen Code auszuführen (Semantic Kernel, Agent Framework, LangGraph — was auch immer), aber die Plattform kümmert sich um Infrastruktur, Observability und Konversationsmanagement.

Das Schlüsselstück ist der Hosting Adapter — eine dünne Abstraktionsschicht, die dein Agenten-Framework mit der Foundry-Plattform verbindet. Für Microsoft Agent Framework sieht das so aus:

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

Das ist deine gesamte Hosting-Geschichte. Der Adapter übernimmt Protokollübersetzung, Streaming über Server-Sent Events, Konversationsverlauf und OpenTelemetry-Tracing — alles automatisch. Keine Custom Middleware, kein manuelles Plumbing.

Deployment ist wirklich einfach

Ich habe vorher Agenten auf Container Apps deployed und es funktioniert, aber man schreibt am Ende viel Glue-Code für State Management und Observability. Mit Hosted Agents und azd sieht das Deployment so aus:

# KI-Agenten-Extension installieren
azd ext install azure.ai.agents

# Von einer Vorlage initialisieren
azd ai agent init

# Bauen, pushen, deployen — fertig
azd up

Dieses einzelne azd up baut deinen Container, pusht ihn zu ACR, provisioniert das Foundry-Projekt, deployed Model-Endpoints und startet deinen Agenten. Fünf Schritte in einem Befehl zusammengefasst.

Integriertes Konversationsmanagement

Das ist der Teil, der in der Produktion am meisten Zeit spart. Anstatt deinen eigenen Konversations-State-Store zu bauen, handhaben Hosted Agents das nativ:

# Eine persistente Konversation erstellen
conversation = openai_client.conversations.create()

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

# Zweite Runde — Kontext bleibt erhalten
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Kein Redis. Kein Cosmos DB Session Store. Keine Custom Middleware für Nachrichtenserialisierung. Die Plattform kümmert sich einfach darum.

Mein Entscheidungsframework

Nachdem ich alle sechs Optionen durchgegangen bin, hier mein schnelles mentales Modell:

Brauchst du null Infrastruktur? → Foundry Agents (Portal/SDK, keine Container)
Hast du Custom-Agenten-Code, willst aber verwaltetes Hosting? → Foundry Hosted Agents
Brauchst du event-getriebene, kurzlebige Agenten-Tasks? → Azure Functions
Brauchst du maximale Container-Kontrolle ohne K8s? → Container Apps
Brauchst du strikte Compliance und Multi-Cluster? → AKS
Hast du einen einfachen HTTP-Agenten mit vorhersehbarem Traffic? → App Service

Für die meisten .NET-Entwickler, die mit Semantic Kernel oder Microsoft Agent Framework bauen, sind Hosted Agents wahrscheinlich der richtige Startpunkt. Du bekommst Scale-to-Zero, integriertes OpenTelemetry, Konversationsmanagement und Framework-Flexibilität — ohne Kubernetes zu verwalten oder deinen eigenen Observability-Stack aufzubauen.

Zum Abschluss

Die Agenten-Hosting-Landschaft auf Azure reift schnell. Wenn du heute ein neues KI-Agenten-Projekt startest, würde ich Foundry Hosted Agents ernsthaft in Betracht ziehen, bevor du aus Gewohnheit zu Container Apps oder AKS greifst. Die verwaltete Infrastruktur spart echte Zeit, und das Hosting-Adapter-Pattern lässt dich deine Framework-Wahl behalten.

Schau dir den vollständigen Leitfaden von Microsoft und das Foundry Samples Repo für funktionierende Beispiele an.

KubeCon Europe 2026: Was .NET-Entwickler wirklich wissen sollten

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kennst du das Gefühl, wenn ein riesiger Ankündigungs-Post erscheint und du durchscrollst und denkst: „Cool, aber was ändert das jetzt tatsächlich für mich"? So geht es mir jede KubeCon-Saison.

Microsoft hat gerade ihren vollständigen KubeCon Europe 2026 Überblick veröffentlicht — geschrieben von Brendan Burns persönlich — und ehrlich gesagt steckt hier echte Substanz drin. Nicht nur Feature-Checklisten, sondern operative Verbesserungen, die ändern, wie du Dinge in Produktion betreibst.

Lass mich aufschlüsseln, was für uns .NET-Entwickler wirklich zählt.

mTLS ohne die Service-Mesh-Steuer

Hier ist die Sache mit Service Meshes: Jeder will die Sicherheitsgarantien, niemand will den operativen Overhead. AKS schließt diese Lücke endlich.

Azure Kubernetes Application Network gibt dir Mutual TLS, anwendungsbewusste Autorisierung und Traffic-Telemetrie — ohne ein volles Sidecar-lastiges Mesh zu deployen. In Kombination mit Cilium mTLS in Advanced Container Networking Services bekommst du verschlüsselte Pod-zu-Pod-Kommunikation mit X.509-Zertifikaten und SPIRE für Identity Management.

Was das in der Praxis bedeutet: Deine ASP.NET Core APIs, die mit Background-Workern kommunizieren, deine gRPC-Services, die sich gegenseitig aufrufen — alles verschlüsselt und identitätsverifiziert auf Netzwerkebene, ohne eine einzige Code-Änderung. Das ist gewaltig.

Für Teams, die von ingress-nginx migrieren, gibt es außerdem Application Routing mit Meshless Istio mit vollem Kubernetes Gateway API Support. Keine Sidecars. Standardbasiert. Und sie haben ingress2gateway-Tools für inkrementelle Migration mitgeliefert.

GPU-Observability, die kein Nachgedanke ist

Wenn du KI-Inferenz neben deinen .NET-Services ausführst (und seien wir ehrlich, wer fängt nicht langsam damit an?), bist du wahrscheinlich auf den GPU-Monitoring-Blindspot gestoßen. Du hattest großartige CPU/Memory-Dashboards und dann… nichts für GPUs ohne manuelle Exporter-Konfiguration.

AKS zeigt GPU-Metriken jetzt nativ in Managed Prometheus und Grafana an. Gleicher Stack, gleiche Dashboards, gleiche Alerting-Pipeline. Keine Custom-Exporter, keine Third-Party-Agents.

Auf der Netzwerkseite wurde Per-Flow-Visibilität für HTTP-, gRPC- und Kafka-Traffic mit einer One-Click Azure Monitor-Erfahrung hinzugefügt. IPs, Ports, Workloads, Flow-Richtung, Policy-Entscheidungen — alles in eingebauten Dashboards.

Und hier kommt die, bei der ich zweimal hingeschaut habe: Agentic Container Networking fügt eine Web-UI hinzu, in der du natürlichsprachliche Fragen zum Netzwerkzustand deines Clusters stellen kannst. „Warum erreicht Pod X Service Y nicht?" → Read-Only-Diagnose aus Live-Telemetrie. Das ist um 2 Uhr nachts wirklich nützlich.

Cross-Cluster-Networking ohne Doktortitel

Multi-Cluster Kubernetes war historisch eine „Bring deinen eigenen Netzwerk-Kleber mit"-Erfahrung. Azure Kubernetes Fleet Manager liefert jetzt Cross-Cluster-Networking über Managed Cilium Cluster Mesh:

Einheitliche Konnektivität über AKS-Cluster hinweg
Globale Service-Registry für Cross-Cluster-Discovery
Zentral verwaltete Konfiguration statt pro Cluster wiederholt

Wenn du .NET-Microservices über Regionen hinweg für Resilienz oder Compliance betreibst, ersetzt das eine Menge fragilen Custom-Kleber. Service A in West Europe kann Service B in East US über das Mesh entdecken und aufrufen, mit konsistenten Routing- und Sicherheitsrichtlinien.

Upgrades, die keinen Mut erfordern

Seien wir ehrlich — Kubernetes-Upgrades in Produktion sind stressig. „Upgraden und hoffen" war die De-facto-Strategie für zu viele Teams und der Hauptgrund, warum Cluster bei Versionen hinterherhinken.

Zwei neue Fähigkeiten ändern das:

Blue-Green Agent Pool Upgrades erstellen einen parallelen Node-Pool mit der neuen Konfiguration. Verhalten validieren, Traffic schrittweise verlagern und einen sauberen Rollback-Pfad behalten. Keine In-Place-Mutationen auf Produktions-Nodes mehr.

Agent Pool Rollback ermöglicht es, einen Node-Pool auf seine vorherige Kubernetes-Version und Node-Image zurückzusetzen, wenn ein Upgrade schiefgeht — ohne den Cluster neu aufzubauen.

Zusammen geben sie Operatoren endlich echte Kontrolle über den Upgrade-Lebenszyklus. Für .NET-Teams ist das wichtig, weil Plattform-Geschwindigkeit direkt steuert, wie schnell du neue Runtimes, Sicherheitspatches und Netzwerk-Fähigkeiten einsetzen kannst.

KI-Workloads werden zu First-Class Kubernetes-Bürgern

Die Upstream-Open-Source-Arbeit ist gleichermaßen wichtig. Dynamic Resource Allocation (DRA) ist gerade in Kubernetes 1.36 GA geworden und macht GPU-Scheduling zu einem echten First-Class-Feature statt eines Workarounds.

Einige Projekte, die es wert sind beobachtet zu werden:

Projekt	Was es macht
AI Runway	Gemeinsame Kubernetes-API für Inferenz — Models deployen ohne K8s-Kenntnisse, mit HuggingFace-Discovery und Kostenschätzungen
HolmesGPT	Agentisches Troubleshooting für Cloud-Native — jetzt ein CNCF-Sandbox-Projekt
Dalec	Deklarative Container-Image-Builds mit SBOM-Generierung — weniger CVEs in der Build-Phase

Die Richtung ist klar: Deine .NET-API, deine Semantic-Kernel-Orchestrierungsschicht und deine Inferenz-Workloads sollten alle auf einem konsistenten Plattformmodell laufen. Wir kommen dahin.

Wo ich diese Woche anfangen würde

Wenn du diese Änderungen für dein Team evaluierst, hier meine ehrliche Prioritätenliste:

Observability zuerst — GPU-Metriken und Netzwerk-Flow-Logs in einem Nicht-Prod-Cluster aktivieren. Schau dir an, was du verpasst hast.
Blue-Green-Upgrades testen — den Rollback-Workflow vor deinem nächsten Produktions-Cluster-Upgrade ausprobieren. Vertrauen in den Prozess aufbauen.
Identity-Aware Networking pilotieren — einen internen Service-Pfad wählen und mTLS mit Cilium aktivieren. Den Overhead messen (Spoiler: er ist minimal).
Fleet Manager evaluieren — wenn du mehr als zwei Cluster betreibst, zahlt sich Cross-Cluster-Networking durch weniger Custom-Kleber von selbst.

Kleine Experimente, schnelles Feedback. Das ist immer der richtige Zug.

Zum Schluss

KubeCon-Ankündigungen können überwältigend sein, aber diese Runde bewegt wirklich etwas für .NET-Teams auf AKS. Bessere Netzwerksicherheit ohne Mesh-Overhead, echte GPU-Observability, sicherere Upgrades und stärkere KI-Infrastruktur-Grundlagen.

Wenn du bereits auf AKS bist, ist jetzt ein großartiger Moment, deine operative Baseline zu verbessern. Und wenn du planst, .NET-Workloads auf Kubernetes zu verlagern — die Plattform ist gerade deutlich produktionsreifer geworden.