Handbuch

Etablieren Sie das Kernprinzip für ein Plattformteam, um die Akzeptanz sicherzustellen und die Entwicklerreibung zu reduzieren.

→Behandeln Sie die interne Plattform als Produkt. Betrachten Sie interne Entwickler als Kunden, führen Sie Benutzerforschung durch, sammeln Sie Feedback und iterieren Sie Funktionen, um deren kognitive Belastung zu reduzieren.

Warum: Diese Denkweise verlagert den Fokus vom Aufbau von Infrastruktur auf die Wertschöpfung und stellt sicher, dass die Plattform echte Entwicklerprobleme löst und nicht umgangen wird ("Schatten-IT").

Etablieren Sie eine einzige Quelle der Wahrheit für den gewünschten Zustand aller Infrastruktur und Anwendungen.

→Verwenden Sie Git-Repositories als einzige Quelle der Wahrheit. Stellen Sie einen In-Cluster-Agenten (ArgoCD, Flux) bereit, der eine kontinuierliche Abgleichschleife ausführt, um den Clusterzustand mit Git zu vergleichen.

Warum: Dies bietet eine vollständige Prüfspur, ermöglicht einfache Rollbacks und verhindert Konfigurationsdrifts durch automatische Rückgängigmachung von Out-of-Band-Änderungen.

Referenz↗

Verhindern Sie Konfigurationsdrift und stellen Sie die Konsistenz der bereitgestellten Artefakte in allen Umgebungen sicher.

→Behandeln Sie Infrastruktur als unveränderlich. Modifizieren Sie niemals laufende Ressourcen. Erstellen Sie stattdessen neue, versionierte Artefakte (Container-Images, VM-Images) und ersetzen Sie die alten. Erzwingen Sie dies mit schreibgeschützten Container-Dateisystemen (`readOnlyRootFilesystem: true`).

Warum: Unveränderlichkeit eliminiert Konfigurationsdrift und macht Bereitstellungen vorhersehbar und wiederholbar. "Ersetzen, nicht reparieren."

Wählen Sie ein sicheres GitOps-Bereitstellungsmodell, insbesondere in Multi-Cluster- oder eingeschränkten Netzwerkumgebungen.

→Implementieren Sie ein Pull-basiertes Modell. Ein im Cluster laufender Agent (ArgoCD, Flux) zieht Manifeste aus Git. Vermeiden Sie Push-basierte Modelle, bei denen ein externes CI-System an die Kubernetes-API pusht.

Warum: Pull-basierte Modelle sind sicherer, da sie weder das externe Freilegen des Kubernetes API-Servers noch die Verwaltung von Anmeldeinformationen für mehrere Cluster in CI erfordern.

Beschleunigen Sie die Entwicklung und stellen Sie Best Practices sicher, ohne erfahrene Teams übermäßig einzuschränken.

→Definieren Sie "Golden Paths" (oder befestigte Wege): vorkonfigurierte, gut unterstützte Vorlagen und Workflows für gängige Aufgaben (z.B. die Erstellung eines neuen Microservice).

Warum: Golden Paths reduzieren die kognitive Belastung und Entscheidungsermüdung für 80% der Fälle, sollten aber dennoch "Auswege" für Expertenteams mit einzigartigen Anforderungen zulassen.

Bieten Sie Multi-Tenancy auf einer geteilten Kubernetes-Plattform mit geeigneten Isolationsstufen an.

→Für die stärkste Isolation verwenden Sie separate Cluster. Für ein Gleichgewicht zwischen starker Isolation und Effizienz verwenden Sie virtuelle Cluster (vClusters). Für grundlegende, weiche Multi-Tenancy verwenden Sie Isolation auf Namespace-Ebene mit RBAC, NetworkPolicies und ResourceQuotas.

Warum: Die Wahl hängt vom Sicherheits- und "Noisy Neighbor"-Risiko ab. Virtuelle Cluster bieten Control Plane-Isolation ohne die Kosten vollständiger physischer Cluster.

