Kubernetes-Wissen aufbauen trotz Managed Service: So vermeiden Sie Abhaengigkeit

TL;DR

• Ein Managed Service nimmt Ihnen den Betrieb ab, aber er darf Ihnen nicht das Verstaendnis abnehmen
• Ohne internes Kubernetes-Wissen sind Sie bei Providerwechsel, Eskalation oder strategischen Entscheidungen hilflos
• Ein strukturiertes Wissensaufbau-Programm kostet ca. 2-4 Stunden pro Woche und Person -- das ist machbar neben dem Tagesgeschaeft
• Shadowing-Sessions, dokumentierte Runbooks und quartalsweise Wissenstransfers muessen Vertragsbestandteil sein
• Ziel ist nicht, den Provider zu ersetzen, sondern ein informierter Auftraggeber zu sein

Warum internes Wissen trotzdem wichtig ist

Sie haben einen Managed Service fuer Ihren Kubernetes-Betrieb beauftragt. Die Cluster laufen, das Monitoring ist gruen, die SLAs werden eingehalten. Warum sollten Sie sich trotzdem mit Kubernetes beschaeftigen?

Drei Szenarien zeigen, warum:

Szenario 1: Der Provider kuendigt. Ihr Managed-Service-Provider wird aufgekauft, stellt den Service ein oder erhoeht die Preise um 80%. Sie muessen innerhalb von 3 Monaten wechseln. Wenn niemand in Ihrem Team Kubernetes versteht, wird diese Migration zum Albtraum.

Szenario 2: Freitagabend, 22 Uhr. Der Provider hat einen Severity-1-Incident, aber es betrifft Ihre Applikation, nicht die Infrastruktur. Der Provider sagt: "Die Pods laufen, das Problem liegt in Ihrem Code." Wenn niemand bei Ihnen ein kubectl-Kommando ausfuehren kann, stehen Sie hilflos da.

Szenario 3: Die strategische Entscheidung. Ihre Geschaeftsfuehrung fragt: "Sollen wir auf Multi-Cloud setzen? Was kostet das? Was aendert sich?" Wenn Ihr IT-Leiter diese Frage nicht einschaetzen kann, entscheidet der Provider -- und dessen Interessen sind nicht Ihre.

Internes Wissen ist keine Redundanz zum Provider. Es ist die Voraussetzung, um ein kompetenter Auftraggeber zu sein.

Das Kompetenzstufenmodell

Nicht jeder in Ihrem Team muss ein Kubernetes-Experte werden. Aber verschiedene Rollen brauchen verschiedene Wissensstufen:

Fuer ein Mittelstandsunternehmen mit 300-1000 Mitarbeitern empfehlen wir:

• 2-3 Personen auf Stufe 2 (User)
• 1 Person auf Stufe 3 (Operator)
• IT-Leitung auf Stufe 1 (Awareness)

Das ist ausreichend, um kompetent mit dem Provider zu arbeiten und im Notfall handlungsfaehig zu sein.

Baustein 1: Strukturiertes Training

Trainingsplan fuer Ihr Team

# kubernetes-trainingsplan-managed-service.yaml
# 6-Monats-Plan fuer internes Wissensaufbau-Programm

monat_1_2_grundlagen:
  themen:
    - "Container-Grundlagen (Docker, Images, Registry)"
    - "Kubernetes-Architektur (Control Plane, Worker Nodes)"
    - "Kernkonzepte (Pods, Deployments, Services, Namespaces)"
    - "kubectl: Die 20 wichtigsten Befehle"
  format: "Online-Kurs (z.B. KodeKloud, Udemy) + woechentliche Praxis-Session"
  zeitaufwand: "2h/Woche pro Person"
  meilenstein: "Jeder kann Pods listen, Logs lesen, Deployments beschreiben"

monat_3_4_praxis:
  themen:
    - "Eigene App deployen (Deployment + Service + Ingress)"
    - "ConfigMaps und Secrets verstehen"
    - "Monitoring-Dashboards lesen und interpretieren"
    - "Troubleshooting: CrashLoopBackOff, ImagePullBackOff, OOMKilled"
  format: "Hands-on Labs in der Staging-Umgebung"
  zeitaufwand: "3h/Woche pro Person"
  meilenstein: "Jeder kann eine App eigenstaendig deployen und debuggen"

