AKS-Fehler 2026: was 30 Klicks im Portal verschweigen

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting | 9 Min. Lesezeit | 10.09.2026

TL;DR: AKS Fehler kurz erklärt

Azure Kubernetes Service nimmt die Control Plane ab, nicht die Architektur. Rund 30 Portal-Klicks entscheiden Netzwerk, Zugriff und Node Pools, und mehrere davon lassen sich später nicht umstellen. Pexon Consulting betreut AKS bei Banken, Versicherern und Energieversorgern. Der wichtigste Rat: Verstehen Sie am ersten Tag, was Sie konfigurieren.

Das Problem: der Ein-Klick-Mythos

Der Satz, den wir am häufigsten hören, lautet sinngemäß: Wir haben jetzt AKS, wir können jetzt einfach mit einem Klick Kubernetes deployen.

Die Erwartung ist verständlich. Der Dienst heißt Azure Kubernetes Service, und Azure verkauft ihn als abgenommene Komplexität. In Teilen stimmt das auch: Node-Provisionierung, Control-Plane-Dimensionierung, der grundsätzliche Cluster-Aufbau, das ist alles hinterlegt.

Nur ist der Weg vom leeren Portal zum brauchbaren Cluster eben nicht ein Klick, sondern eher dreißig. Hinter mehreren dieser Klicks stehen Entscheidungen, die Sie später nicht mehr ohne Weiteres zurücknehmen können: Netzwerkmodell, Cluster-Zugriffsmodell, Identitätsanbindung, Node-Pool-Struktur, Update-Strategie. Nach Angaben von Microsoft in den AKS-Netzwerkkonzepten ist das Netzwerkmodell eine Create-Zeit-Entscheidung. Genau das ist der Punkt, den das Portal als Dropdown tarnt.

Wir haben Anrufe von Kunden bekommen, die schon beim Erstellungsprozess des AKS-Clusters überfordert waren. Nicht weil sie inkompetent wären, sondern weil das Portal Architekturfragen als Formularfelder tarnt. Genau dort entstehen die AKS Fehler, die uns achtzehn Monate später als Sanierungsprojekt wieder begegnen.

Wer den Einstieg sucht, bevor das Cluster steht, findet den Weg über die Kubernetes Beratung. Dort klären wir die Portal-Fragen, bevor sie zementiert sind.

Warum AKS Fehler am Anfang später am teuersten sind

Das ist der teuerste AKS Fehler, den wir in Projekten regelmäßig sehen: Am Anfang wurde etwas nicht bedacht, und im Nachgang ist der Weg zurück sehr kompliziert.

Ein Beispiel aus der Praxis. Das Netzwerkmodell wird beim Anlegen festgelegt. Wer sich hier für die falsche Variante entscheidet oder den Adressraum zu knapp bemisst, kann das später nicht einfach umstellen. Er baut das Cluster neu und migriert die Workloads. Ähnlich verhält es sich mit der Entscheidung zwischen öffentlichem und privatem Cluster, mit der Identitätsanbindung und mit der Struktur der Node Pools.

Deshalb ist die entscheidende Phase nicht der Betrieb, sondern der erste Tag. Wirklich zu verstehen, was Sie da gerade einrichten, ist billiger als jede spätere Sanierung. Wenn intern das Wissen dafür nicht vorhanden ist, sind ein paar Tage externe Begleitung beim Aufbau deutlich günstiger als das Neubauprojekt in achtzehn Monaten.

Die Flags, die später wehtun, stehen schon in der ersten Create-Zeile. Das hier ist kein Copy-Paste für Produktion, sondern die Stelle, an der Sie innehalten sollten:

# Illustrativ: diese Flags lassen sich nach dem Create nicht einfach umbiegen.
az aks create 
  --resource-group rg-prod 
  --name aks-prod 
  --network-plugin azure 
  --network-plugin-mode overlay 
  --pod-cidr 10.244.0.0/16 
  --enable-private-cluster 
  --enable-managed-identity 
  --node-count 3
# Netzwerkmodell, Adressraum, privat vs. öffentlich: vor dem Enter klären.

Drei Dinge daran sind später teuer, wenn sie falsch sitzen:

1. Das Netzwerk-Plugin und der Adressraum. Overlay verzeiht knappe VNets, Azure CNI ohne Overlay frisst IP-Raum, den Sie nicht nachträglich aufblasen.
2. Privat oder öffentlich. Wer den API-Server später hinter Private Link ziehen will, steht oft vor einem Neuaufbau, nicht vor einem Häkchen.
3. Die Identität. System-assigned vs. User-assigned, Kubelet-Rechte, Key-Vault-Anbindung: nachträglich machbar, aber mit Ausfallrisiko.

