Die populärste Kubernetes-Empfehlung lautet: „Starte klein, deploye einen Container und skaliere später.“ Für eine Demo stimmt das. Für österreichische Enterprise-Umgebungen führt dieser Rat oft in die falsche Richtung. Das erste Kubernetes Deployment ist selten der kritische Teil. Schwierig wird es, wenn ein Workload in einer hybriden, regulierten Landschaft nachvollziehbar betrieben, geprüft, aktualisiert und im Fehlerfall sicher zurückgerollt werden muss.
Österreich zeigt, dass Kubernetes längst über Start-ups hinaus eingesetzt wird. Die Stadt Wien kündigte am 31.01.2024 an, ihr Rechenzentrum schrittweise mit Kubernetes und Red Hat OpenShift zu modernisieren. Die Ankündigung zur Modernisierung des Wiener Rechenzentrums ist damit ein praktisches Signal für den Einsatz in grossen öffentlichen Umgebungen, in denen Legacy-Integration, Governance und kritische Betriebsprozesse zusammenkommen.
Ein weiterer österreichischer Kubernetes-Marktüberblick führt 257 Unternehmen auf, die Kubernetes einsetzen. Zusätzlich werden 104 Unternehmen mit Kubernetes-Recruiting und 5.583 offene Rollen genannt. Die Zahlen sind kein amtlicher Statistikwert, zeigen aber deutlich, dass die Plattform in österreichischen IT-, Software-, Banking-, Bau- und Versicherungsumgebungen organisatorisch angekommen ist.
Der relevante Schmerzpunkt lautet deshalb nicht „Wie schreibe ich ein Deployment-Manifest?“. Er lautet: Wie wird aus einem technischen Deployment ein revisionssicherer, beobachtbarer und wirtschaftlich tragfähiger Betrieb?
Inhaltsverzeichnis
- Warum die meisten Kubernetes-Deployments im Betrieb scheitern
- Das erste Deployment mit produktionsreifer YAML-Struktur
- Rollout-Strategien für unterschiedliche Risikoprofile
- Skalierung und Observability im laufenden Betrieb
- CI/CD-Integration mit Governance von Anfang an
- Typische Fehler und wie man sie systematisch behebt
- Entscheidungsrahmen für Workload-Platzierung und Betriebsmodell
Warum die meisten Kubernetes-Deployments im Betrieb scheitern
Viele Tutorials enden genau dort, wo der Enterprise-Betrieb beginnt. Ein Image wird geladen, ein Pod startet, ein Service antwortet. Danach fehlen häufig die Fragen, die im Produktionsalltag entscheidend sind: Wer darf deployen? Welche Version lief zu welchem Zeitpunkt? Welche Daten dürfen in welchem Cluster liegen? Wie wird ein Rollout nachgewiesen? Und wer entscheidet, ob ein Fehler ein Rollback oder eine weitere Analyse auslöst?
Ein Kubernetes Deployment scheitert deshalb selten an der Syntax. Es scheitert an fehlender Betriebsverantwortung. Manuelle Änderungen im Cluster, uneinheitliche Namespaces und individuell gepflegte YAML-Dateien erzeugen eine Umgebung, in der niemand mehr zuverlässig sagen kann, welche Konfiguration gültig ist. Für Audits ist das problematisch, für Incident Response ebenfalls.
Österreichische Unternehmen arbeiten dabei oft mit hybriden Strukturen. Lokale Systeme, Cloud-Dienste, bestehende Virtualisierung und regulatorische Vorgaben müssen gemeinsam funktionieren. Microsoft eröffnete seine Cloud-Region in Österreich 2025, Google kündigte für 2026 sein erstes Rechenzentrum in Oberösterreich an. Das schafft zusätzliche Platzierungsoptionen, beseitigt aber keine Anforderungen an Datenresidenz, Zugriffskontrolle oder Kontrollnachweise, wie die Informationen zur österreichischen Microsoft-Rechenzentrumsregion zeigen.
Der Pilot beweist nicht die Betriebsfähigkeit
Ein Pilot beantwortet, ob ein Container auf Kubernetes laufen kann. Er beantwortet nicht, ob das Team den Workload über Monate sicher betreiben kann. Genau hier entstehen die typischen Lücken:
- Manuelle Deployments: Änderungen sind nicht reproduzierbar und lassen sich später schwer belegen.
- Fehlende Standards: Jede Anwendung verwendet andere Labels, Probes, Ressourcenwerte und Rollout-Regeln.
- Unklare Zuständigkeiten: Das Entwicklungsteam besitzt den Code, das Infrastrukturteam den Cluster, aber niemand besitzt den gesamten Betriebsprozess.
- Knappes Plattformwissen: Der österreichische Arbeitsmarktüberblick nennt 104 Firmen mit Kubernetes-Jobbedarf und 5.583 offene Rollen. Das Verzeichnis österreichischer Kubernetes-Unternehmen ist zwar keine amtliche Erhebung, macht den Engpass an qualifizierten Betriebs- und Plattformteams aber sichtbar.
Praktische Regel: Ein Deployment gilt erst dann als produktionsreif, wenn Konfiguration, Berechtigungen, Nachweise, Monitoring und Rückrollback gemeinsam funktionieren.
Kubernetes ist damit nicht nur eine Containerplattform. Es ist ein Betriebsmodell. Wer nur das Cluster aufsetzt, verschiebt die eigentliche Arbeit auf später. In regulierten Umgebungen ist „später“ meistens der ungünstigste Zeitpunkt.
Das erste Deployment mit produktionsreifer YAML-Struktur
Ein brauchbares Manifest macht den Workload für Menschen und Maschinen eindeutig. Labels verbinden Deployment, Pods, Monitoring und Policy-Checks. Ressourcenangaben helfen dem Scheduler, Probes schützen den Traffic vor nicht bereiten Pods, und ein PodDisruptionBudget begrenzt freiwillige Unterbrechungen während Wartungen.
Das folgende Beispiel ist bewusst als Template für einen typischen internen Service gehalten. Das Image, die Ressourcengrössen und die Probe-Pfade müssen vor dem produktiven Einsatz anhand von Lasttests und realen Startzeiten angepasst werden.
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-api
namespace: production
labels:
app.kubernetes.io/name: order-api
app.kubernetes.io/part-of: commerce
app.kubernetes.io/component: api
app.kubernetes.io/managed-by: gitops
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
selector:
matchLabels:
app.kubernetes.io/name: order-api
template:
metadata:
labels:
app.kubernetes.io/name: order-api
app.kubernetes.io/part-of: commerce
app.kubernetes.io/component: api
spec:
serviceAccountName: order-api
containers:
- name: order-api
image: registry.example.at/commerce/order-api:1.4.2
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: order-api
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app.kubernetes.io/name: order-api
Die wichtigen Felder
replicas beschreibt die gewünschte Anzahl gleichzeitig laufender Pods. Die Zahl ist kein Qualitätsbeweis. Sie muss zur Kapazität, zur Verfügbarkeit der Abhängigkeiten und zur gewählten Rollout-Strategie passen.
selector und die Pod-Labels müssen zusammenpassen. Ein falscher Selector kann dazu führen, dass das Deployment seine Pods nicht verwaltet. Konsistente app.kubernetes.io-Labels erleichtern zusätzlich Observability, Kostenstellen-Zuordnung und Policy-Enforcement.
requests reservieren die erwartete Kapazität für die Scheduling-Entscheidung. limits begrenzen die maximale Nutzung. Zu niedrige Requests erzeugen Überbuchung und instabile Performance, zu hohe Werte führen zu stiller Überprovisionierung. Produktive Werte gehören deshalb in einen reproduzierbaren Prozess, nicht in eine spontane Schätzung.
Ein Pod ohne readinessProbe kann Traffic erhalten, obwohl der Prozess zwar läuft, aber noch keine Datenbankverbindung oder Cache-Struktur aufgebaut hat. Eine zu aggressive livenessProbe kann dagegen einen langsam startenden, aber gesunden Prozess fortlaufend neu starten. initialDelaySeconds, Timeout und Fehlergrenzen müssen das tatsächliche Start- und Antwortverhalten abbilden.
Für reproduzierbare Infrastruktur sollte das Manifest nicht als lokale Datei auf einem Laptop enden. Eine Einordnung von Infrastructure as Code hilft, Konfigurationen versioniert, reviewbar und automatisiert auszurollen.
Rollout-Strategien für unterschiedliche Risikoprofile
Die beste Rollout-Strategie hängt nicht vom persönlichen Geschmack ab. Sie hängt davon ab, wie schnell ein Fehler erkannt wird, wie viel Unterbrechung akzeptabel ist und wie sicher ein Rollback funktioniert.
| Strategie | Geeignet für | Stärke | Typisches Risiko |
|---|---|---|---|
| Rolling Update | Regelmässige, gut verstandene Änderungen | Einfach und ressourcenschonend | Fehler erreicht schrittweise weitere Pods |
| Canary Deployment | Neue Funktionen und messbare Nutzerreaktionen | Begrenzte Exposition | Ohne gutes Monitoring bleibt der Test blind |
| Blue/Green | Kritische Systeme mit klarer Umschaltung | Schneller Wechsel auf die bekannte Version | Paralleler Betrieb benötigt zusätzliche Kapazität |
Rolling Update
Rolling Updates passen zu Services, deren Änderungen gut rückwärtskompatibel sind. maxUnavailable: 0 verhindert, dass während der Aktualisierung absichtlich verfügbare Kapazität verloren geht, während maxSurge die temporäre Zusatzkapazität begrenzt. Diese Strategie ist nicht automatisch ausfallsicher. Ohne Readiness-Probes kann Kubernetes einen neuen Pod als verfügbar betrachten, obwohl die Anwendung noch nicht bereit ist.
Ein Rollback erfolgt typischerweise über die Deployment-Historie. Das funktioniert nur zuverlässig, wenn Images unveränderlich versioniert sind und die vorherige Konfiguration noch bekannt ist. Ein „latest“-Tag gehört nicht in diesen Prozess.
Canary Deployment
Canary Releases senden zunächst nur einen begrenzten Teil des Traffics an die neue Version. Dafür braucht das Team eine belastbare Messung, etwa Fehlerraten, Latenz, fachliche Erfolgsquoten und relevante Logs. Ein Canary ohne Alerts ist lediglich ein kleinerer, unbemerkter Rollout.
Die technische Umsetzung kann über getrennte Deployments und Traffic-Steuerung mit Ingress oder Service Mesh erfolgen. Die Entscheidung zum Weiterrollen muss vorab definiert sein. Wer erst während des Incidents diskutiert, welche Metrik einen Abbruch auslöst, hat keinen kontrollierten Canary-Prozess.
Blue/Green Deployment
Bei Blue/Green laufen alte und neue Version parallel. Ein Service oder eine Ingress-Regel schaltet den produktiven Traffic nach erfolgreicher Prüfung um. Das ist für kritische Systeme attraktiv, weil der Rückweg auf die alte Version meist schnell möglich ist. Der Preis ist zusätzlicher Kapazitätsbedarf und die Notwendigkeit, Datenbankänderungen rückwärtskompatibel zu gestalten.
PodDisruptionBudgets und Readiness-Probes ergänzen jede Strategie. Das Budget schützt vor freiwilligen Unterbrechungen bei Wartungen, die Probe verhindert Traffic auf unbereite Pods. Besonders in verteilten Umgebungen mit österreichischen Edge-Infrastrukturen ist ein expliziter Kapazitätsplan erforderlich. Der EU Digital Decade Country Report für Österreich weist für 2025 rund 210 Edge Nodes aus. Das unterstreicht, dass Rollouts nicht nur im zentralen Rechenzentrum stattfinden und Canary- oder Blue/Green-Verfahren bei Latenz- und Verfügbarkeitsanforderungen sinnvoll sein können.
Skalierung und Observability im laufenden Betrieb
Autoscaling löst keine schlechte Kapazitätsplanung. Es reagiert auf Signale, die das Team vorher ausgewählt und kalibriert hat. Ein Horizontal Pod Autoscaler kann Pods anhand von CPU- oder anwendungsnahen Metriken skalieren. Der Vertical Pod Autoscaler kann Ressourcenempfehlungen liefern oder anpassen. Der Cluster Autoscaler fügt Nodes hinzu, wenn Pods wegen fehlender Kapazität nicht eingeplant werden können.
Diese Mechanismen dürfen nicht unkoordiniert auf denselben Workload losgelassen werden. Wenn der HPA zu aggressiv skaliert, steigt der Node-Bedarf. Wenn der VPA gleichzeitig Limits verändert, ändern sich die Scheduling-Voraussetzungen. Ohne klare Zuständigkeit entstehen Schwingungen, unnötige Neustarts oder Kosten, die im Monatsabschluss überraschend auftauchen.
Metriken mit Betriebswert
Ein sinnvolles Observability-Fundament beginnt mit den Fragen, die ein Bereitschaftsteam beantworten muss:
- Verfügbarkeit: Erreicht der Service die vereinbarten Endpunkte?
- Latenz: Werden Antworten langsamer, obwohl Pods noch gesund erscheinen?
- Fehler: Steigen HTTP-Fehler, Queue-Fehler oder fachliche Abbrüche?
- Kapazität: Reichen CPU, Memory, Storage und Node-Ressourcen?
- Rollout: Ist die neue Version tatsächlich bereit oder wartet sie auf Events?
Labels wie Anwendung, Komponente, Umgebung und Team verbinden diese Signale. Sie verhindern, dass ein Dashboard nur rote und grüne Kästchen zeigt, ohne Verantwortliche oder betroffene Abhängigkeiten zu benennen.
Österreichs Cloud-Nutzung lag laut EU Digital Decade Country Report 2026 bei 41,7%, mit einem jährlichen Wachstum von 8,3% seit 2023. Diese Werte beschreiben den Digitalisierungsstand, nicht automatisch Kubernetes-Reife. Für ein Kubernetes Deployment folgt daraus trotzdem eine klare Reihenfolge: Cloud-Readiness, Netzwerksegmentierung, IAM und RBAC sowie Observability müssen vor komplexen produktiven Rollouts belastbar sein.
Für die Anbindung an externe Systeme gehören auch Ingress und Load Balancing in die Betriebsbetrachtung. Der Praxisüberblick zu Load Balancing ist dabei eine sinnvolle Ergänzung, ersetzt aber keine anwendungsspezifische Lastmessung.
CI/CD-Integration mit Governance von Anfang an
Ein produktives Deployment sollte aus einem Commit entstehen, nicht aus einer SSH-Sitzung auf einem Cluster. Die Pipeline muss dabei mehr prüfen als die Gültigkeit von YAML. Sie muss feststellen, ob das Image vertrauenswürdig ist, ob die Konfiguration Unternehmensregeln einhält und ob der Rollout für die Zielumgebung zugelassen ist.
Ein verlässlicher Ablauf trennt Build, Prüfung und Betrieb:
- Build: Container-Image reproduzierbar erstellen und mit einer unveränderlichen Version versehen.
- Supply Chain: Image signieren und die Signatur vor dem Deployment prüfen.
- Konfiguration: Helm oder Kustomize für standardisierte Umgebungsvarianten verwenden.
- Policy: Ressourcenangaben, privilegierte Container, erlaubte Registries, Labels und Network Policies automatisiert prüfen.
- Freigabe: Pull Request, Review und gegebenenfalls eine fachliche oder regulatorische Freigabe dokumentieren.
- Rollout: GitOps oder ein gleichwertiger Mechanismus synchronisiert den gewünschten Zustand.
- Nachweis: Pipeline, Commit, Image-Digest, Zielnamespace und Rolloutstatus bleiben auffindbar.
Governance ist Teil des Artefakts
RBAC muss nach dem Prinzip der geringsten Berechtigung aufgebaut werden. Entwickler brauchen nicht automatisch Cluster-Admin-Rechte, und eine Pipeline sollte nur in die Namespaces schreiben können, die sie tatsächlich betreut. Network Policies sollten den erlaubten Datenfluss explizit beschreiben, statt auf implizite Erreichbarkeit zu vertrauen.
Audit-Logs sind dabei kein Ersatz für Prozessklarheit. Sie zeigen, wer eine Aktion ausgeführt hat. Git-Historie, Freigaben und Pipeline-Metadaten zeigen zusätzlich, warum die Änderung zugelassen wurde. Erst diese Kombination ergibt einen brauchbaren Kontrollnachweis.
Betriebsnachweis: Ein Rollout ist erst vollständig dokumentiert, wenn nicht nur das Ergebnis, sondern auch die verantwortliche Änderung und die angewendeten Prüfungen nachvollziehbar sind.
Helm eignet sich für klar strukturierte Parameter und wiederverwendbare Templates. Kustomize ist oft angenehmer, wenn Umgebungen nahe am Basemanifest bleiben sollen. Beide Werkzeuge lösen keine Governance von selbst. Sie schaffen nur die Grundlage, auf der Signierung, Policy-Checks und Reviewprozesse reproduzierbar arbeiten können.
Für die Verbindung von Sicherheitskontrollen, Verantwortlichkeiten und Nachweisen liefert ein Security- und Governance-Framework zusätzliche Struktur. Entscheidend bleibt, dass die Regeln im Pipeline-Prozess technisch erzwungen werden und nicht nur in einem Dokument stehen.
Typische Fehler und wie man sie systematisch behebt
Ein CrashLoopBackOff ist keine Diagnose, sondern ein Symptom. In einem Rollout trat ein solcher Status auf, nachdem eine Anwendung zwar den Container gestartet hatte, aber ihre Konfiguration erst beim ersten Request vollständig validierte. Die Liveness-Probe interpretierte diesen Zustand als dauerhaftes Versagen und löste Neustarts aus.
Die richtige Reihenfolge beginnt nicht mit einem Patch. Zuerst wird der betroffene Pod identifiziert, danach werden Beschreibung, Logs und Events gemeinsam gelesen:
kubectl get pods -n production
kubectl describe pod <pod-name> -n production
kubectl logs <pod-name> -n production --previous
kubectl get events -n production --sort-by=.lastTimestamp
Statusmeldung und wahrscheinliche Ursache
| Status | Häufige Ursache | Erste Prüfung |
|---|---|---|
| CrashLoopBackOff | Prozess beendet sich oder Probe schlägt fehl | Vorherige Logs, Exit-Code, Probe-Konfiguration |
| ImagePullBackOff | Registry, Tag oder Berechtigung fehlerhaft | Events, Image-Referenz, ImagePullSecret |
| Pending | Scheduler findet keinen passenden Node | Requests, Taints, Affinity, verfügbare Kapazität |
| Container bleibt unready | Abhängigkeit oder Startphase nicht abgeschlossen | Readiness-Logs, Service Discovery, Timeout-Werte |
Bei ImagePullBackOff stehen die Events meist näher an der Ursache als die Pod-Ausgabe. Ein falscher Registry-Pfad, ein nicht vorhandenes Tag oder ein fehlender Service Account mit Pull-Berechtigung kann den Start verhindern. Das Image einfach erneut zu deployen ändert daran nichts.
Pending weist oft auf falsch gesetzte Requests, Node-Taints oder unpassende Affinity-Regeln hin. Werden CPU- und Memory-Requests zu gross gewählt, findet der Scheduler keinen geeigneten Node, obwohl im Cluster insgesamt noch Kapazität vorhanden sein kann. Werden sie zu klein gewählt, läuft der Pod zwar an, konkurriert aber später mit anderen Workloads.
Dauerhafte Fehlerbehebung
Bei Probes müssen Startverhalten und Betriebszustand getrennt betrachtet werden. Eine startupProbe kann für Anwendungen sinnvoll sein, die beim Start Migrationen oder umfangreiche Initialisierung durchführen. Die Readiness-Probe beantwortet die Traffic-Frage, die Liveness-Probe die Frage nach einem festgefahrenen Prozess. Diese Zustände dürfen nicht mit demselben Endpunkt modelliert werden.
Network-Policy-Fehler zeigen sich häufig erst als Timeout zu einer Datenbank oder einem internen Service. Deshalb gehören Namespace, Service Account, Zielport und erlaubte Richtung in die Prüfung. Wer nur das Deployment neu startet, behebt die Policy nicht.
Entscheidungsrahmen für Workload-Platzierung und Betriebsmodell
Nicht jeder Workload gehört in Kubernetes. Die richtige Frage lautet nicht, ob sich eine Anwendung technisch containerisieren lässt, sondern ob Plattformnutzen, Betriebsaufwand und Kontrollanforderungen zusammenpassen.
Für österreichische Unternehmen sollte die Entscheidung mindestens diese Dimensionen enthalten:
- Workload: Ist die Anwendung stateless, modular und für deklarative Bereitstellung geeignet? Ein eng gekoppeltes Legacy-System mit schwer portierbarem Storage ist nicht automatisch ein guter Kubernetes-Kandidat.
- Datenhaltung: Müssen Daten lokal, in einer bestimmten Region oder innerhalb einer kontrollierten Netzwerkzone bleiben? Lokale Infrastruktur erleichtert die Platzierung, ersetzt aber keine Datenklassifizierung und Zugriffskontrolle.
- Betriebsmodell: Gibt es ein Team für Upgrades, Incident Response, Kapazitätsplanung, Policy-Management und Dokumentation? Fehlt diese Verantwortung, ist Managed Kubernetes oder eine andere Plattform oft vernünftiger.
- Skalierung: Entsteht ein echter Vorteil durch mehrere Replikas, automatisierte Rollouts, Service Discovery oder Fleet-Management? Wenn der Workload dauerhaft klein und stabil bleibt, kann eine einfachere Plattform wirtschaftlicher sein.
- Regulatorik: Können Änderungen, Zugriffe, Images und Rollbacks revisionssicher nachgewiesen werden? Wenn nicht, ist das Problem nicht mit zusätzlichem YAML gelöst.
Lokal, managed oder alternative Plattform
Ein lokaler Cluster passt, wenn Datenresidenz, Netzwerknähe, bestehende Infrastruktur oder spezielle Integrationen ausschlaggebend sind und das Unternehmen den Betrieb kontrollieren kann. Managed Kubernetes reduziert den Aufwand für Cluster-Lifecycle und Control Plane, nimmt dem Team aber nicht automatisch die Verantwortung für Anwendung, Berechtigungen, Secrets und Datenflüsse ab.
Cloud-First ist sinnvoll, wenn standardisierte Infrastruktur, elastische Kapazität und vorhandene Cloud-Kompetenz stärker wiegen als lokale Kontrolle. Für nicht containerisierte oder stark zustandsgebundene Workloads bleiben VM oder PaaS oft die bessere Wahl. Die österreichische Digital-Agenda weist weiterhin auf Lücken bei Cloud-Nutzung und Datenanalyse sowie auf strukturelle und fiskalische Infrastrukturhürden hin. Das macht eine nüchterne Voranalyse wichtiger als einen pauschalen Kubernetes-Standard.
Mein Entscheidungsrahmen ist einfach: Erst Workload und Betriebsverantwortung klären, dann die Plattform auswählen. Beginnt mit einem begrenzten, gut messbaren Service, baut Policies und Runbooks gleichzeitig auf und erweitert die Plattform erst, wenn der Betrieb die zusätzliche Komplexität nachweislich tragen kann.
Specialty Tokens unterstützt österreichische Enterprise- und Mittelstandsteams bei AI-Implementierungen, sicheren Integrationen und produktiven Automatisierungs-Workflows, auch in komplexen ERP-, CRM- und Legacy-Landschaften. Wenn Sie Kubernetes-Betrieb, Governance oder AI-gestützte Operations gemeinsam pragmatisch bewerten und umsetzen möchten, besuchen Sie Specialty Tokens und starten Sie ein Gespräch über den passenden Rollout.