Azure Kubernetes Service im Praxistest: Infrastruktur als Code, Kostenfallen und Kapazitätsplanung – Lektionen aus „Challenges using Azure Kubernetes Service“ von Daniel Karnutsch (Vivid Planet Software GmbH)

Einleitung: Warum dieser Vortrag für Engineering-Teams relevant ist

In „Challenges using Azure Kubernetes Service“ beleuchtet Daniel Karnutsch, Software Engineer bei der Vivid Planet Software GmbH, drei sehr konkrete Baustellen, die fast jedes Team beim Schritt zu Kubernetes im Managed-Cloud-Kontext trifft: Infrastruktur als Code, Kosten (und deren Vorhersagbarkeit) sowie Kapazitätsplanung. Vivid Planet ist ein Softwareunternehmen nahe Salzburg (Hallwang) mit rund 60 Personen. Das Team entwickelt maßgeschneiderte Lösungen für große Unternehmen – vorwiegend rund ums Web – und bewegt sich damit genau in dem Spannungsfeld, in dem Kubernetes häufig zum Standard wird.

Wir bei DevJobs.at haben zugehört, welche Entscheidungen Vivid Planet getroffen hat, welche Stolpersteine auf dem Weg lagen und welche pragmatischen Gegenmaßnahmen sich bewährt haben. Der Vortrag ist bewusst praxisnah: Er zeigt, wo Managed Kubernetes echte Komplexität abnimmt – und wo neue, weniger offensichtliche Risiken entstehen.

Entscheidungsrahmen: Kubernetes-Hosting zwischen maximaler Flexibilität und weniger Komplexität

Daniel ordnet zu Beginn die typischen Hosting-Optionen ein – eine hilfreiche Matrix aus Flexibilität und operativem Aufwand:

• On-Premises, selbst verwaltetes Kubernetes: maximale Kontrolle von der Hardware über die Orchestrierung bis zu allen Zwischenlagen, aber auch maximale Komplexität und Personalbedarf.
• Selbst verwaltetes Kubernetes in der Public Cloud: Hardwareverantwortung entfällt, volle Kontrolle über Kubernetes bleibt. Flexibler als On-Prem, aber weiterhin komplex in Betrieb und Pflege.
• Managed Kubernetes in der Public Cloud (z. B. Azure Kubernetes Service): der Cloud-Provider deployt und betreibt die Control Plane, übernimmt Standardaufgaben und bietet sinnvolle Defaults. Teams behalten genug Freiheiten für eigene Anforderungen, müssen aber auf einige Eingriffsmöglichkeiten verzichten.
• Platform-as-a-Service (z. B. Red Hat OpenShift in der Public Cloud): der größte Teil der Plattformverantwortung (etwa Routing) wird abgenommen – dafür die geringste Flexibilität.

Vivid Planet hat sich für Managed Kubernetes in der Public Cloud entschieden – explizit für Azure Kubernetes Service (AKS). Die Gründe:

• „Genug“ Flexibilität bei deutlich reduzierter Komplexität für ein kleineres Team.
• Direkter Zugriff auf Public-Cloud-Services (verwaltete Datenbanken, Storage-Dienste etc.).
• Ausgereifte Standardaufgaben im Managed-Angebot: keine direkte Kontrolle über Control-Plane-Komponenten, aber verlässliche Defaults und Provider-gestützte Administrative Tasks, bis hin zu automatisch aktivierbaren Kubernetes-Version-Upgrades.

Wichtig: Auch in AKS bleiben zentrale Aufgaben im Team, etwa Routing/Load Balancing, Mandantentrennung oder Security-Konfigurationen. Managed heißt nicht „alles erledigt“, sondern „sinnvoller Fokus auf die Applikationen“ – mit klaren Zuständigkeiten, die weiterhin in der Engineering-Organisation liegen.

Herausforderung 1: Infrastruktur als Code – wenn Defaults und Realität auseinanderlaufen

Daniel nutzt das Thema „Infrastructure as Code“ (IaC), um ein grundsätzliches Muster bei Managed Services zu zeigen: Die Abstraktion hilft – aber sie ist nie deckungsgleich mit der tatsächlichen Plattform-Realität. Und genau dort entstehen die kniffligen Fälle.

Warum IaC? Kurzüberblick über die Vorteile