Definieren Sie den primären Interaktionsmodus zwischen dem Plattformteam und den stream-aligned (Produkt-)Teams.

→Das Plattformteam sollte primär im "X-as-a-Service"-Modus agieren und Self-Service-Tools, APIs und Dokumentation bereitstellen.

Warum: In großem Maßstab kann ein Plattformteam kein High-Touch-Kollaborationsmodell mit jedem Team verwenden. Das As-a-Service-Modell ermöglicht Skalierung und Entwicklerautonomie.

Implementieren Sie eine umfassende Observability-Strategie für ein verteiltes System.

→Sammeln und korrelieren Sie die drei Säulen: Metriken (numerische Zeitreihendaten über Prometheus), Logs (strukturierte Ereignisse über Fluent Bit) und Traces (Anfrageflüsse über OpenTelemetry).

Warum: Keine einzelne Säule ist ausreichend. Deren Korrelation (z.B. das Einbetten von Trace IDs in Logs) ist unerlässlich, um Probleme in komplexen Microservice-Architekturen schnell zu diagnostizieren.

Setzen Sie Sicherheits- und Organisationsrichtlinien in allen Kubernetes-Clustern automatisch durch.

→Verwenden Sie eine Policy Engine wie OPA/Gatekeeper oder Kyverno, integriert als Validating/Mutating Admission Controller. Speichern Sie Richtlinien in Git und synchronisieren Sie sie über GitOps.

Warum: Dies bietet automatisierte, präventive Schutzmaßnahmen und gibt Entwicklern schnelles Feedback in ihrer CI/CD-Pipeline anstatt langsamer, manueller Überprüfungsschranken.

Wählen Sie eine Policy Engine für Kubernetes basierend auf den Team-Fähigkeiten und der Richtlinienkomplexität aus.

→Verwenden Sie Kyverno für Richtlinien, die im bekannten Kubernetes-ähnlichen YAML ausgedrückt werden können. Verwenden Sie OPA/Gatekeeper für komplexe Richtlinien, die eine mächtigere, speziell entwickelte Sprache (Rego) und externe Datenintegration erfordern.

Warum: Kyverno hat eine geringere Lernkurve für Kubernetes-Praktizierende. OPA/Rego ist mächtiger, erfordert aber das Erlernen einer neuen Sprache.

Stellen Sie die Integrität und Authentizität von Container-Images sicher, die in Produktion bereitgestellt werden.

→Implementieren Sie das Signieren von Images in der CI-Pipeline mit Sigstore/Cosign. Verwenden Sie einen Policy Controller (Kyverno, Gatekeeper), um eine Admission Policy zu erstellen, die Image-Signaturen überprüft, bevor die Erstellung eines Pods zugelassen wird.

Warum: Dies stellt sicher, dass nur Images, die von vertrauenswürdigen CI-Pipelines erstellt wurden und nicht manipuliert wurden, im Cluster ausgeführt werden können, wodurch die Ausführung von nicht autorisiertem Code verhindert wird.

Referenz↗

Sichern Sie die gesamte Service-to-Service-Kommunikation innerhalb des Clusters mit einem Zero-Trust-Ansatz.

→Stellen Sie ein Service Mesh (z.B. Istio, Linkerd) bereit und aktivieren Sie strenges Mutual TLS (mTLS) für den gesamten In-Mesh-Verkehr.

Warum: mTLS bietet sowohl Verschlüsselung während der Übertragung als auch eine starke, kryptografisch überprüfbare Identität für Client und Server, wodurch Spoofing- und Man-in-the-Middle-Angriffe innerhalb des Clusters verhindert werden.

Setzen Sie Sicherheits-Best-Practices für alle Workloads durch, die im Cluster laufen.

→Aktivieren Sie den integrierten Pod Security Admission Controller. Konfigurieren Sie Namespaces, um das `restricted`-Profil für Workloads und `baseline` für Plattformkomponenten durchzusetzen.

