Dicht verkabelte Serverschränke in grünlich beleuchtetem, dunklem Rechenzentrum

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.
Schwarzweiß-Aufnahme eines Schranks mit ungeordnet verlegten Kabeln und Geräten

02Vorgehen

Vom Workload-Inventar zur übergebenen Plattform

Sechs Schritte, jeder mit einem greifbaren Ergebnis.

  1. 01

    Workload-Assessment

    Ergebnis: Zuordnung je Workload

    Wir 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).

  2. 02

    Architektur

    Ergebnis: Zielarchitektur

    Clusterzuschnitt (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.

  3. 03

    Cluster-Auswahl

    Ergebnis: Entscheidungsvorlage

    Entscheidung zwischen den Betriebsmodellen anhand der Matrix unten, dokumentiert als Entscheidungsvorlage.

  4. 04

    Betriebskonzept

    Ergebnis: Betriebsregeln

    Upgrade-Strategie, Backup und Wiederherstellung, Observability, Kapazitäts- und Kostensteuerung, Zuständigkeiten.

  5. 05

    Implementierung

    Ergebnis: Cluster als Code

    Provisionierung der Cluster als Infrastructure as Code, Basiskonfiguration (Netzwerkrichtlinien, Zugriffsmodell, Secrets-Handling, Ressourcenlimits), Anbindung an CI/CD und GitOps.

  6. 06

    Validierung und Übergabe

    Ergebnis: Runbooks, Einweisung

    Funktionstests, 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.

Bewertungsraster für Kubernetes-Betriebsmodelle, Stand 13.11.2026
KriteriumSTACKIT SKEEigenes Kubernetes auf ProxmoxEKS / 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-ServersSie oder ein Betriebspartner (z. B. SKAFFON)Anbieter
Wer betreibt Worker und Hardware?Node Pools bei STACKIT; Betrieb der Workloads bei IhnenVollständig Sie: Hardware, Virtualisierung, Netz, SpeicherAnbieter für Infrastruktur; Betrieb der Workloads bei Ihnen
Datenstandort und BetreiberkontrolleRegionen und vertragliche Zusagen im STACKIT-Vertrag prüfenMaximal: Standort, Zugriff und Schlüssel bleiben bei IhnenRegion je Dienst festzulegen, Verfügbarkeit je Region verschieden: EKS, AKS, GKE. Rechts- und Zugriffsfragen des Anbieterkonzerns separat bewerten
Updates und ReparaturAutomatische 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 einplanenVollständig in Ihrer Hand; höchster BetriebsaufwandJe 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üfenSelbst zu betreiben oder zuzukaufenSehr breites Angebot
GPU-WorkloadsGPU-Node-Pools dokumentiert (NVIDIA GPU Operator, Ubuntu-Node-Pools); Verfügbarkeit und Modelle prüfenAbhängig von der eigenen HardwareGPU-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ähigkeitGut, wenn Sie bei Standard-Kubernetes und IaC bleiben; proprietäre Dienste erhöhen die BindungHoch: Sie besitzen die PlattformGut für Kubernetes selbst; Bindung entsteht durch angrenzende proprietäre Dienste
Betriebsaufwand für Ihr TeamMittelHochMittel
KostenlogikVerbrauchsbasiert; Preise der Anbieter prüfenInvestition in Hardware und Betriebspersonal; planbar bei hoher, stabiler LastVerbrauchsbasiert; Datenabfluss und Zusatzdienste beachten
Passt besonders, wenn …Datenstandort Europa und wenig Eigenbetrieb gewünscht sindVolle Kontrolle, bestehende Virtualisierungsplattform oder Air-Gap gefordert sindBreite Managed-Service-Palette oder bestehende Hyperscaler-Landschaft vorhanden

Zur Proxmox-Seite: Proxmox; zur STACKIT-Seite: STACKIT.

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.

Entscheidungsweg der Kubernetes-Beratung Workloads werden geprüft, harte Kriterien streichen Betriebsmodelle, dann wird zwischen STACKIT SKE, Proxmox und EKS/AKS/GKE abgewogen. 1 · ASSESSMENT2 · AUSSCHLUSS3 · ABWÄGUNG4 · VORLAGE Welche Workloadsgehören auf K8s? Datenstandort, Air-Gap,Vertragsbindung Betriebsaufwand gegenKontrolle, dann Dienste Entscheidung mitAnnahmen, Exit-Weg Vom Workload zur Plattformentscheidung STACKIT SKEEigenes K8s auf ProxmoxEKS / AKS / GKE Control Plane beim AnbieterDatenstandort EuropaBetriebsaufwand: mittel Volle Kontrolle, Air-Gap möglichHardware und Betrieb bei IhnenBetriebsaufwand: hoch Breite Managed-Service-PaletteBestehende Hyperscaler-LandschaftBetriebsaufwand: mittel Bewertungsraster, keine Rangliste: Die Gewichtung Ihrer Kriterien entscheidet.
Das Ergebnis wird als Entscheidungsvorlage festgehalten, mit den getroffenen Annahmen und der Begründung.
Entscheidungsweg der Kubernetes-Beratung Workloads werden geprüft, harte Kriterien streichen Betriebsmodelle, dann wird zwischen STACKIT SKE, Proxmox und EKS/AKS/GKE abgewogen. Vom Workload zurPlattformentscheidung 1 · ASSESSMENT2 · AUSSCHLUSS3 · ABWÄGUNG4 · VORLAGE Welche Workloadsgehören auf K8s?Datenstandort, Air-Gap,VertragsbindungBetriebsaufwand gegenKontrolle, dann DiensteEntscheidung mitAnnahmen, Exit-Weg STACKIT SKEEigenes K8s auf ProxmoxEKS / AKS / GKE Control Plane beim AnbieterDatenstandort EuropaBetriebsaufwand: mittelVolle Kontrolle, Air-Gap möglichHardware und Betrieb bei IhnenBetriebsaufwand: hochBreite Managed-Service-PaletteBestehende Hyperscaler-LandschaftBetriebsaufwand: mittel Bewertungsraster, keine Rangliste: DieGewichtung Ihrer Kriterien entscheidet.
Das Ergebnis wird als Entscheidungsvorlage festgehalten, mit den getroffenen Annahmen und der Begründung.

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.

Draufsicht auf einen Holztisch mit mehreren Laptops, Notizbüchern und Händen bei der Arbeit

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 Security

06Eingaben

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.

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.