• Versionierung: Die Infrastrukturdefinition liegt in Dateien; Pull-Requests, Reviews, Historie und Contributor-Workflows greifen wie im Application Code.
• Reproduzierbarkeit: Infrastruktur lässt sich zuverlässig auf- und abbauen; neue Umgebungen lassen sich erstellen, indem die Konfigurationen dupliziert werden.
• Automatisierung: Vorhandene CI/CD-Pipelines können nicht nur Apps, sondern auch Infrastruktur ausrollen.

Vivid Planet setzt auf Terraform (neben Terraform nennt Daniel Pulumi als populäres IaC-Werkzeug). Die Vorteile sind real – dennoch gab es zwei sehr handfeste Problemfelder.

Problemfeld A: Abweichende Defaults im Provider

Ein zentrales Muster: Terraform-Provider bringen eigene Defaultwerte mit – und diese spiegeln nicht zwingend die aktuellen Empfehlungen oder Defaults des Cloud-Providers wider. Daniels Beispiel ist im AKS-Kontext besonders lehrreich:

• OS-Disk-Typ im Terraform-Provider: Default auf „managed disks“.
• Diese Option ist laut Daniel „nicht empfohlen“ aufgrund geringerer Performance; bevorzugt werden „ephemeral disks“.
• Der Haken: Wer sich unkritisch auf Provider-Defaults verlässt, bekommt nicht die Plattformkonfiguration, die man eigentlich anstrebt.

Das Fazit ist einfach, aber entscheidend: IaC vereinfacht das Management – ersetzt aber nicht die Notwendigkeit, Defaults bewusst zu setzen und Cloud-Provider-Entwicklungen zeitnah nachzuziehen. Wenn der Terraform-Provider „langsamer“ ist als die Plattform, klaffen Anspruch und Umsetzung auseinander.

Problemfeld B: Änderungen, die laut IaC nicht gehen – in der Plattform aber sehr wohl

Das zweite Beispiel betrifft ein hochrelevantes Betriebs-Szenario: die Änderung der VM-Größe im Default-Node-Pool eines AKS-Clusters. Daniels Befund:

• Terraform-Plan zeigt bei dieser Änderung an: Der Default-Node-Pool würde zerstört und neu erstellt – und damit der gesamte Cluster.
• Ergebnis: Downtime – in der Regel inakzeptabel.

Doch die Praxis in AKS lässt einen Ausweg zu – nur eben nicht direkt via Terraform-Plan:

1. Per Azure-Portal oder Azure CLI einen temporären „System Node Pool“ anlegen, der die Rolle des Default-Node-Pools übernimmt.
2. Den bisherigen Default-Node-Pool entfernen (es muss stets mindestens ein System-Node-Pool existieren).
3. Den neuen Default-Node-Pool mit der gewünschten VM-Größe erstellen.
4. Den temporären Node-Pool wieder löschen.

Laut Daniel gelingt so der Tausch ohne Ausfallzeit – produktionstauglich und kontrolliert. Die Kehrseite: Terraform weiß davon nichts. Die Lösung ist explizit, das Terraform-State-File manuell zu editieren, sodass der neue Zustand in IaC reflektiert wird. Danach meldet Terraform „keine Änderungen“ – die Realität und der IaC-State sind wieder synchron.

Die Meta-Lektion:

• Manche Änderungen sind aus Sicht des IaC-Providers „nicht möglich“ oder würden brachial rekonstruiert.
• Dieselbe Änderung ist jedoch über die Plattform-Tools im laufenden Betrieb realisierbar.
• Teams müssen beides zusammenbringen: Plattformseitige Workarounds beherrschen – und den IaC-State verantwortungsvoll nachziehen.

Herausforderung 2: Kosten und Kostenschätzung – über das Offensichtliche hinausdenken

Daniel greift eine Binsenweisheit auf, die im Cloud-Betrieb schmerzhaft konkret wird:

Die naive Schätzung im AKS-Kontext lautet oft: „Wir zahlen nur die Nodes.“ VM-Preise nachschlagen, multiplizieren – fertig. Der Vortrag zeigt, warum diese Perspektive unvollständig ist.

Was zusätzlich zu Buche schlägt