Warum: Das `restricted`-Profil erzwingt kritische Sicherheitsverbesserungen (z.B. als Nicht-Root ausführen, alle Capabilities entfernen, Privilegienerhöhung verbieten) und ist eine grundlegende Sicherheitsmaßnahme.

Referenz↗

Erkennen Sie anomales oder bösartiges Verhalten innerhalb laufender Container auf Betriebssystemebene.

→Stellen Sie ein Laufzeit-Sicherheitstool bereit, das eBPF verwendet, wie Falco oder Tetragon. Definieren Sie Regeln, um verdächtige Systemaufrufe, Dateizugriffe und Prozessausführungen zu erkennen.

Warum: Traditionelle Sicherheitstools sind blind für Aktivitäten innerhalb von Containern. eBPF bietet tiefe, ressourcenschonende Einblicke in Kernel-Ebene-Ereignisse und ermöglicht die Erkennung von Bedrohungen, die andere Tools übersehen.

Bauen Sie eine skalierbare und resiliente Observability-Datenpipeline auf.

→Verwenden Sie den OpenTelemetry (OTel) Collector. Verketten Sie Prozessoren, um Daten zu transformieren (z.B. den `attributes`-Prozessor zum Entfernen von PII, den `batch`-Prozessor für Effizienz). Verwenden Sie den `memory_limiter`-Prozessor frühzeitig in der Pipeline, um OOMs zu verhindern.

Warum: Der Collector entkoppelt die Instrumentierung von Backends und bietet eine flexible, herstellerunabhängige Möglichkeit, Telemetriedaten vor dem Export zu verarbeiten, zu filtern und zu routen.

Referenz↗

Stellen Sie neue Anwendungsversionen in der Produktion bereit, während Sie Risiko und Explosionsradius minimieren.

→Implementieren Sie automatisierte Canary Deployments mit einem Tool wie Flagger oder Argo Rollouts. Verlagern Sie den Traffic schrittweise auf die neue Version, während wichtige Metriken (Erfolgsrate, Latenz) automatisch analysiert werden. Führen Sie bei SLO-Verletzungen automatisch einen Rollback durch.

Warum: Die automatisierte Canary-Analyse validiert neue Versionen mit echtem Produktionstraffic und bietet ein wesentlich höheres Maß an Sicherheit als einfache Rolling Updates.

Stellen Sie eine neue Version einer Anwendung bereit mit der Möglichkeit, einen sofortigen Rollback durchzuführen.

→Pflegen Sie zwei identische Produktionsumgebungen ("blau" und "grün"). Stellen Sie die neue Version in der inaktiven (grünen) Umgebung bereit. Nach der Validierung schalten Sie den Load Balancer um, um den gesamten Traffic auf grün zu leiten. Halten Sie blau im Leerlauf für einen sofortigen Rollback.

Warum: Dieses Muster bietet Zero-Downtime-Bereitstellungen und den schnellstmöglichen Rollback, erfordert aber typischerweise doppelte Infrastrukturressourcen.

Verwalten Sie Geheimnisse deklarativ in einem GitOps-Workflow, ohne Klartext-Anmeldeinformationen in Git zu speichern.

→Verwenden Sie einen dedizierten Secrets Operator. Entweder verschlüsseln Sie Geheimnisse vor dem Commit (Bitnami Sealed Secrets, Mozilla SOPS) oder referenzieren Sie Geheimnisse aus einem externen Vault (External Secrets Operator).

Warum: Dies hält sensible Daten aus Git fern, während Geheimnisse deklarativ zusammen mit der Anwendungskonfiguration verwaltet werden können, wodurch der GitOps-Workflow aufrechterhalten wird.

Verwalten Sie Anwendungskonfigurationen über mehrere Umgebungen (Dev, Staging, Prod) ohne Duplizierung.

