Kubernetes Platform Engineering: Self-Service-Plattformen fuer Entwickler aufbauen

TL;DR

Platform Engineering schafft eine Internal Developer Platform (IDP), die Entwicklern Self-Service-Zugang zu Kubernetes gibt, ohne dass sie Kubernetes-Experten sein muessen.
Der Technology Stack besteht typischerweise aus Backstage (Portal), Crossplane (Infrastruktur), ArgoCD (Deployments) und Prometheus/Grafana (Monitoring).
Starten Sie klein: Templates fuer Deployments und CI/CD-Pipelines bringen den schnellsten ROI.
DORA-Metriken (Deployment Frequency, Lead Time, MTTR, Change Failure Rate) messen den Erfolg Ihres Platform Teams.
Die groessten Fehler: Zu viel auf einmal bauen, Entwickler nicht einbeziehen, und die Plattform als Produkt nicht ernst nehmen.

Was ist Platform Engineering?

Platform Engineering ist die Disziplin, interne Entwicklerplattformen zu entwerfen und zu betreiben. Das Ziel: Entwickler koennen Infrastruktur und Deployments selbst verwalten, ohne Tickets an Ops-Teams zu schreiben.

Im Kubernetes-Kontext bedeutet das: Statt dass jedes Team eigene Helm Charts schreibt, RBAC-Policies versteht und Monitoring konfiguriert, stellt das Platform Team fertige "Golden Paths" bereit. Entwickler waehlen aus einem Katalog, konfigurieren wenige Parameter und bekommen eine vollstaendig provisionierte Umgebung.

Ohne Platform Engineering:
  Entwickler -> Ticket an Ops -> Warten -> Manuelles Setup -> Deployment

Mit Platform Engineering:
  Entwickler -> Self-Service Portal -> Automatische Provisionierung -> Deployment

Der Unterschied zu klassischem DevOps: DevOps sagt "Jedes Team ist fuer seinen Betrieb verantwortlich". Kubernetes Platform Engineering sagt "Wir bauen die Werkzeuge, damit jedes Team seinen Betrieb effizient ausfuehren kann".

Platform Team vs. DevOps Team

Aspekt	DevOps Team (klassisch)	Platform Team
Arbeitsweise	Reagiert auf Anfragen	Baut Produkte fuer Entwickler
Output	Infrastruktur-Arbeit	Self-Service-Tools und APIs
Kunden	Das Unternehmen	Entwickler-Teams
Erfolgsmessung	Uptime, Incident Response	Developer Productivity, Adoption

Empfohlene Teamzusammensetzung (5-7 Personen)

1 Product Owner / Engineering Manager
2 Platform Engineers (Kubernetes, Infrastruktur)
1 Developer Experience Engineer (Tooling, Portal)
1 SRE (Monitoring, Alerting, Runbooks)
Optional: 1 Security Engineer (Policy-as-Code)

Das Platform Team behandelt die Plattform als internes Produkt: Roadmap, User Research mit Entwickler-Teams, Feedback-Loops und iterative Entwicklung. Mehr dazu in unserem Artikel zum Aufbau eines Platform Teams.

Der Technology Stack: Backstage, Crossplane, ArgoCD

Backstage als Developer Portal

Backstage (CNCF-Projekt, urspruenglich von Spotify) bietet einen Service Catalog, Templates und ein Plugin-System. Ein Software Template fuer Kubernetes-Deployments:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: kubernetes-service
  title: Kubernetes Microservice
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service-Informationen
      required:
        - name
        - team
      properties:
        name:
          title: Service Name
          type: string
          pattern: '^[a-z0-9-]+$'
        team:
          title: Team
          type: string
          enum: [frontend, backend, data, ml]
        replicas:
          title: Anzahl Replicas
          type: integer
          default: 2
        cpu:
          title: CPU Request
          type: string
          default: "250m"
        memory:
          title: Memory Request
          type: string
          default: "256Mi"
  steps:
    - id: fetch-template
      name: Repository aus Template erstellen
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          team: ${{ parameters.team }}
    - id: publish
      name: Git Repository erstellen
      action: publish:github
      input:
        repoUrl: github.com?owner=meine-org&repo=${{ parameters.name }}
    - id: create-argocd-app
      name: ArgoCD Application erstellen
      action: argocd:create-resources
      input:
        appName: ${{ parameters.name }}
        repoUrl: ${{ steps.publish.output.remoteUrl }}
        path: k8s/overlays/production
    - id: register
      name: Im Service Catalog registrieren
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

Crossplane fuer Infrastructure Self-Service

Crossplane erweitert Kubernetes um Cloud-Infrastruktur als Kubernetes-Ressourcen. Entwickler bestellen Datenbanken per YAML:

# Das ist alles, was ein Entwickler schreiben muss:
apiVersion: database.platform.example.de/v1alpha1
kind: PostgresInstance
metadata:
  name: order-service-db
  namespace: team-backend
spec:
  size: medium
  version: "16"

