Kubernetes · Assessment bis Übergabe
Kubernetes-Beratung für Architektur, Einführung und Betrieb
Wir klären, ob Ihre Workloads auf Kubernetes gehören, welches Betriebsmodell zu Ihnen passt und wie der Cluster produktionsfähig wird: mit begründeter Entscheidung, nicht mit Standardempfehlung.
- STACKIT Kubernetes Engine (SKE)
- Eigenes Kubernetes auf Proxmox
- EKS, AKS und GKE
01Ausgangslage
Der Cluster läuft. Ist er auch betreibbar?
Die ersten Container-Anwendungen laufen, aber Clusterbetrieb, Updates und Rechtekonzept sind ungeregelt? Oder ein Cluster wurde „einfach aufgesetzt“ und soll nun produktionsfähig werden, mit Netzwerkrichtlinien, Backup, Observability und Wiederanlaufkonzept?
SKAFFON berät bei der Einführung und dem Betrieb von Kubernetes: von der Frage, ob Ihre Workloads überhaupt auf Kubernetes gehören, über die Wahl zwischen verwaltetem Cluster und Eigenbetrieb bis zur Einrichtung, Validierung und Übergabe. Soll der Betrieb danach nicht bei Ihnen liegen, gibt es Managed Kubernetes.
- Es steht eine Plattformentscheidung an: verwalteter Dienst, eigene Infrastruktur oder beides.
- Anforderungen an Datenstandort oder Betreiberkontrolle machen den bisherigen Cloud-Dienst fraglich.
02Vorgehen
Vom Workload-Inventar zur übergebenen Plattform
Sechs Schritte, jeder mit einem greifbaren Ergebnis.
- 01
Workload-Assessment
Ergebnis: Zuordnung je WorkloadWir prüfen, welche Anwendungen zu Kubernetes passen, welche besser auf virtuellen Maschinen oder als Managed Service bleiben, und welche vorher überarbeitet werden müssen (Konfiguration, Zustand, Health-Checks).
- 02
Architektur
Ergebnis: ZielarchitekturClusterzuschnitt (ein Cluster pro Umgebung, pro Team oder pro Mandant), Netzwerk und Ingress, Speicher, Namensräume und Mandantentrennung, Rechtekonzept mit RBAC und Anbindung an Ihre Identitätsverwaltung.
- 03
Cluster-Auswahl
Ergebnis: EntscheidungsvorlageEntscheidung zwischen den Betriebsmodellen anhand der Matrix unten, dokumentiert als Entscheidungsvorlage.
- 04
Betriebskonzept
Ergebnis: BetriebsregelnUpgrade-Strategie, Backup und Wiederherstellung, Observability, Kapazitäts- und Kostensteuerung, Zuständigkeiten.
- 05
Implementierung
Ergebnis: Cluster als CodeProvisionierung der Cluster als Infrastructure as Code, Basiskonfiguration (Netzwerkrichtlinien, Zugriffsmodell, Secrets-Handling, Ressourcenlimits), Anbindung an CI/CD und GitOps.
- 06
Validierung und Übergabe
Ergebnis: Runbooks, EinweisungFunktionstests, Wiederherstellungstest, Runbooks und Einweisung Ihres Teams.
03Entscheidungsmatrix
STACKIT SKE, Proxmox oder Hyperscaler: Wo Ihr Cluster laufen sollte
Die Matrix zeigt, wie wir die drei Betriebsmodelle gegeneinander abwägen. Sie ist ein Bewertungsraster, keine Rangliste: Je nach Gewichtung Ihrer Kriterien gewinnt eine andere Spalte. Stand: 13.11.2026; Produktdetails ändern sich, prüfen Sie sie vor einer Entscheidung in der Dokumentation der Anbieter: STACKIT Kubernetes Engine, Proxmox VE, Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine.
| Kriterium | STACKIT SKE | Eigenes Kubernetes auf Proxmox | EKS / AKS / GKE |
|---|---|---|---|
| Wer betreibt die Control Plane? | Anbieter; laut STACKIT-Dokumentation verwaltet und hochverfügbar, SLA 99,9 % für die Verfügbarkeit des API-Servers | Sie oder ein Betriebspartner (z. B. SKAFFON) | Anbieter |
| Wer betreibt Worker und Hardware? | Node Pools bei STACKIT; Betrieb der Workloads bei Ihnen | Vollständig Sie: Hardware, Virtualisierung, Netz, Speicher | Anbieter für Infrastruktur; Betrieb der Workloads bei Ihnen |
| Datenstandort und Betreiberkontrolle | Regionen und vertragliche Zusagen im STACKIT-Vertrag prüfen | Maximal: Standort, Zugriff und Schlüssel bleiben bei Ihnen | Region je Dienst festzulegen, Verfügbarkeit je Region verschieden: EKS, AKS, GKE. Rechts- und Zugriffsfragen des Anbieterkonzerns separat bewerten |
| Updates und Reparatur | Automatische Updates im konfigurierbaren Wartungsfenster (Kubernetes nur auf höhere Patch-Stufen, dazu Betriebssystem; Pflicht-Updates bei auslaufender Version, auch bei deaktiviertem Auto-Update), Auto-Repair dokumentiert: Versions-Updates; Einfluss auf Ihre Workloads einplanen | Vollständig in Ihrer Hand; höchster Betriebsaufwand | Je nach Dienst unterschiedlich: AKS mit Auto-Upgrade-Kanälen und Wartungsfenster, GKE mit Node-Auto-Repair (Standard-Voreinstellung), EKS mit automatischem Control-Plane-Upgrade am Support-Ende; Nodes in EKS Managed Node Groups folgen dem Control-Plane-Update nicht automatisch |
| Zugehörige Managed Services (Datenbank, Speicher, Registry) | Umfang im STACKIT-Katalog gegen Ihren Bedarf prüfen | Selbst zu betreiben oder zuzukaufen | Sehr breites Angebot |
| GPU-Workloads | GPU-Node-Pools dokumentiert (NVIDIA GPU Operator, Ubuntu-Node-Pools); Verfügbarkeit und Modelle prüfen | Abhängig von der eigenen Hardware | GPU-Nodes dokumentiert (EKS: beschleunigte AMIs für NVIDIA-GPU-Instanzen, Device-Plugin bzw. DRA-Treiber je nach Variante separat zu installieren, AKS, GKE); Kontingente und regionale Verfügbarkeit prüfen |
| Exit-Fähigkeit | Gut, wenn Sie bei Standard-Kubernetes und IaC bleiben; proprietäre Dienste erhöhen die Bindung | Hoch: Sie besitzen die Plattform | Gut für Kubernetes selbst; Bindung entsteht durch angrenzende proprietäre Dienste |
| Betriebsaufwand für Ihr Team | Mittel | Hoch | Mittel |
| Kostenlogik | Verbrauchsbasiert; Preise der Anbieter prüfen | Investition in Hardware und Betriebspersonal; planbar bei hoher, stabiler Last | Verbrauchsbasiert; Datenabfluss und Zusatzdienste beachten |
| Passt besonders, wenn … | Datenstandort Europa und wenig Eigenbetrieb gewünscht sind | Volle Kontrolle, bestehende Virtualisierungsplattform oder Air-Gap gefordert sind | Breite Managed-Service-Palette oder bestehende Hyperscaler-Landschaft vorhanden |
04Entscheidungsweg
So lesen wir die Matrix in der Praxis
Erst die harten Ausschlusskriterien (Datenstandort, Air-Gap, Vertragsbindung), dann Betriebsaufwand gegen Kontrolle, zuletzt die angrenzenden Dienste.
05Selbstbetrieb
Eigener Cluster: Standarddistribution oder Talos Linux
Wer die Control Plane selbst betreibt, gewinnt Kontrolle und bezahlt mit Betriebsarbeit. Der Cluster ist dabei selten das Problem; Datenbanken, Speicher, Identität und Netz entscheiden oft die Plattform.
Auf eigener Infrastruktur setzen wir je nach Anforderung auf eine Standarddistribution oder auf ein minimalistisches, API-gesteuertes Betriebssystem wie Talos Linux. Das reduziert die Angriffsfläche, verlangt aber ein Team, das diesen Betriebsstil trägt.
Zugriff auf den Cluster: Ihre Identitäten, minimale Rechte
Der Zugriff auf den Cluster hängt an Ihrer Identitätsverwaltung und folgt dem Prinzip der minimalen Rechte, mit Rollen je Team und Namensraum statt geteilter Administrator-Kubeconfigs. So bleibt nachvollziehbar, wer was im Cluster darf.
Cloud Security06Eingaben
Was wir von Ihnen brauchen, damit die Empfehlung konkret wird
Ohne diese Eingaben bleibt jede Clusterempfehlung generisch.
- Liste der Workloads: zustandslos oder zustandsbehaftet, Last, Abhängigkeiten, Datenbanken
- Anforderungen an Verfügbarkeit und Datenstandort
- Vorhandene Pipelines
- Vorhandene Identitätsverwaltung
- Skills im Team
- Wer später Cluster-Updates verantwortet
07
Kubernetes ja oder nein: Wo wir Ihnen davon abraten
Ein Assessment endet nicht automatisch mit einem Cluster. Das sagen wir Ihnen auch.
Dann lohnt die Beratung
- Mehrere Workloads, die Plattformbetrieb, Rechtekonzept und Wiederanlauf brauchen.
- Eine Plattformentscheidung zwischen verwaltetem Dienst und Eigenbetrieb steht an.
- Es gibt einen fachlichen Ansprechpartner für Anforderungen.
Dann ist etwas anderes besser
- Eine einzelne, einfache Anwendung: virtuelle Maschinen oder ein Platform-as-a-Service sind oft die bessere Antwort.
- Ihr Team soll Kubernetes ohne Lernaufwand „nebenbei“ betreiben: Wir übergeben sauber, aber Betrieb braucht Verantwortliche. Alternativ Managed Kubernetes.
- Sie suchen reines Training: dafür gibt es GoldenKube, ein separates Produkt.
08Abgrenzung
Wo die Plattformberatung endet
Umfang der Beratung ist die Plattform. Anwendungslogik und Fachdaten verändern wir nicht ohne eigenen Auftrag.
-
Härtung vertiefen
Sicherheitsvertiefung ist eigener Umfang.
-
Supply Chain absichern
Pipeline- und Lieferkettensicherheit ist eigener Umfang.
09
Häufige Fragen
Wie legt SKAFFON den Aufwand und das Angebot fest?
Den Aufwand bestimmen die Zahl der Cluster und Umgebungen, die Zahl und Komplexität der Workloads, die Anforderungen an Sicherheit und Wiederanlauf, die Integration in Pipelines und Identität sowie der Anteil von Beratung, Umsetzung und Schulung. Das Angebot beschreibt Umfang, Preismodell und die Ergebnisse je Phase.
Mit welchen Plattformen arbeitet SKAFFON?
Mit STACKIT Kubernetes Engine (SKE), selbst betriebenem Kubernetes auf Proxmox sowie mit EKS, AKS und GKE. Die Wahl begründen wir anhand der Entscheidungsmatrix auf dieser Seite.
Kann SKAFFON den Betrieb auch übernehmen?
Ja. Wenn Ihr Team den Clusterbetrieb nicht selbst tragen soll, ist Managed Kubernetes der passende Weg; Beratung und Betrieb lassen sich getrennt oder zusammen beauftragen.
Beschreiben Sie Ihre Workloads
Nennen Sie uns Workloads und Randbedingungen; wir melden uns mit einem Vorschlag für Assessment und Vorgehen.