Wir raten aktuell davon ab, diese drei Punkte im Portal durchzuklicken, nur weil die Defaults grün sind. Defaults sind Microsofts Kompromiss für Demo-Cluster, nicht Ihre Produktionsentscheidung.

Was AKS Ihnen nicht abnimmt

Hier lohnt sich die nüchterne Liste. AKS ist gut. Aber diese Punkte bleiben bei Ihnen.

Updates. Kubernetes-Versionen laufen aus, Node-Images müssen erneuert werden. Es gibt Auto-Patch-Mechanismen, die müssen Sie aber einstellen, testen und in ein Wartungsfenster bringen. Automatisch passiert hier nichts, was Sie nicht vorher konfiguriert haben. Nach Angaben der AKS-Auto-Upgrade-Dokumentation sind Cluster-Channel und Node-OS-Channel getrennte Schalter, beides muss aktiv gesetzt werden. Wer das sauber machen will, findet den Channel-Schnitt im Beitrag AKS Upgrade automatisieren. Ohne Channel und Wartungsfenster ist das Supportende keine Überraschung, sondern ein Kalendereintrag, den niemand gesetzt hat. Die Fristen stehen im Text zum AKS Version Supportende.

Skalierung. Cluster Autoscaler und Horizontal Pod Autoscaler funktionieren gut, setzen aber saubere Resource Requests und Limits voraus. Ohne die skaliert entweder nichts oder alles ins Geld.

# Illustrativ: ohne Requests bleibt der Autoscaler blind.
resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Das wirkt harmlos. Es ist der häufigste konkrete AKS Fehler, den wir in Bestandsumgebungen finden. Fehlende Requests machen Autoscaling unbrauchbar, treiben die Rechnung und sind die Ursache für einen großen Teil der Stabilitätsprobleme, die uns als AKS ist instabil gemeldet werden.

Security. Netzwerk-Policies, RBAC, Pod-Security, Image-Härtung, Secrets-Anbindung an Key Vault. Nichts davon ist Standard, alles davon ist notwendig. Der Hyperscaler sichert seine Control Plane. Ihre Workloads sichern Sie.

Kostenkontrolle. AKS macht es leicht, Ressourcen anzufordern. Es macht es nicht leicht, sie wieder loszuwerden. Ohne Governance wächst die Rechnung schneller als die Last.

Betriebsaufwand insgesamt. Man muss ganz viel Betriebsaufwand einstecken, um alles herauszuholen und das Cluster aktuell und sicher zu halten. Das ist die Zeile, die in den meisten Business Cases fehlt.

Wann AKS, wann eigenes Cluster

Die kurze Antwort: AKS, wenn Sie skalieren wollen. Eigenes Cluster, wenn Sie kontrollieren müssen.

AKS ist der richtige Weg, wenn:

• Sie ohnehin in Azure sind und die Ökosystem-Integration nutzen (Key Vault, WAF, Load Balancer, Entra ID)
• Sie deutlich größer skalieren wollen und den Hyperscaler im Untergrund brauchen
• Sie schnell produktiv sein müssen
• Ihre Datenschutzanforderungen mit Verschlüsselung, Customer Managed Keys und Policies abbildbar sind

Ein eigenes Cluster ist der richtige Weg, wenn:

• Sie hochsensible Daten verarbeiten, Medizindaten sind der Klassiker
• Regulatorik oder interne Policy den Weg in eine US-Cloud faktisch versperren
• Sie ohnehin nur ein kleines Cluster mit stabiler Last brauchen
• Sie auf einen lokalen deutschen Anbieter oder ein Fremdrechenzentrum gehen wollen

Wir sehen aktuell spürbar mehr Bewegung in die zweite Richtung, aus Regulatorik- und Datenschutzgründen. Aber es ist eine Abwägung, keine Grundsatzentscheidung, und sie fällt in einem Gespräch über Ihre konkreten Anforderungen deutlich besser als in einer Grundsatzdebatte.

Wer den Sovereign-Pfad konkret braucht, also Region, Schlüsselhoheit und Nachweis, findet den Schnitt in AKS und Sovereign Kubernetes. AKS bleibt dort die Plattform, Souveränität ist die Konfiguration drumherum, nicht der Produktname.

Unsere klare Empfehlung: Kleines Cluster, gleichmäßige Last, strenge Datenhoheit, dann Eigenbetrieb oder ein deutscher Managed-Anbieter. Stark schwankende Last, knappes Personal, Azure-Ökosystem schon da, dann AKS. Die Mischform, AKS aufsetzen und hoffen, der Rest ergibt sich, ist die teuerste der drei Optionen.

Der Kostenpunkt, den niemand gern anspricht

Was man nicht verschweigen darf: Azure ist teurer als viele andere Anbieter, und AKS selbst kostet Geld, mehr, als wenn Sie Kubernetes selbst aufbauen und betreiben.