→Verwenden Sie ein Tool wie Kustomize mit einer Basis- und Overlay-Struktur oder Helm mit umgebungsspezifischen Values-Dateien. Promoten Sie Änderungen, indem Sie Image-Tags oder die Konfiguration in der Overlay-/Values-Datei der Zielumgebung aktualisieren, typischerweise über einen Pull Request.

Warum: Dieser "Don't Repeat Yourself" (DRY)-Ansatz verhindert Konfigurationsdrifts zwischen Umgebungen und macht Unterschiede explizit und auditierbar.

Verwalten Sie die Bereitstellungen derselben Anwendung über eine große, dynamische Flotte von Clustern hinweg.

→Verwenden Sie ArgoCD ApplicationSets mit einem Cluster-Generator. Der Generator entdeckt Cluster dynamisch basierend auf Labels und verwendet eine Vorlage, um eine Application-Ressource für jeden passenden Cluster zu generieren.

Warum: Dies automatisiert das Anwendungs-Bootstrapping für neue Cluster und verwaltet die Konfiguration in großem Maßstab, wodurch die Notwendigkeit entfällt, Hunderte von Application-Ressourcen manuell zu erstellen.

Referenz↗

Ermöglichen Sie die kontinuierliche Bereitstellung in der Produktion, während Sie die Freigabe neuer Funktionen für Benutzer steuern.

→Integrieren Sie ein Feature-Flagging-System. Stellen Sie neuen Code hinter einem deaktivierten Feature Flag in der Produktion bereit. Geben Sie die Funktion frei, indem Sie das Flag für bestimmte Benutzersegmente aktivieren, wodurch die Bereitstellung von der Freigabe entkoppelt wird.

Warum: Dies trennt technisches Risiko (Bereitstellung) von Geschäftsrisiko (Freigabe) und ermöglicht High-Velocity-Bereitstellungen, A/B-Tests und "Kill Switch"-Funktionen.

Automatisches Bereitstellen neuer Container-Images, sobald diese in ein Registry gepusht werden.

→Verwenden Sie die Image Automation-Komponenten von FluxCD. Das `ImageRepository` scannt das Registry, die `ImagePolicy` wählt das neue Tag aus (z.B. basierend auf SemVer), und die `ImageUpdateAutomation` committet die Tag-Änderung zurück in das Git-Repository.

Warum: Dies schließt den Kreis von CI (Image Push) zu CD (Deployment) für einen vollautomatisierten GitOps-Workflow, ohne dass das CI-System Zugriff auf den Cluster benötigt.

Bieten Sie eine vereinheitlichte, deklarative API für Entwickler, um Kubernetes- und Cloud-Infrastrukturressourcen (z.B. Datenbanken, Message Queues) im Self-Service-Verfahren bereitzustellen.

→Verwenden Sie Crossplane. Installieren Sie Cloud-Provider-Plugins und definieren Sie High-Level CompositeResourceDefinitions (XRDs) für Entwickler (z.B. `kind: PostgresSQLInstance`). Ordnen Sie diese mithilfe von Compositions den zugrunde liegenden Cloud-Ressourcen zu.

Warum: Dies erweitert die Kubernetes-Steuerebene zur Verwaltung externer Ressourcen, wodurch Entwickler vertraute `kubectl`- und GitOps-Workflows für alle ihre Anwendungsabhängigkeiten nutzen können, gesteuert durch plattformdefinierte Muster.

Referenz↗

Automatisieren Sie das komplexe Lebenszyklusmanagement zustandsbehafteter Anwendungen (z.B. Installation, Upgrades, Backups, Fehlerbehebung) auf Kubernetes-native Weise.

→Erstellen Sie einen Kubernetes Operator. Definieren Sie eine Custom Resource Definition (CRD) für Ihre Anwendung und implementieren Sie einen benutzerdefinierten Controller, der eine Reconciliation Loop ausführt, um den Zustand der Anwendung zu verwalten.

Warum: Operatoren kodieren menschliches operatives Wissen in Software, ermöglichen eine robuste Automatisierung und behandeln komplexe Anwendungen als erstklassige Kubernetes-Ressourcen.

