Veröffentlicht am

Golden Paths: Kubernetes-Templates für Developer

Teilen:
Authors

TL;DR

Golden Paths sind vordefinierte, getestete Wege für Entwickler, um Anwendungen auf Kubernetes zu deployen. Statt jedes Team eigene Manifeste schreiben zu lassen, stellt das Platform-Team standardisierte Templates bereit — über Backstage, Helm oder interne CLIs. Das Ergebnis: weniger Fehler, schnelleres Onboarding und konsistente Deployments.


Golden Paths: Self-Service für Kubernetes-Teams

Jedes Team baut eigene Deployment-Manifeste. Jedes Team macht dabei andere Fehler. Das ist der Normalzustand in vielen Unternehmen — und genau das Problem, das Golden Paths lösen.

Ein Golden Path ist kein Zwang, sondern eine Empfehlung mit Rückenwind. Das Platform-Team liefert fertige Templates, die Best Practices eingebaut haben:

# Minimales Beispiel: Was ein Golden Path liefert
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}
  labels:
    app.kubernetes.io/managed-by: platform-team
    app.kubernetes.io/part-of: golden-path
spec:
  replicas: {{ .Values.replicas | default 2 }}
  selector:
    matchLabels:
      app: {{ .Values.appName }}
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        fsGroup: 1000
      containers:
        - name: app
          image: "{{ .Values.image }}:{{ .Values.tag }}"
          resources:
            requests:
              cpu: {{ .Values.cpu | default "100m" }}
              memory: {{ .Values.memory | default "128Mi" }}
            limits:
              memory: {{ .Values.memory | default "128Mi" }}

Entwickler füllen nur ihre Werte aus. Security Context, Resource Limits und Labels sind bereits korrekt gesetzt.

Warum Golden Paths funktionieren

Das Konzept stammt aus Spotifys Platform-Engineering-Ansatz. Die Idee: Statt Regeln aufzustellen, die niemand liest, baust du den einfachsten Weg so, dass er automatisch der richtige ist.

Drei Probleme, die Golden Paths konkret lösen:

Onboarding dauert Wochen. Neue Teams müssen Kubernetes-Manifeste verstehen, Helm lernen, CI/CD aufsetzen. Mit einem Golden Path: backstage template create — fertig in 15 Minuten.

Fehlkonfigurationen in Production. Kein Resource Limit gesetzt? Kein Health Check? Kein Network Policy? Golden Paths liefern das alles mit — Teams müssten sich aktiv dagegen entscheiden.

Drift zwischen Teams. Team A nutzt Kustomize, Team B hat eigene Helm Charts, Team C kopiert YAMLs aus Stack Overflow. Golden Paths schaffen eine gemeinsame Basis.

Backstage Software Template

Backstage von Spotify ist die populärste Plattform für Golden Paths. Ein Software Template definiert, was der Entwickler ausfüllt und was das System generiert:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: kubernetes-microservice
  title: Kubernetes Microservice (Golden Path)
  description: Erstellt einen neuen Microservice mit CI/CD und Monitoring
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service-Informationen
      required:
        - serviceName
        - team
        - language
      properties:
        serviceName:
          title: Service-Name
          type: string
          pattern: '^[a-z0-9-]+$'
        team:
          title: Team
          type: string
          enum: ['backend', 'frontend', 'data', 'infra']
        language:
          title: Programmiersprache
          type: string
          enum: ['go', 'java', 'python', 'node']
        replicas:
          title: Replicas (Production)
          type: integer
          default: 2
          minimum: 1
          maximum: 10
    - title: Features
      properties:
        enableIngress:
          title: Ingress aktivieren
          type: boolean
          default: true
        enableMonitoring:
          title: Prometheus Monitoring
          type: boolean
          default: true
  steps:
    - id: fetch
      name: Repository aus Template generieren
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}
          team: ${{ parameters.team }}
          language: ${{ parameters.language }}
    - id: publish
      name: GitHub Repository erstellen
      action: publish:github
      input:
        repoUrl: github.com?owner=meine-firma&repo=${{ parameters.serviceName }}
    - id: register
      name: Im Katalog registrieren
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

Der Entwickler füllt ein Formular aus. Backstage erstellt Repository, Helm Chart, CI/CD-Pipeline und Monitoring — alles nach dem Standard des Platform-Teams.

Helm Values als Schnittstelle

Nicht jede Organisation braucht Backstage. Ein gut strukturiertes Helm Chart mit dokumentierten Values reicht oft aus:

# values.yaml — Golden Path Microservice
app:
  name: mein-service
  team: backend
  language: go

deployment:
  replicas: 2
  image:
    repository: registry.firma.de/mein-service
    tag: latest
  port: 8080

# Vorkonfiguriert — nur bei Bedarf ändern
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 256Mi

monitoring:
  enabled: true
  path: /metrics
  port: 9090

ingress:
  enabled: true
  className: nginx
  host: mein-service.firma.de

networkPolicy:
  enabled: true
  allowNamespaces:
    - monitoring
    - ingress-nginx

Teams ändern nur den oberen Block. Resources, Monitoring und Network Policies sind sinnvoll vorbelegt.

Was gehört in einen Golden Path?

KomponentePflichtWarum
Deployment mit Resource LimitsJaVerhindert Noisy-Neighbor-Probleme
Health Checks (liveness/readiness)JaKubernetes braucht sie für Self-Healing
Network PolicyJaZero-Trust als Default
Prometheus ServiceMonitorEmpfohlenObservability von Anfang an
PodDisruptionBudgetEmpfohlenVerfügbarkeit bei Node-Wartung
HorizontalPodAutoscalerOptionalNicht jeder Service braucht Autoscaling

Typische Fehler bei Golden Paths

Zu viele Optionen. Wenn das Template 40 Parameter hat, ist es kein Golden Path mehr. Halte die Pflichtfelder unter 5.

Kein Upgrade-Pfad. Templates entwickeln sich weiter. Plane von Anfang an, wie existierende Services auf neue Template-Versionen aktualisiert werden. Renovate oder Dependabot für interne Helm Charts helfen hier.

Kein Feedback-Loop. Miss, wie viele Teams den Golden Path nutzen und wo sie abweichen. Abweichungen sind kein Problem — sie zeigen, wo der Path verbessert werden muss.

FAQ

Sind Golden Paths nicht einfach nur Helm Charts?

Nein. Ein Helm Chart ist ein Werkzeug, ein Golden Path ist ein Konzept. Er kann Helm Charts enthalten, aber auch CI/CD-Pipelines, Repository-Struktur, Monitoring-Setup und Dokumentation umfassen.

Was passiert, wenn ein Team vom Golden Path abweichen will?

Das ist explizit erlaubt. Golden Paths sind der einfachste Weg, nicht der einzige. Teams können eigene Manifeste schreiben — sie verlieren dann aber den Support des Platform-Teams und müssen Compliance selbst sicherstellen.

Brauche ich Backstage für Golden Paths?

Nein. Backstage ist komfortabel, aber ein Git-Repository mit Template-Helm-Charts und guter Dokumentation funktioniert genauso. Entscheidend ist, dass der Path existiert und gepflegt wird.

Wie messe ich den Erfolg von Golden Paths?

Adoptionsrate (wie viele Teams nutzen ihn), Time-to-Production für neue Services und Anzahl der Fehlkonfigurationen in Production. Wenn neue Services in unter einer Stunde laufen statt in zwei Wochen, funktioniert der Path.


Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen