Wer containerisierte Anwendungen zuverlässig betreiben und Releases beschleunigen möchte, landet schnell bei Azure AKS. Der verwaltete Kubernetes-Dienst nimmt einen großen Teil der Infrastrukturarbeit ab, lässt Teams aber weiterhin mit Containern, Deployments und CI/CD arbeiten. Ich zeige, wie AKS aufgebaut ist, wann Automatic oder Standard sinnvoll ist, welche Kosten entstehen und worauf es bei Sicherheit, Skalierung und Betrieb wirklich ankommt.
Die wichtigsten Fakten für eine fundierte AKS-Entscheidung
- Managed Kubernetes bedeutet, dass Azure die Steuerungsebene betreibt, während Sie die Worker-Knoten und Workloads verantworten.
- AKS Automatic eignet sich für produktive Workloads mit möglichst wenig Plattformbetrieb.
- AKS Standard bietet mehr Kontrolle über Netzwerke, Knotenpools und Clusterkonfigurationen.
- Für CI/CD verbinden Sie typischerweise Container Registry, Pipeline und Kubernetes-Manifeste.
- Die Kosten entstehen vor allem durch VMs, Speicher, Netzwerk, Monitoring und Zusatzdienste, nicht nur durch den Cluster selbst.
Was AKS beim Hosting tatsächlich übernimmt
Azure Kubernetes Service ist ein verwalteter Dienst für das Ausführen containerisierter Anwendungen. Azure betreibt die Kubernetes-Steuerungsebene, also unter anderem den API-Server und zentrale Verwaltungsfunktionen. Die Rechenleistung für Ihre Anwendungen läuft dagegen auf Worker-Knoten, die in Ihrem Azure-Abonnement bereitgestellt werden.
Das ist der entscheidende Unterschied zu einem vollständig selbst betriebenen Kubernetes-Cluster. Sie müssen die Control Plane nicht selbst patchen oder hochverfügbar auslegen, bleiben aber für Workloads, Ressourcenlimits, Images, Netzwerke und viele Sicherheitsentscheidungen verantwortlich. Kubernetes verschwindet also nicht, der administrative Aufwand verschiebt sich nur an die Stellen, an denen er für Ihr Produkt relevant ist.
Die wichtigsten Bausteine
- Cluster: Die logische Umgebung, in der Kubernetes-Ressourcen verwaltet werden.
- Node Pools: Gruppen von virtuellen Maschinen mit bestimmten Größen oder Betriebssystemen.
- Pods: Die kleinste ausführbare Einheit, in der ein oder mehrere Container laufen.
- Services: Stabile Netzwerkadressen, über die Pods intern oder extern erreichbar werden.
- Ingress: Eine HTTP- oder HTTPS-Einstiegsschicht für Webanwendungen und APIs.
- Container Registry: Ein privates Register, beispielsweise Azure Container Registry, für Images.
In der Praxis ist diese Trennung sehr hilfreich. Entwickler liefern ein neues Container-Image, während die Plattform den Betrieb der Knoten, die Verteilung der Pods und die Kommunikation zwischen den Diensten organisiert. Ich halte AKS besonders dann für stark, wenn mehrere Teams dieselbe Plattform nutzen und einheitliche Standards für Deployments und Sicherheit gebraucht werden.
AKS Automatic oder Standard passt besser
Seit 2026 bietet AKS zwei deutlich unterschiedliche Betriebsmodelle. AKS Automatic arbeitet mit produktionsfähigen Voreinstellungen für Skalierung, Sicherheit, Überwachung und Upgrades. AKS Standard gibt Plattformteams mehr direkte Kontrolle, verlangt dafür aber mehr eigene Planung und laufende Administration.
| Kriterium | AKS Automatic | AKS Standard |
|---|---|---|
| Geeignet für | Die meisten neuen Produktions-Workloads | Spezielle Infrastruktur- und Compliance-Anforderungen |
| Knotenverwaltung | Stärker durch Azure vorgegeben und verwaltet | Eigene Verwaltung von Knotenpools und Einstellungen |
| Flexibilität | Weniger Detailkontrolle, dafür schnellere Einführung | Hohe Kontrolle über Netzwerk, Pools und Lebenszyklus |
| Betriebsaufwand | Niedriger | Höher, besonders bei Upgrades und Sicherheitsrichtlinien |
| Typischer Nutzer | Produktteams und kleinere Plattformteams | Erfahrene Cloud- und Plattformteams |
Ich würde für eine neue Webanwendung zunächst Automatic prüfen. Das Modell reduziert die Zahl der Entscheidungen, die am ersten Tag getroffen werden müssen. Standard ist die bessere Wahl, wenn Sie etwa eigene Netzwerkmuster, spezialisierte GPU-Knoten, komplexe Mandantentrennung oder bestehende Automatisierung ausrollen müssen.
Mehr Kontrolle ist allerdings nicht automatisch ein Vorteil. Jede zusätzliche Einstellung wird später zu einer Betriebsaufgabe. Wer Standard wählt, sollte deshalb Verantwortlichkeiten für Patchmanagement, Upgrades, Monitoring und Notfallwiederherstellung klar benennen.
So wird aus einem Commit ein produktives Deployment
Der typische DevOps-Ablauf beginnt mit einem Commit im Quellcode-Repository. Eine Pipeline baut daraus ein Container-Image, prüft es und legt es in einer privaten Registry ab. Anschließend wird das Image über Kubernetes-Manifeste, Helm oder eine GitOps-Lösung in eine AKS-Umgebung ausgerollt.
- Code prüfen: Unit-Tests, Linting und Sicherheitsprüfungen laufen bei jedem Pull Request.
- Image bauen: Das Dockerfile erzeugt ein versioniertes Image mit unveränderlichem Tag.
- Image scannen: Bekannte Schwachstellen und unsichere Basispakete werden vor dem Deployment erkannt.
- Registry aktualisieren: Das geprüfte Image landet in Azure Container Registry oder einer gleichwertigen privaten Registry.
- Deployment ausführen: Die Pipeline aktualisiert die Kubernetes-Ressourcen in einer Test- oder Produktionsumgebung.
- Rollout beobachten: Health Checks, Metriken und Logs entscheiden, ob der Rollout fortgesetzt oder zurückgerollt wird.
Mit Azure DevOps Pipelines lässt sich dieser Prozess direkt mit AKS und einer Container Registry verbinden. Ebenso sind GitHub Actions oder eine GitOps-Plattform möglich. Entscheidend ist weniger das konkrete Werkzeug als die Trennung zwischen Build, Freigabe und Betrieb.
az aks get-credentials \
--resource-group produktiv-rg \
--name web-cluster
kubectl apply -f deployment.yamlEin häufiger Fehler ist, nur den erfolgreichen Pipeline-Lauf zu messen. Ein Image kann gebaut und technisch ausgerollt werden, obwohl die Anwendung danach keine Datenbank erreicht oder wegen fehlender Ressourcen sofort neu startet. Ich plane deshalb für produktive Systeme immer Readiness- und Liveness-Probes, definierte Rollout-Strategien und eine einfache Rückkehr zur letzten funktionierenden Version ein.
Sicherheit, Netzwerk und Überwachung gehören zusammen
Ein AKS-Cluster ist nicht sicher, nur weil die Control Plane verwaltet wird. Die Anwendung, ihre Container-Images, Geheimnisse, Identitäten und Netzwerkpfade bleiben Teil Ihrer Verantwortung. Für den Zugriff auf den Cluster sollte die Integration mit Microsoft Entra ID und rollenbasierter Zugriffskontrolle die Grundlage bilden.
Zugriff und Geheimnisse
Administratoren und Entwickler sollten nur die Rechte erhalten, die sie für ihre Aufgabe benötigen. Zugangsdaten gehören weder in Git-Repositories noch in Docker-Images. Für den Zugriff auf Azure-Ressourcen aus Pods heraus ist Microsoft Entra Workload ID meist sauberer als statische Schlüssel, weil sich Berechtigungen zentral steuern und rotieren lassen.
Netzwerk und Datenverkehr
Interne Services sollten nicht automatisch öffentlich erreichbar sein. Für externe Webanwendungen kommen je nach Architektur ein Load Balancer, ein Ingress-Controller und ein Web Application Firewall zum Einsatz. Network Policies begrenzen zusätzlich, welche Pods miteinander kommunizieren dürfen.
Bei regulierten Workloads würde ich den API-Server nicht offen ins Internet stellen, sondern den Clusterzugriff über private Netzwerke, definierte Administrationswege und zentrale Protokollierung führen. Das erhöht den Planungsaufwand, reduziert aber die Angriffsfläche deutlich.
Monitoring und Fehleranalyse
Azure Monitor und Container Insights können Clusterzustand, Knoten, Pods und Containerlogs zusammenführen. Für dauerhaft aussagekräftige Dashboards sind zusätzlich Metriken wie Fehlerrate, Antwortzeit, Speicherauslastung und Neustarts wichtig. Ein grüner Clusterstatus sagt wenig aus, wenn die eigentliche Anwendung bereits mit langen Antwortzeiten kämpft.
Ich empfehle, mindestens drei Ebenen zu überwachen: Plattform, Anwendung und Geschäftsprozess. Ein Shop braucht neben CPU-Metriken also auch Hinweise auf fehlgeschlagene Bestellungen oder eine wachsende Warteschlange.
Skalierung funktioniert nur mit guten Ressourcenangaben
AKS kann auf mehreren Ebenen skalieren. Der Horizontal Pod Autoscaler erhöht oder verringert die Zahl der Pod-Replikate anhand von Metriken. Der Cluster Autoscaler passt dagegen die Anzahl der Knoten an, wenn Pods wegen fehlender Ressourcen nicht eingeplant werden können.
Beide Mechanismen ergänzen sich. Der HPA kann beispielsweise eine Anwendung von 3 auf 12 Pods erweitern. Reichen die vorhandenen Knoten dafür nicht aus, stellt der Cluster Autoscaler zusätzliche Kapazität bereit. Für ereignisbasierte Workloads, etwa Nachrichtenverarbeitung, ist KEDA oft passender als eine reine CPU-Skalierung.
Die automatische Skalierung arbeitet aber nicht zauberhaft. Ohne realistische CPU- und Speicheranforderungen trifft Kubernetes schlechte Platzierungsentscheidungen. Werden Requests zu niedrig angesetzt, drohen Engpässe; sind sie zu hoch, bleiben Knoten teuer ungenutzt.
Lesen Sie auch: DevOps Lifecycle verstehen und CI/CD sicher einsetzen
Was AKS monatlich kostet
Im Free-Tarif wird die Steuerungsebene ohne SLA angeboten. Bezahlt werden trotzdem die zugrunde liegenden Ressourcen, insbesondere virtuelle Maschinen, Managed Disks, öffentliche IPs, Load Balancer, Container Registry, Monitoring und ausgehender Datenverkehr.
Für produktive Umgebungen mit Verfügbarkeitsanforderungen ist der Standardtarif die üblichere Wahl. Microsoft nennt für AKS Clustergrenzen von bis zu 5.000 Knoten, wobei die praktische Größe immer von Region, Netzwerk, Workload und Betriebsmodell abhängt. Die konkreten VM-Preise unterscheiden sich nach Region, Größe, Betriebssystem, Reservierung und Vertrag, deshalb sollte die Kalkulation mit dem Azure-Preisrechner erfolgen.
Mein wichtigster Spartipp ist unspektakulär, aber wirksam: Nicht nur die VM-Größe prüfen, sondern auch ungenutzte Testumgebungen, zu großzügige Requests und dauerhaft laufende Nebenkomponenten. In kleinen Projekten kann ein einfacher Dienst günstiger und leichter zu betreiben sein als ein Kubernetes-Cluster.
Wann AKS sinnvoll ist und wann ein anderer Dienst reicht
AKS spielt seine Stärke aus, wenn eine Anwendung aus mehreren Services besteht, unabhängig skalieren muss oder eine standardisierte Containerplattform für mehrere Teams gebraucht wird. Auch hybride Strategien, anspruchsvolle Netzwerkregeln und bestehende Kubernetes-Kompetenz sprechen dafür.
| Azure-Dienst | Passt gut, wenn | Grenze |
|---|---|---|
| AKS | Sie Kubernetes-Kontrolle, Skalierung und komplexe Workloads benötigen | Höherer Lern- und Betriebsaufwand |
| Azure Container Apps | Sie Container deployen möchten, ohne den Cluster selbst zu verwalten | Weniger Kontrolle über die Kubernetes-Plattform |
| App Service | Eine klassische Webanwendung oder API schnell betrieben werden soll | Weniger geeignet für komplexe Microservice-Orchestrierung |
| Azure Functions | Einzelne ereignisgesteuerte Funktionen im Mittelpunkt stehen | Nicht für jede dauerhaft laufende Anwendung geeignet |
Für eine einzelne Website mit moderatem Traffic würde ich nicht aus Prinzip Kubernetes einsetzen. Container Apps oder App Service lösen solche Aufgaben oft schneller. AKS lohnt sich dort, wo seine zusätzlichen Möglichkeiten den Mehraufwand tatsächlich rechtfertigen.
Wer von virtuellen Maschinen zu AKS migriert, sollte außerdem nicht einfach jede bestehende Serverstruktur in Container verpacken. Besser ist eine Prüfung von Zustandsdaten, Netzwerkkopplungen, Startzeiten, Hintergrundjobs und Release-Prozess. Besonders Datenbanken gehören häufig weiterhin in einen spezialisierten Managed Service und nicht in denselben Cluster.
Die richtige AKS-Entscheidung beginnt mit dem Betriebsmodell
Für die meisten Teams lautet mein pragmatischer Startpunkt AKS Automatic mit klaren CI/CD- und Sicherheitsstandards. Standard ist dann sinnvoll, wenn die zusätzliche Kontrolle einen konkreten technischen oder regulatorischen Vorteil bringt. Entscheidend ist nicht, möglichst viele Kubernetes-Funktionen zu aktivieren, sondern einen Betrieb zu schaffen, den das Team dauerhaft beherrschen kann.
Planen Sie vor dem ersten produktiven Deployment mindestens Verantwortlichkeiten für Upgrades, Kostenkontrolle, Backups, Monitoring und Notfallwiederherstellung ein. Wer diese Punkte früh klärt, bekommt mit AKS eine flexible Hosting-Plattform, die Releases beschleunigt und auch bei wachsender Anwendung nicht sofort zum Engpass wird.
