- Authors

- Name
- Phillip Pham
- @ddppham
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?
| Komponente | Pflicht | Warum |
|---|---|---|
| Deployment mit Resource Limits | Ja | Verhindert Noisy-Neighbor-Probleme |
| Health Checks (liveness/readiness) | Ja | Kubernetes braucht sie für Self-Healing |
| Network Policy | Ja | Zero-Trust als Default |
| Prometheus ServiceMonitor | Empfohlen | Observability von Anfang an |
| PodDisruptionBudget | Empfohlen | Verfügbarkeit bei Node-Wartung |
| HorizontalPodAutoscaler | Optional | Nicht 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
Developer Experience Metriken für Kubernetes messen
Developer Experience auf Kubernetes-Plattformen mit DORA-Metriken, Zufriedenheitsumfragen und Time-to-First-Deploy systematisch messen und verbessern.
Backstage Developer Portal auf Kubernetes einrichten
Backstage als Internal Developer Portal auf Kubernetes deployen. Software Catalog, Self-Service Templates und TechDocs einrichten mit Helm Chart und Plugins.
Kubernetes Developer Experience: Tilt, Skaffold, DevSpace
Kubernetes Developer Experience verbessern mit Tilt, Skaffold und Telepresence. Inner Loop Tools und Self-Service-Portale für produktive Teams.
Kubernetes Self-Service Portal mit Backstage und Crossplane
Kubernetes Self-Service Portal aufbauen mit Backstage, Crossplane und ArgoCD: Namespace-Provisioning, RBAC-Automation und Guardrails für Teams.
Platform Engineering: Self-Service auf Kubernetes
Internal Developer Platform auf Kubernetes aufbauen: Self-Service für Entwickler mit Backstage, Crossplane und ArgoCD produktiv umsetzen.