monat_5_6_vertiefung:
  themen:
    - "Helm Charts lesen und anpassen"
    - "RBAC verstehen (wer darf was)"
    - "Network Policies Grundlagen"
    - "Backup und Restore verstehen"
  format: "Shadowing beim Provider + interne Workshops"
  zeitaufwand: "3h/Woche pro Person"
  meilenstein: "Operator-Level fuer mindestens 1 Person"

optional_zertifizierung:
  empfehlung: "CKAD (Certified Kubernetes Application Developer)"
  kosten: "395 USD pro Pruefung"
  vorbereitung: "ca. 40-60 Stunden"
  wert: "Nachweisbare Kompetenz, motivierend fuer das Team"

Kosten des Trainingsprogramms

Das klingt nach viel. Aber vergleichen Sie es mit den Kosten eines Provider-Wechsels ohne internes Wissen: 50.000-100.000 EUR fuer externe Berater, die Ihren Cluster verstehen muessen. Die Details dieser Rechnung finden Sie im Kostenvergleich Kubernetes Team aufbauen.

Baustein 2: Shadowing beim Provider

Shadowing bedeutet: Ihr Team schaut dem Provider bei der Arbeit ueber die Schulter. Nicht um zu kontrollieren, sondern um zu lernen.

Shadowing-Modell

Shadowing als Vertragsbestandteil

Dieser Punkt ist entscheidend: Shadowing muss im Vertrag stehen. Sonst passiert es nicht.

Vertragsklausel Wissenstransfer (Mustertext):

Der Provider verpflichtet sich zu folgenden Wissenstransfer-Massnahmen:

1. Incident Shadowing
   Der Auftraggeber hat das Recht, bei allen Incidents der
   Severity 1 und 2 in Echtzeit zugeschaltet zu werden.
   Der Provider erlaeutert Diagnose und Loesung.

2. Monatliche Shadowing-Sessions
   Der Provider fuehrt mindestens 2 Shadowing-Sessions pro
   Monat durch (je 1-2 Stunden), in denen interne Engineers
   des Auftraggebers bei operativen Taetigkeiten zuschauen
   und Fragen stellen koennen.

3. Quartalsweiser Wissenstransfer-Workshop
   Der Provider fuehrt quartalsweise einen halbtaegigen
   Workshop durch, der aktuelle Architekturentscheidungen,
   Aenderungen und Best Practices behandelt.

4. Dokumentationspflicht
   Alle Konfigurationsaenderungen, Incident-Loesungen und
   Architekturentscheidungen werden in einer gemeinsamen
   Wissensdatenbank dokumentiert.

Baustein 3: Dokumentationsanforderungen

Dokumentation ist der Wissenstransfer, der auch dann funktioniert, wenn Menschen nicht verfuegbar sind.

Was dokumentiert sein muss

# Dokumentations-Checkliste pruefen
# Fuehren Sie dieses Review quartalsweise durch

# 1. Cluster-Architektur
# Gibt es ein aktuelles Architektur-Diagramm?
ls docs/architecture/
# Erwartet: cluster-topology.md, network-architecture.md,
#           component-diagram.md

# 2. Runbooks (Schritt-fuer-Schritt-Anleitungen)
ls docs/runbooks/
# Erwartet:
#   incident-response.md
#   node-failure-recovery.md
#   deployment-rollback.md
#   certificate-renewal.md
#   backup-restore.md
#   scaling-procedures.md

# 3. Entscheidungsprotokolle (ADRs)
ls docs/adr/
# Erwartet: Fuer jede groessere Entscheidung ein ADR
#   001-ingress-controller-auswahl.md
#   002-monitoring-stack-design.md
#   003-backup-strategie.md

# 4. Zugangsdokumentation
ls docs/access/
# Erwartet:
#   kubeconfig-management.md
#   service-account-uebersicht.md
#   rbac-konzept.md

Dokumentationsqualitaet pruefen

Baustein 4: Knowledge Transfer bei Vertragsende

Der wichtigste Wissenstransfer passiert am Ende. Leider wird er am haeufigsten vernachlaessigt, weil zu diesem Zeitpunkt die Motivation auf beiden Seiten gering ist.