Stellen Sie sicher, dass ein Operator die Bereinigung externer Ressourcen (z.B. ein Cloud-Load Balancer) durchführen kann, bevor die zugehörige Custom Resource aus Kubernetes gelöscht wird.

→Fügen Sie einen Finalizer zu den Metadaten der Custom Resource hinzu. Wenn ein Benutzer die CR löscht, wechselt sie in den Status `Terminating`. Die Reconciliation-Logik des Operators erkennt dies, führt die Bereinigung durch und entfernt dann den Finalizer, wodurch der K8s API-Server die Löschung abschließen kann.

Warum: Ohne einen Finalizer könnte die CR gelöscht werden, bevor der Operator Zeit hat, externe Ressourcen zu bereinigen, was zu verwaister, kostspieliger Infrastruktur führt.

Verwalten Sie den Lebenszyklus einer Flotte von Kubernetes-Clustern selbst mit deklarativen, GitOps-freundlichen Tools.

→Verwenden Sie Cluster API (CAPI). Ein Management-Cluster führt CAPI-Controller aus, die `Cluster`- und `Machine`-Ressourcen abgleichen, um Workload-Cluster über verschiedene Cloud-Anbieter hinweg bereitzustellen und zu konfigurieren.

Warum: CAPI verwandelt das Cluster-Management in einen deklarativen Kubernetes-Workflow, der eine konsistente, automatisierte und versionskontrollierte Bereitstellung und Upgrades ganzer Cluster ermöglicht.

Referenz↗

Entwickeln Sie Plattform-APIs (als CRDs definiert) weiter, ohne bestehende Benutzer zu beeinträchtigen oder eine "Big Bang"-Migration zu erfordern.

→Unterstützen Sie mehrere Versionen in der CRD-Definition (z.B. v1beta1, v1). Implementieren Sie einen Konvertierungs-Webhook, um zwischen den Versionen zu übersetzen, sodass neue Clients v1 verwenden können, während alte Clients weiterhin v1beta1 für dasselbe gespeicherte Objekt verwenden.

Warum: Konvertierungs-Webhooks sind der native Kubernetes-Mechanismus, um eine nicht-disruptive API-Entwicklung zu ermöglichen, die für ein stabiles Plattformprodukt entscheidend ist.

Reduzieren Sie die kognitive Belastung von Entwicklern und verbessern Sie die Auffindbarkeit durch die Zentralisierung von Tools, Dokumentation und Software-Assets.

→Implementieren Sie ein Internal Developer Portal (IDP) mit einem Framework wie CNCF Backstage. Füllen Sie den Software Catalog, stellen Sie Software Templates zum Scaffolding neuer Services bereit und integrieren Sie TechDocs für "Docs-as-Code".

Warum: Ein IDP fungiert als "Single Pane of Glass" für Entwickler, bietet Golden Paths und Self-Service-Funktionen, die die Plattformkomplexität abstrahieren und das Onboarding sowie die Entwicklung beschleunigen.

Referenz↗

Bieten Sie ein einziges, zuverlässiges Inventar aller Software in der Organisation, einschließlich Eigentum, Abhängigkeiten und Betriebsstatus.

→Implementieren Sie einen Softwarekatalog (z.B. Backstage Software Catalog), der über `catalog-info.yaml`-Dateien in Git-Repositories gefüllt wird. Dies erstellt ein zentrales, durchsuchbares Verzeichnis von Services, Bibliotheken, APIs usw.

Warum: Ein Katalog löst die Auffindbarkeit ("Welche Services gibt es?") und die Zuständigkeit ("Mit wem spreche ich über diesen Service?"), was für die Skalierung von Microservice-Architekturen entscheidend ist.

Ermöglichen Sie Entwicklern, neue, produktionsreife Services zu erstellen, die den Organisationsstandards in wenigen Minuten entsprechen.