Die Komplexitaet steckt in der Composition, die das Platform Team einmalig definiert:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgres-aws
spec:
  compositeTypeRef:
    apiVersion: database.platform.example.de/v1alpha1
    kind: XPostgresInstance
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.upbound.io/v1beta2
        kind: Instance
        spec:
          forProvider:
            region: eu-central-1
            engine: postgres
            publiclyAccessible: false
            storageEncrypted: true
            backupRetentionPeriod: 7
      patches:
        - fromFieldPath: spec.size
          toFieldPath: spec.forProvider.instanceClass
          transforms:
            - type: map
              map:
                small: db.t4g.medium
                medium: db.r6g.large
                large: db.r6g.xlarge

ArgoCD fuer GitOps-Deployments

ArgoCD synchronisiert den Cluster-Zustand mit Git. Fuer eine ausfuehrliche Anleitung empfehlen wir unser ArgoCD GitOps Tutorial.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: team-applications
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/meine-org/platform-config.git
        revision: main
        directories:
          - path: "teams/*/apps/*"
  template:
    metadata:
      name: "{{path[1]}}-{{path[3]}}"
    spec:
      project: "{{path[1]}}"
      source:
        repoURL: https://github.com/meine-org/platform-config.git
        path: "{{path}}"
      destination:
        server: https://kubernetes.default.svc
        namespace: "{{path[1]}}"
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Schritt-fuer-Schritt: Was zuerst bauen?

Phase 1 (Monat 1-2): Standardisierte Deployments

# Standard Helm Values fuer jeden Microservice
replicaCount: 2
resources:
  requests:
    cpu: 250m
    memory: 256Mi
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
monitoring:
  enabled: true
  serviceMonitor: true
networkPolicy:
  enabled: true

Phase 2 (Monat 3-4): Self-Service Namespace-Provisionierung

apiVersion: v1
kind: Namespace
metadata:
  name: team-backend
  labels:
    team: backend
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    pods: "100"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-backend-edit
  namespace: team-backend
subjects:
  - kind: Group
    name: team-backend
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Phase 3 (Monat 5-6): Observability und Infrastructure Self-Service

Standard-Alerts fuer jeden Service, Crossplane fuer Datenbanken, Grafana-Dashboards per Template.

DORA-Metriken: Erfolg messen

Metrik	Was wird gemessen	Zielwert (Elite)
Deployment Frequency	Wie oft wird deployed	Mehrmals taeglich
Lead Time for Changes	Commit bis Produktion	Unter 1 Stunde
Mean Time to Recovery	Ausfall bis Wiederherstellung	Unter 1 Stunde
Change Failure Rate	Deployments die Fehler verursachen	Unter 5%

Die fuenf groessten Fehler

1. Alles auf einmal bauen. Starten Sie mit einem konkreten Problem (z.B. "Neuen Service deployen dauert 3 Tage") und loesen Sie dieses zuerst.

2. Entwickler nicht einbeziehen. Regelmaessige User Research, Beta-Tester aus den Teams und ein oeffentlicher Feedback-Kanal sind Pflicht.

3. Zu viel Abstraktion. Entwickler muessen noch verstehen, was passiert. Bieten Sie sinnvolle Defaults mit der Option, sie zu ueberschreiben.

4. Keine Migration von Legacy-Workflows. Bieten Sie Migrationspfade an, statt bestehende Workflows ueber den Haufen zu werfen.

5. Kein Product Mindset. Die Plattform ist ein internes Produkt. Behandeln Sie sie auch so: Roadmap, Feedback, Iteration.

Fuer Details zu GitOps als Teil Ihrer Plattform lesen Sie den Artikel zu GitOps Security Best Practices. Fuer CI/CD-Skalierung empfehlen wir den Enterprise CI/CD Guide.

Platform Engineering: Self-Service auf Kubernetes

Kubernetes Platform Engineering: Self-Service-Plattformen fuer Entwickler aufbauen

TL;DR

Was ist Platform Engineering?

Platform Team vs. DevOps Team

Empfohlene Teamzusammensetzung (5-7 Personen)

Der Technology Stack: Backstage, Crossplane, ArgoCD

Backstage als Developer Portal

Crossplane fuer Infrastructure Self-Service

ArgoCD fuer GitOps-Deployments

Schritt-fuer-Schritt: Was zuerst bauen?

Phase 1 (Monat 1-2): Standardisierte Deployments

Phase 2 (Monat 3-4): Self-Service Namespace-Provisionierung

Phase 3 (Monat 5-6): Observability und Infrastructure Self-Service

DORA-Metriken: Erfolg messen

Die fuenf groessten Fehler

Verwandte Artikel

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

Kubernetes Platform Team aufbauen: IDP Anleitung

Developer Experience Metriken für Kubernetes messen

Developer Onboarding auf Kubernetes automatisieren

Golden Paths: Kubernetes-Templates für Developer

Backstage Developer Portal auf Kubernetes einrichten