Exit-Wissenstransfer-Plan

Was bei Vertragsende uebergeben werden muss

Baustein 5: Vendor-Abhaengigkeit aktiv vermeiden

Wissensaufbau allein reicht nicht. Sie muessen auch technische Abhaengigkeiten minimieren.

Abhaengigkeits-Check

Fuer jedes "Ja" muessen Sie einen Mitigationsplan haben. Im Idealfall sind alle diese Punkte unter Ihrer Kontrolle, und der Provider hat nur Zugriffsrechte darauf.

Mehr zu diesem Thema finden Sie unter Kubernetes Vendor Lock-in und Cloud Exit.

Praxisbeispiel: 12-Monats-Wissensaufbau-Plan

So koennte ein realistischer Plan fuer ein Mittelstandsunternehmen aussehen:

MONAT 1-3: GRUNDLAGEN
├── 2 Personen starten Online-Kurs (2h/Woche)
├── IT-Leitung nimmt an Kubernetes-Awareness-Workshop teil (4h)
├── Erste Shadowing-Session beim Provider
└── Meilenstein: Team kann Pods listen, Logs lesen, Dashboards verstehen

MONAT 4-6: HANDS-ON
├── Hands-on Labs in Staging-Umgebung
├── Monatliches Incident-Shadowing laeuft
├── Dokumentations-Review (erste Iteration)
├── Erste eigene Deployments in Staging
└── Meilenstein: Team kann Apps eigenstaendig deployen

MONAT 7-9: VERTIEFUNG
├── 1 Person beginnt Operator-Training
├── Helm Charts anpassen und verstehen
├── RBAC und Network Policies verstehen
├── Erster interner "Game Day" (simulierter Ausfall)
└── Meilenstein: 1 Person kann Basis-Betrieb uebernehmen

MONAT 10-12: KONSOLIDIERUNG
├── CKAD-Pruefung fuer 1 Person (optional)
├── Vollstaendiges Dokumentations-Review
├── Break-Glass-Verfahren testen
├── Zweiter Game Day (komplexeres Szenario)
└── Meilenstein: Team ist handlungsfaehig bei Providerwechsel

LAUFEND AB MONAT 13:
├── 2h/Woche Weiterbildung pro Person
├── Monatliches Shadowing beim Provider
├── Quartalweise Wissenstransfer-Workshops
└── Jaehrlicher Game Day

Die haeufigsten Fehler

Fazit

Ein Managed Service befreit Sie vom operativen Kubernetes-Betrieb -- aber er darf Sie nicht vom Kubernetes-Verstaendnis befreien. Die Investition in internes Wissen ist keine Redundanz zum Provider. Sie ist die Grundlage fuer drei Dinge:

1. Kompetente Steuerung: Sie koennen den Provider bewerten, hinterfragen und steuern.
2. Handlungsfaehigkeit im Notfall: Bei Eskalationen oder Providerwechsel stehen Sie nicht im Dunkeln.
3. Strategische Unabhaengigkeit: Architekturentscheidungen treffen Sie, nicht Ihr Provider.

Der Aufwand dafuer ist ueberschaubar: 2-4 Stunden pro Woche und Person, verteilt auf 6-12 Monate. Das ist weniger als ein Prozent Ihrer Teamkapazitaet. Die Alternative -- blinde Abhaengigkeit von einem einzelnen Dienstleister -- kostet im Ernstfall das Hundertfache.

Mehr zur Komplexitaet von Kubernetes und warum Wissensaufbau so wichtig ist, finden Sie unter Kubernetes Komponenten und Komplexitaet.

Verwandte Artikel

• Kubernetes-Betrieb auslagern oder selbst machen?
• Kubernetes Team aufbauen: Was es wirklich kostet
• Kubernetes Vendor Lock-in und Cloud Exit
• Kubernetes Managed Service vs. Inhouse Vergleich
• Kubernetes Komponenten und Komplexitaet

Sie nutzen einen Managed Service und moechten sicherstellen, dass Ihr Team trotzdem kompetent bleibt? Wir helfen Ihnen, ein praxistaugliches Wissensaufbau-Programm aufzusetzen -- abgestimmt auf Ihre Teamgroesse und Ihren Provider. Sprechen Sie mit uns.