• SLA-Anforderungen: Wenn Kund:innen ein SLA erwarten, müssen auch Plattformkomponenten abgesichert werden – mit entsprechenden Kosten.
• Support-Plan: Cloud-Provider haben ihre Standard-Supportkanäle stark eingegrenzt (häufig auf Abrechnungsfragen). Wer technische Unterstützung braucht, benötigt einen zusätzlichen Support-Plan.
• Netzwerk-Spezifika: Statische IP-Anforderungen erfordern zusätzliche Netzwerkkomponenten. Deren Kosten sind häufig bandbreitenabhängig – und damit vorab schwer präzise zu beziffern.
• Observability: Wer die Ressourcennutzung im Betrieb verstehen will, braucht passende Telemetrie. Monitoring- und Logging-Dienste rechnen nach Nutzung ab (Anzahl Container, Logleitungen etc.) – schwer planbar, solange das System sich noch in Bewegung befindet.

Verrechnung in Mehrmandanten- oder Projekt-Setups ist knifflig

Selbst wenn die Gesamtkosten grob klar sind, wird die Verteilung anspruchsvoll:

• Node-Kosten lassen sich näherungsweise über Resource Requests auf Anwendungen verteilen.
• Linear mitwachsende Kosten (Netzwerk, Observability) sind nutzungsbasiert und schwer „gerecht“ zuzuordnen.

Daniels Leitlinien für die Praxis

• Node-Kosten als absolute Untergrenze betrachten. Daniels konkrete Zahl: Bei Vivid Planet machten die Nodes etwa 50% der Clusterkosten aus. Anders gesagt: Die Summe war doppelt so hoch wie die reine Node-Rechnung.
• Wenn es möglich ist: Eine nahezu produktionsreife Umgebung über einen längeren Zeitraum laufen lassen und die realen Kosten als Basis der Schätzung verwenden.
• Kosten in fixe und lineare Anteile trennen: Onboarding in AKS erzeugt fixe Grundkosten; je Applikation steigen dann variable Kosten mit.
• Entwicklungen im FinOps-Bereich im Blick behalten: Sie bieten Methoden zur verursachungsgerechten Kostenzuordnung und zu Einsparpotenzialen.

Die wichtigste mentale Umstellung: Statt „VM-Preise × Anzahl Nodes“ gilt „Nodes = Mindestwert, Rest ist signifikant und nutzungsgetrieben“. So entsteht eine realistischere Erwartungshaltung gegenüber Cloud-Kosten – inklusive der Unsicherheiten.

Herausforderung 3: Kapazitätsplanung – „It’s just somebody else’s computer“

Die zweite zitierte Wahrheit ist simpel und trifft ins Schwarze:

Auch in der Public Cloud müssen die physischen Ressourcen jemandem gehören und gemanagt werden. Was heißt das konkret für AKS-Workloads?

Verfügbarkeit ist nicht garantiert – weder bei Node-Typen noch in Regionen

Daniel nennt drei Ursachenfelder:

• Bestimmte VM-Typen können zeitweise nicht verfügbar sein – wegen hoher Nachfrage oder weil sie zugunsten neuerer Generationen auslaufen.
• Ganze Regionen können „voll“ sein. Daniel betont, dass er das früher nicht für möglich gehalten hätte, es in der Praxis aber erlebt hat.
• Reservierungen/Committed Usage senken zwar die Kosten, machen aber unflexibel: Wer sich auf bestimmte Produkte oder Node-Typen festlegt, kann nicht jederzeit auf Neuere wechseln.

Gegenmaßnahmen – mit Nebenwirkungen

• Migration in eine Region mit geringerer Auslastung: technisch möglich, aber eine source of truth für Latenz. Gerade wenn Datenbanken außerhalb des Clusters verbleiben, führt der Regionswechsel für die Apps zu Mehrlatenz – es sei denn, auch die Datenbanken ziehen um.
• Quotas früh und großzügig erhöhen: realistisch abschätzen, wie viele Nodes benötigt werden, den Betrieb mit dieser Größenordnung testen und Luft für Upgrades, saisonale Lastspitzen oder neue Kund:innen einkalkulieren.

Die Gemeinsamkeit: Kapazität ist in der Cloud nicht „unendlich elastisch“. Planen heißt hier, rechtzeitig die organisatorischen und technischen Weichen zu stellen, damit die Plattform den geschäftlichen Bedarf zum richtigen Zeitpunkt bedienen kann.

Konkrete Takeaways für Engineering-Teams

Auf Basis des Vortrags kristallisieren sich aus unserer Sicht fünf gruppierte Handlungsfelder heraus – alle direkt durch Daniels Beispiele gedeckt:

1) IaC bewusst und kontrolliert einsetzen