→Verwenden Sie ein Scaffolding-Tool wie Backstage Software Templates. Definieren Sie Vorlagen, die ein neues Git-Repo mit standardmäßiger Projektstruktur, CI/CD-Pipeline-Konfiguration, Observability-Dashboards und `catalog-info.yaml` generieren.

Warum: Vorlagen kodifizieren Best Practices und bieten einen "befestigten Weg" für Entwickler, wodurch die Zeit bis zum ersten Commit drastisch reduziert und sichergestellt wird, dass neue Services mit integrierter Sicherheit, Observability und Compliance erstellt werden.

Stellen Sie sicher, dass die technische Dokumentation aktuell, versioniert und zusammen mit der beschriebenen Software abgelegt ist.

→Verfolgen Sie einen "Docs-as-Code"-Ansatz. Speichern Sie die Dokumentation in Markdown-Dateien im Git-Repository des Services. Verwenden Sie ein Tool wie Backstage TechDocs, um diese Dokumentation automatisch im IDP zu erstellen und zu rendern.

Warum: Dieses Modell behandelt Dokumentation wie Code – sie kann in Pull Requests überprüft und zusammen mit der Funktion, die sie beschreibt, versioniert werden, wodurch veraltete Dokumente vermieden werden.

Messen Sie die Effektivität der Plattform und ihren Einfluss auf die Software-Bereitstellungsleistung.

→Verfolgen Sie die vier DORA-Metriken: Deployment Frequency (Geschwindigkeit), Lead Time for Changes (Geschwindigkeit), Change Failure Rate (Stabilität) und Time to Restore Service (MTTR, Stabilität).

Warum: DORA-Metriken sind branchenübliche, ergebnisorientierte Messgrößen, die nachweislich mit der Organisationsleistung korrelieren. Sie bieten eine ausgewogene Sicht auf Geschwindigkeit und Stabilität.

Referenz↗

Bieten Sie Teams, die eine gemeinsame Kubernetes-Plattform nutzen, genaue, granulare Kostentransparenz.

→Stellen Sie ein FinOps-Tool wie OpenCost oder Kubecost bereit. Ordnen Sie Kosten den Workloads basierend auf ihrem tatsächlichen Ressourcenverbrauch über die Zeit zu. Verteilen Sie gemeinsame Cluster-Kosten (z.B. Systemkomponenten, Node-Overhead) proportional.

Warum: Genaues Chargeback/Showback fördert die Verantwortlichkeit und ermutigt Teams zur Optimierung der Ressourcennutzung. Ohne dies sind gemeinsame Plattformkosten undurchsichtig und schwer zu verwalten.

Messen Sie, ob die Plattform tatsächlich Wert bietet und von Entwicklungsteams genutzt wird.

→Verfolgen Sie die Akzeptanzrate wichtiger Plattformfunktionen, insbesondere von Golden Path Templates und gemeinsam genutzten CI/CD-Pipelines. Ergänzen Sie dies mit Umfragen zur Entwicklerzufriedenheit (NPS-Stil).

Warum: Eine hohe Akzeptanz optionaler, meinungsbasierter Plattformfunktionen ist ein starkes Signal dafür, dass die Plattform reale Probleme löst. Eine geringe Akzeptanz deutet auf eine Diskrepanz zu den Entwicklerbedürfnissen hin.

Bewerten Sie den aktuellen Zustand der Plattform und erstellen Sie eine Roadmap für Verbesserungen.

→Verwenden Sie ein Plattform-Reifegradmodell, um Fähigkeiten über mehrere Dimensionen hinweg zu bewerten: z.B. Self-Service, Observability, Sicherheit, Zuverlässigkeit und Governance. Definieren Sie Stufen von Ad-hoc/manuell bis vollständig automatisiert und optimiert.

Warum: Ein Reifegradmodell bietet einen strukturierten Rahmen zur Selbstbewertung, hilft, Schwachstellen zu identifizieren, und stimmt das Team auf eine strategische Vision für die Entwicklung der Plattform ab.