Der Azure Kubernetes Service (AKS) ist Microsofts verwalteter Kubernetes-Dienst auf Azure, der Container-Orchestrierung für Unternehmensanwendungen deutlich vereinfacht. Statt Kubernetes-Infrastruktur selbst aufzubauen und zu warten, übernimmt AKS die Verwaltung der Control Plane vollständig – du konzentrierst dich auf deine Anwendungen, nicht auf den Betrieb des Clusters. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um AKS-Architektur, Skalierung, Sicherheit und Kosten.
Wie unterscheidet sich AKS von selbst verwaltetem Kubernetes?
Der entscheidende Unterschied liegt in der Verantwortungsaufteilung: Bei AKS übernimmt Microsoft die Verwaltung der Kubernetes-Control-Plane – also API-Server, etcd-Datenbank und Scheduler – vollständig und kostenlos. Bei selbst verwaltetem Kubernetes trägst du die alleinige Verantwortung für Betrieb, Updates und Hochverfügbarkeit dieser Komponenten.
In der Praxis bedeutet das konkret: Wer Kubernetes selbst betreibt, muss ein Team vorhalten, das Cluster-Upgrades plant, Sicherheits-Patches einspielt, Ausfälle der Control Plane behebt und die Infrastruktur skaliert. Dieser operative Aufwand ist erheblich und bindet Ressourcen, die in vielen Unternehmen fehlen.
AKS reduziert diesen Aufwand strukturell:
- Automatische Control-Plane-Updates: Microsoft aktualisiert API-Server und Systemkomponenten im Hintergrund
- Integriertes Monitoring: Azure Monitor und Container Insights sind direkt angebunden
- Native Azure-Integration: Entra ID, Azure Networking, Azure Container Registry und Azure Policy lassen sich ohne zusätzliche Konfigurationsarbeit nutzen
- SLA-gesicherter Betrieb: Microsoft garantiert die Verfügbarkeit der Control Plane per Service Level Agreement
Selbst verwaltetes Kubernetes bleibt sinnvoll, wenn maximale Kontrolle über jede Konfigurationsebene erforderlich ist oder spezifische Compliance-Anforderungen den Einsatz einer Public Cloud ausschließen. Für die meisten Unternehmensanwendungen bietet AKS jedoch das bessere Verhältnis aus Flexibilität und Betriebsaufwand.
Welche Kernkomponenten bilden einen AKS-Cluster?
Ein AKS-Cluster besteht aus zwei grundlegenden Ebenen: der von Microsoft verwalteten Control Plane und den durch das Unternehmen betriebenen Worker Nodes. Diese Trennung ist das architektonische Fundament, auf dem alle weiteren Komponenten aufbauen.
Control Plane und Node Pools
Die Control Plane umfasst den Kubernetes-API-Server als zentrale Schnittstelle, den Scheduler für die Zuweisung von Workloads auf Nodes sowie den Controller Manager, der den gewünschten Cluster-Zustand kontinuierlich sicherstellt. etcd dient als verteilter Schlüssel-Wert-Speicher für alle Cluster-Daten. Diese Komponenten sind in AKS vollständig abstrahiert.
Die Worker Nodes laufen als Azure Virtual Machines in sogenannten Node Pools. Ein System Node Pool übernimmt interne Kubernetes-Dienste, während User Node Pools die eigentlichen Anwendungs-Workloads aufnehmen. Diese Trennung ermöglicht unterschiedliche VM-Typen je nach Anforderung – etwa GPU-optimierte Nodes für KI-Workloads oder speicherskalierte Nodes für Datenbankcontainer.
Netzwerk und Storage
Das Kubernetes-Netzwerk in AKS basiert auf Azure CNI oder dem kubenet-Plugin und integriert sich direkt in Azure Virtual Networks. Services werden über Azure Load Balancer oder Application Gateway exponiert. Für persistente Daten stehen Azure Disks und Azure Files als Storage-Klassen zur Verfügung, die sich per Persistent Volume Claims in Pods einbinden lassen. Eine strukturierte Netzwerkarchitektur ist dabei entscheidend – ähnlich wie beim Aufbau einer Azure Landing Zone, die Netzwerksegmentierung, VPN-Anbindungen und Zugriffskontrolle von Anfang an berücksichtigt.
Wie skaliert AKS automatisch bei schwankender Last?
AKS bietet drei Skalierungsmechanismen, die unabhängig voneinander oder kombiniert eingesetzt werden können: den Horizontal Pod Autoscaler für die Anwendungsebene, den Cluster Autoscaler für die Node-Ebene und KEDA für ereignisgesteuerte Skalierung. Zusammen decken sie nahezu alle Lastmuster moderner Unternehmensanwendungen ab.
Der Horizontal Pod Autoscaler (HPA) beobachtet CPU- und Speicherauslastung von Pods und skaliert die Anzahl der Replikate automatisch hoch oder herunter. Wenn eine Webanwendung unter Last steht, erhöht der HPA die Pod-Anzahl innerhalb von Sekunden – ohne manuellen Eingriff.
Der Cluster Autoscaler agiert eine Ebene tiefer: Wenn neue Pods nicht auf bestehende Nodes passen, fordert er automatisch weitere Azure-VMs an. Sinkt die Last, gibt er nicht benötigte Nodes wieder frei und reduziert damit die laufenden Kosten. Dieser Mechanismus arbeitet eng mit Azure-Skalierungssets zusammen.
KEDA (Kubernetes Event-Driven Autoscaling) erweitert die Skalierung um ereignisbasierte Trigger – etwa Nachrichten in einer Azure Service Bus Queue oder HTTP-Anfragen an ein Azure API Gateway. Damit lassen sich Microservices auf null Pods herunterskalieren, wenn kein Traffic anliegt, und bei Bedarf innerhalb von Sekunden hochfahren.
Wie wird Sicherheit und Zugriffskontrolle in AKS umgesetzt?
Sicherheit in AKS wird auf mehreren Schichten umgesetzt: Identität und Zugriff über Microsoft Entra ID, Netzwerksicherheit über Policies und Firewalls sowie Workload-Sicherheit über Pod-Identitäten und Secrets Management. Entscheidend ist, dass diese Schichten von Beginn an in die Architektur integriert werden – nicht nachträglich ergänzt.
Die wichtigsten Sicherheitsmechanismen im Überblick:
- Entra ID Integration: Nutzer*innen und Dienstkonten authentifizieren sich über Microsoft Entra ID; Kubernetes RBAC und Azure RBAC greifen ineinander
- Workload Identity: Pods erhalten Managed Identities, um auf Azure-Ressourcen wie Key Vault oder Storage zuzugreifen – ohne hartcodierte Credentials
- Network Policies: Kubernetes Network Policies oder Azure Network Policies steuern, welche Pods miteinander kommunizieren dürfen
- Azure Policy für AKS: Governance-Regeln erzwingen automatisch Sicherheitsstandards, etwa das Verbot privilegierter Container
- Microsoft Defender for Containers: Erkennt Bedrohungen auf Cluster- und Node-Ebene in Echtzeit
- Secrets in Azure Key Vault: Sensible Konfigurationsdaten werden nicht im Cluster gespeichert, sondern sicher aus Key Vault geladen
Für Unternehmen mit erhöhten Compliance-Anforderungen empfiehlt sich ein privater AKS-Cluster, bei dem der API-Server nicht öffentlich erreichbar ist. Die Verbindung erfolgt dann ausschließlich über private Netzwerkverbindungen innerhalb der Azure-Infrastruktur.
Welche Kosten entstehen beim Betrieb von AKS in der Praxis?
Die Control Plane von AKS ist kostenlos – du bezahlst ausschließlich für die genutzten Azure-Ressourcen: Virtual Machines für die Worker Nodes, Storage, Netzwerk-Traffic und optionale Zusatzdienste. Die tatsächlichen Kosten hängen stark von der Cluster-Größe, den VM-Typen und dem Nutzungsmuster ab.
Die größten Kostentreiber in der Praxis sind:
- Worker Nodes: VM-Kosten machen den größten Anteil aus; die Wahl zwischen Standard-VMs und Spot Instances kann die Kosten erheblich beeinflussen
- Persistent Storage: Azure Managed Disks und Azure Files werden nach Kapazität abgerechnet
- Load Balancer und Netzwerk-Traffic: Ausgehender Datenverkehr und Load-Balancer-Stunden fallen separat an
- Monitoring und Logging: Azure Monitor und Log Analytics Workspaces erzeugen eigene Kosten je nach Datenvolumen
Effektives Kostenmanagement beginnt mit der richtigen Node-Pool-Strategie: Spot Instances für unterbrechbare Workloads reduzieren die VM-Kosten erheblich. Der Cluster Autoscaler sorgt dafür, dass nicht benötigte Nodes abgebaut werden. Ähnlich wie bei der Azure Data Platform gilt auch für AKS: Ohne strukturiertes Kostenmanagement entstehen schnell unnötige Ausgaben durch überdimensionierte oder dauerhaft laufende Ressourcen.
Wann ist AKS die richtige Wahl für Unternehmensanwendungen?
AKS ist die richtige Wahl, wenn Unternehmensanwendungen containerbasiert sind oder containerisiert werden sollen, mehrere Microservices koordiniert betrieben werden müssen und die Organisation von automatischer Skalierung, integrierter Sicherheit und Azure-nativer Governance profitieren will. Für monolithische Anwendungen ohne Containerisierungsstrategie ist AKS hingegen nicht der geeignete Einstiegspunkt.
AKS eignet sich besonders gut für folgende Szenarien:
- Microservices-Architekturen: Wenn verschiedene Anwendungskomponenten unabhängig voneinander skaliert, aktualisiert und deployt werden sollen
- Hybride Workloads: Wenn Anwendungen sowohl on-premises als auch in der Cloud laufen und konsistente Deployment-Prozesse gefragt sind
- KI- und ML-Workloads: AKS lässt sich direkt mit Azure OpenAI und Azure Machine Learning verbinden und ermöglicht GPU-optimierte Node Pools für Inferenz-Workloads
- Regulierte Branchen: Durch Entra ID Integration, Azure Policy und private Cluster-Optionen erfüllt AKS auch strenge Compliance-Anforderungen
- Schnell wachsende Anwendungen: Wenn Lastspitzen unvorhersehbar sind und manuelle Skalierung zu langsam oder zu teuer ist
Weniger geeignet ist AKS für einfache Webanwendungen ohne Skalierungsanforderungen – hier sind Azure App Service oder Azure Container Apps oft die schlankere Lösung. Die Entscheidung für AKS sollte immer mit einer klaren Architekturstrategie verbunden sein, nicht allein mit dem Wunsch, Kubernetes einzusetzen.
Wie Communardo Smart Work beim Einstieg in AKS unterstützt
AKS-Projekte scheitern selten an der Technologie selbst – häufiger an fehlender Architekturgrundlage, unklaren Governance-Strukturen oder einer Infrastruktur, die organisch gewachsen ist und keine klaren Standards kennt. Communardo Smart Work begleitet Unternehmen ab 500 Mitarbeitenden beim strukturierten Einstieg in den Azure Kubernetes Service:
- Architekturberatung und AKS-Design: Entwicklung einer Cluster-Architektur, die zu den Anforderungen der Organisation passt – von Node-Pool-Strategie bis Netzwerkdesign
- Azure Landing Zone als Fundament: Sicherstellung, dass AKS in eine strukturierte Azure-Infrastruktur eingebettet wird – mit Governance, Sicherheitsrichtlinien und Kostenkontrolle von Anfang an
- Sicherheit und Compliance: Einrichtung von Entra ID Integration, Workload Identity, Network Policies und Microsoft Defender for Containers nach Best Practices
- Kostenoptimierung: Analyse und Optimierung der Node-Pool-Konfiguration, Autoscaler-Einstellungen und Storage-Strategie
- Enablement und Betrieb: Schulung der internen Teams und Unterstützung im laufenden Betrieb, damit das Wissen in der Organisation verankert bleibt
Wenn du wissen möchtest, wie AKS konkret in deine Azure-Umgebung passt und welche Schritte als Nächstes sinnvoll sind, nimm direkt Kontakt auf – wir schauen uns die Ausgangssituation gemeinsam an.