• Terraform-Provider-Defaults sind nicht automatisch die besten Defaults des Cloud-Providers. Setzt kritische Parameter explizit.
• Prüft Terraform-Pläne besonders dann, wenn sie destructive Changes andeuten. Sucht nach Plattform-nativen Workarounds.
• Plant den Sonderfall „State-Drift“ ein: Wenn Änderungen außerhalb von Terraform notwendig sind, muss der Terraform-State verantwortungsvoll nachgezogen werden.

2) Plattform-Werkzeuge beherrschen

• Für AKS-spezifische Operationen (z. B. Node-Pool-Wechsel) lohnt es sich, Portal/CLI-Playbooks parat zu haben – inklusive Rückweg in den IaC-Desired-State.

3) Kosten nicht romantisieren

• Rechnet mit signifikanten Posten jenseits der Nodes: SLA, Support, Netzwerk, Observability.
• Behandelt Node-Kosten als Untergrenze – nicht als Gesamtbild.
• Validiert Annahmen in einer länger laufenden, produktionsnahen Umgebung.
• Trennt fixe Grundkosten von linear wachsenden Anwendungsanteilen; nutzt FinOps-Praktiken zur Verrechnung und Optimierung.

4) Kapazität als Risiko und Produktmerkmal

• VM-Typen können verschwinden oder ausgebucht sein; Regionen können voll sein.
• Reservierungen sparen Geld, erhöhen aber Bindung. Diese Trade-offs bewusst eingehen.
• Quotas proaktiv erhöhen, Puffer für Upgrades, Onboarding und Lastspitzen einplanen.

5) Managed heißt Mitmachen

• Managed Kubernetes nimmt euch die Control Plane ab – nicht aber Entscheidungs- und Betriebsverantwortung bei Routing, Security, Mandantentrennung und Kostensteuerung.

Was wir aus „Challenges using Azure Kubernetes Service“ mitnehmen

Der Vortrag von Daniel Karnutsch ist eine Einladung zur Nüchternheit. Azure Kubernetes Service reduziert Komplexität dort, wo sie oft am teuersten ist – in der Pflege und Absicherung der Control Plane. Gleichzeitig verschiebt sich die Verantwortlichkeit in drei Richtungen, die Engineering-Teams aktiv gestalten müssen:

• IaC ist ein Beschleuniger – sofern man die möglichen Diskrepanzen zwischen Provider-Defaults und Cloud-Empfehlungen kennt und adressiert. Das OS-Disk-Beispiel und der Node-Pool-Wechsel zeigen: Die Details machen den Unterschied zwischen „Downtime und Neuaufbau“ und „Zero-Downtime-Upgrade“.
• Kosten sind ein System, nicht eine Zeile in der VM-Preisliste. Daniels 50%-Beispiel für die Node-Kosten ist ein klarer Marker: Ohne Metriken aus einer laufenden, produktionsnahen Umgebung bleibt jede Schätzung fragil.
• Kapazität in der Public Cloud ist weder grenzenlos noch garantiert. Wer Reservierungen nutzt, spart – bindet sich aber. Wer Regionen wechselt, gewinnt Ressourcen – bezahlt mit Latenz, insbesondere wenn Datenhaltung außerhalb des Clusters verbleibt. Wer Quotas frühzeitig anhebt, schafft Handlungsfähigkeit in kritischen Momenten.

Für Teams, die AKS einführen oder skalieren, ist die Botschaft ermutigend und anspruchsvoll zugleich: Managed Kubernetes ist gereift und praxistauglich. Die eigentlichen Herausforderungen beginnen dort, wo Architektur, Betrieb und Kostenmodell aufeinanderprallen – genau die Felder, die Daniel offen adressiert.

Schluss: Fokus schärfen, wo es zählt

Am Ende steht ein pragmatischer Dreiklang, den wir aus „Challenges using Azure Kubernetes Service“ mitnehmen:

• Bewusst entscheiden: Wo abstrahiert AKS, wo bleibt Verantwortung bei uns?
• Transparent messen: Welche Kosten entstehen wirklich, wie verteilen sie sich, und welche Annahmen halten dem Betrieb stand?
• Vorausschauend planen: Welche Kapazitätsrisiken treffen unser Setup, und welche Puffer geben uns Manövrierfähigkeit?

Oder, frei nach den beiden zitierten Linien: Die Zukunft vorherzusagen ist schwer – und die Cloud ist eben doch nur der Computer eines anderen. Wer diese Realität operativ annimmt, kann AKS stabil, skalierbar und ohne böse Überraschungen betreiben.