Dafür nehmen Sie eine ganze Reihe von Vorteilen mit: Skalierbarkeit auf Abruf, mehrere Rechenzentrumsstandorte in Deutschland und der EU, ein integriertes Ökosystem und keine Hardwareinvestition. Ob dieser Tausch für Sie aufgeht, hängt an Ihrem Lastprofil und an Ihren Personalkosten.

Ehrlich gerechnet gilt: Bei kleinen, stabilen Clustern ist Eigenbetrieb oft günstiger. Bei stark schwankender Last, hohen Verfügbarkeitsanforderungen oder knappem Personal dreht sich das Verhältnis. Der teuerste AKS Fehler in der Rechnung ist nicht die Node-VM, sondern ein Cluster, das man nach 18 Monaten neu bauen muss.

Die Personalseite wird in den meisten Vergleichen unterschlagen. AKS spart Ihnen nicht den Platform Engineer, es spart Ihnen den Control-Plane-Betrieb. Updates, Härtung, Alerting und der Nachweis bleiben. Wer die interne Rechnung ohne diese Stellen aufmacht, rechnet sich AKS schön. Die Gegenrechnung, was zwei interne FTEs plus On-Call wirklich kosten, steht in der Kubernetes-Eigenbetrieb-Rechnung.

Wenn der Cluster stehen soll, der Betrieb aber nicht intern hängt, ist der nächste sinnvolle Schritt ein Kubernetes Managed Service: Cluster bleibt bei Ihnen, Betrieb nicht.

Production-Gap: Cluster läuft, Grundentscheidung trägt nicht

Die AKS Fehler aus dem Portal-Create bleiben unsichtbar, solange die Demo läuft. Sichtbar werden sie im Cutover.

Häufig gestellte Fragen

Kann man AKS Fehler nachträglich korrigieren?

Teilweise. Vieles lässt sich nachziehen: Policies, Security-Konfiguration, Monitoring, Node Pools. Einige Grundentscheidungen aber nicht, insbesondere das Netzwerkmodell und der Adressraum. Dann ist der saubere Weg ein Neuaufbau mit paralleler Migration. Das ist unangenehm, aber planbar, und deutlich besser, als Jahre auf einem Fundament weiterzubauen, das nicht trägt.

Was kostet es, ein falsch aufgesetztes AKS-Cluster zu sanieren?

Kommt darauf an, was zementiert ist. Policies und Requests sind Tage- bis Wochenarbeit. Ein falsches Netzwerkmodell mit zu knappem Adressraum ist ein Neuaufbau, also paralleles Cluster, Migration, Cutover. Das landet schnell im mittleren fünfstelligen Bereich, plus die interne Zeit. Ein Review vor dem ersten Create ist dagegen ein paar Tage.

Wie viel Betriebsaufwand entsteht realistisch für ein AKS-Cluster?

Das hängt stark an der Umgebung, aber die Faustregel lautet: Es ist mehr als ein Nebenjob und weniger als eine Vollzeitstelle, genau in dem Bereich, in dem Organisationen die Zuständigkeit gern an jemanden hängen, der eigentlich etwas anderes tut. Genau daraus entstehen die meisten Probleme, die wir später sanieren.

Brauchen wir für AKS trotzdem Kubernetes-Know-how?

Ja, und zwar mehr, als der Name suggeriert. AKS nimmt Ihnen den Aufbau der Control Plane ab, nicht das Verständnis von Kubernetes. Wer Deployments, Netzwerk-Policies, RBAC und Ressourcenmanagement nicht versteht, betreibt ein Cluster, das läuft, bis es das nicht mehr tut.

Ist AKS für kleine Umgebungen sinnvoll?

Selten. Bei einem kleinen Cluster mit gleichmäßiger Last zahlen Sie den Hyperscaler-Aufschlag für Elastizität, die Sie nicht abrufen. Dann ist entweder ein eigenes Cluster oder ein deutscher Managed-Service-Anbieter meist die wirtschaftlichere Wahl.

Nächster Schritt

Wenn Sie AKS neu aufsetzen: Klären Sie Netzwerkmodell, Zugriffsmodell, Identitätsanbindung und Update-Strategie, bevor Sie das erste Mal auf Erstellen klicken. Wenn Sie AKS bereits betreiben: Lassen Sie einmal von außen prüfen, ob die Grundentscheidungen zu dem passen, was die Umgebung heute leisten soll.

Mitbringen sollten Sie den Zugang zu einem Ansprechpartner mit Portal-Rechten und eine Aussage dazu, wie sich Ihre Last in den nächsten zwei Jahren entwickeln soll.

Robin Werner, Head of Azure und Kubernetes bei Pexon Consulting, erklärt, was Kunden bei Azure Kubernetes Service unterschätzen und wann der Weg zum eigenen Cluster der richtige ist. Video auf YouTube ansehen.

Verwandte Themen