Kubernetes Self-Service Portal mit Backstage und Crossplane

TL;DR

• Ein Kubernetes Self-Service Portal reduziert die Wartezeit fuer Entwickler von Tagen auf Minuten -- Namespace, RBAC und Quotas entstehen automatisch.
• Backstage liefert das Frontend, Crossplane die Infrastruktur-Abstraktion und ArgoCD die GitOps-basierte Provisionierung.
• Guardrails statt Gatekeeping: Policy Engines wie Kyverno setzen Leitplanken, ohne Entwickler auszubremsen.
• Kostenvisibilitaet pro Team ueber Labels und kubecost schafft Verantwortungsbewusstsein ohne Budgetgenehmigungen.
• Approval Workflows fuer sensible Ressourcen (z.B. GPU-Nodes, Produktions-Namespaces) lassen sich per GitOps abbilden.

Warum Self-Service auf Kubernetes unverzichtbar ist

In Enterprise-Umgebungen mit 20, 50 oder 100 Teams ist das klassische Ticket-System der groesste Engpass. Ein Entwickler braucht einen neuen Namespace fuer ein Feature. Er schreibt ein Ticket. Das Platform-Team priorisiert. Zwei Tage spaeter ist der Namespace da -- mit falschen Quotas. Noch ein Ticket.

Das skaliert nicht. Die Loesung ist ein Self-Service Portal, das Entwicklern erlaubt, standardisierte Umgebungen selbst zu provisionieren -- innerhalb definierter Grenzen.

Ohne Self-Service:
  Entwickler -> Ticket -> Warten -> Platform-Team -> Manuell -> Fertig (2-5 Tage)

Mit Self-Service:
  Entwickler -> Portal -> Automatisch -> Fertig (5 Minuten)

Die Architektur eines Kubernetes Self-Service Portals

Ein produktionsreifes Self-Service Portal besteht aus vier Schichten:

Schicht 1: Backstage als Developer Portal

Backstage ist das zentrale Portal, in dem Entwickler ihre Self-Service-Aktionen ausloesen. Software Templates definieren, was ein Entwickler provisionieren kann:

# backstage-template: namespace-provisioning
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: kubernetes-namespace
  title: Neuen Namespace anlegen
spec:
  type: environment
  parameters:
    - title: Namespace-Konfiguration
      properties:
        teamName:
          type: string
          description: Name des Teams
        environment:
          type: string
          enum: [dev, staging, production]
        cpuLimit:
          type: string
          default: "8"
          description: CPU-Limit in Cores
        memoryLimit:
          type: string
          default: "16Gi"
          description: Memory-Limit
  steps:
    - id: create-gitops-pr
      name: GitOps PR erstellen
      action: publish:github:pull-request
      input:
        repoUrl: github.com/org/k8s-gitops
        title: "Namespace ${{ parameters.teamName }}-${{ parameters.environment }}"
        branchName: "ns/${{ parameters.teamName }}-${{ parameters.environment }}"

Der Entwickler waehlt im Portal seine Parameter, klickt auf "Erstellen" und im Hintergrund entsteht ein Pull Request im GitOps-Repository.

Schicht 2: Crossplane fuer Infrastruktur-Abstraktion

Crossplane verwandelt Kubernetes in eine universelle Control Plane fuer Infrastruktur. Statt rohe YAML-Manifeste zu schreiben, definieren Platform-Teams Compositions -- wiederverwendbare Bausteine:

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: team-environment
spec:
  compositeTypeRef:
    apiVersion: platform.example.com/v1alpha1
    kind: TeamEnvironment
  resources:
    - name: namespace
      base:
        apiVersion: kubernetes.crossplane.io/v1alpha2
        kind: Object
        spec:
          forProvider:
            manifest:
              apiVersion: v1
              kind: Namespace
              metadata:
                labels:
                  team: ""
                  cost-center: ""
    - name: resource-quota
      base:
        apiVersion: kubernetes.crossplane.io/v1alpha2
        kind: Object
        spec:
          forProvider:
            manifest:
              apiVersion: v1
              kind: ResourceQuota
              metadata:
                name: team-quota
              spec:
                hard:
                  requests.cpu: "4"
                  requests.memory: 8Gi
                  limits.cpu: "8"
                  limits.memory: 16Gi
                  persistentvolumeclaims: "10"
    - name: rbac-rolebinding
      base:
        apiVersion: kubernetes.crossplane.io/v1alpha2
        kind: Object
        spec:
          forProvider:
            manifest:
              apiVersion: rbac.authorization.k8s.io/v1
              kind: RoleBinding
              metadata:
                name: team-admin
              roleRef:
                apiGroup: rbac.authorization.k8s.io
                kind: ClusterRole
                name: admin

Ein einziges TeamEnvironment-Objekt erzeugt Namespace, ResourceQuota, RoleBinding, NetworkPolicy und LimitRange gleichzeitig. Mehr zu Crossplane finden Sie unter Platform Engineering auf Kubernetes.

Schicht 3: GitOps-basierte Provisionierung

ArgoCD ueberwacht das GitOps-Repository und synchronisiert Aenderungen automatisch in den Cluster:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: team-environments
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/org/k8s-gitops
        revision: main
        directories:
          - path: "teams/*/environments/*"
  template:
    metadata:
      name: "{{path.basename}}"
    spec:
      project: default
      source:
        repoURL: https://github.com/org/k8s-gitops
        targetRevision: main
        path: "{{path}}"
      destination:
        server: https://kubernetes.default.svc
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ArgoCD ApplicationSets erkennen neue Verzeichnisse im Repository automatisch. Wenn ein Team eine neue Umgebung anfordert und der PR gemerged wird, deployed ArgoCD die Ressourcen ohne manuellen Eingriff.

Schicht 4: Guardrails statt Gatekeeping

Self-Service ohne Grenzen fuehrt zu Chaos. Aber zu viele Einschraenkungen machen den Self-Service wertlos. Die Balance liegt in Guardrails: automatisierte Policies, die Fehler verhindern, ohne Entwickler zu blockieren.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Jeder Container braucht CPU- und Memory-Limits."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-namespace-creation
spec:
  validationFailureAction: Enforce
  rules:
    - name: only-gitops-creates-namespaces
      match:
        any:
          - resources:
              kinds:
                - Namespace
      exclude:
        subjects:
          - kind: ServiceAccount
            name: argocd-application-controller
            namespace: argocd
      validate:
        message: "Namespaces duerfen nur ueber GitOps erstellt werden."
        deny: {}

Mehr zu Policy-Automatisierung unter Kyverno Policies fuer Kubernetes.

Approval Workflows fuer sensible Ressourcen

Nicht alles sollte vollautomatisch laufen. Produktions-Namespaces, GPU-Quotas oder externe Cloud-Ressourcen brauchen eine Freigabe. GitOps macht das elegant:

# .github/CODEOWNERS
# Produktions-Umgebungen brauchen Approval vom Platform-Team
teams/*/environments/production/ @platform-team

# GPU-Requests brauchen Approval vom Infra-Team
teams/*/gpu-requests/ @infrastructure-team

Der Workflow ist simpel: Entwickler erstellt PR, CODEOWNERS erzwingt Review, nach Approval merged ArgoCD automatisch. Kein Ticket-System, kein Bottleneck -- aber kontrolliert.

Kostenvisibilitaet pro Team

Self-Service ohne Kostentransparenz fuehrt dazu, dass Teams unbegrenzt Ressourcen anfordern. Die Loesung ist ein Label-basiertes Kostensystem:

# Jeder Namespace bekommt automatisch ein cost-center Label
apiVersion: v1
kind: Namespace
metadata:
  name: team-payments-dev
  labels:
    team: payments
    cost-center: cc-4711
    environment: dev

Kubecost oder OpenCost aggregieren die tatsaechlichen Kosten pro Label. Ein woechentlicher Report an die Teamleitung schafft Bewusstsein:

Teams sehen, was sie tatsaechlich nutzen vs. was sie reserviert haben. Das motiviert zur Optimierung ohne Budgetgenehmigungen von oben.

RBAC-Automation: Vom Onboarding bis zum Offboarding

Manuelles RBAC-Management skaliert nicht. Wenn ein neuer Entwickler ins Team kommt, braucht er Zugriff auf die richtigen Namespaces. Wenn jemand das Team wechselt, muss der alte Zugriff weg.

Die Loesung: RBAC an die Teamzugehoerigkeit koppeln, nicht an einzelne Personen.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-payments-dev-access
  namespace: team-payments-dev
subjects:
  - kind: Group
    name: team-payments
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Wenn der Identity Provider (z.B. Azure AD, Okta) die Gruppenzugehoerigkeit an den OIDC-Token uebergibt, funktioniert Onboarding und Offboarding automatisch. Mehr zu RBAC-Konzepten unter RBAC fuer Enterprise Kubernetes.

Implementierungsstrategie: Phase fuer Phase

Bauen Sie nicht alles gleichzeitig. Ein bewaehrter Stufenplan:

Phase 1 -- Woche 1-2: Foundation

• GitOps-Repository aufsetzen (ArgoCD)
• Namespace-Template mit ResourceQuota und RBAC erstellen
• Kyverno-Basisrichtlinien deployen

Phase 2 -- Woche 3-4: Self-Service

• Backstage installieren und Software Catalog befuellen
• Erstes Software Template fuer Namespace-Provisioning
• OIDC-Integration fuer automatisches RBAC

Phase 3 -- Woche 5-8: Erweiterung

• Crossplane Compositions fuer komplexe Umgebungen
• Kostenreporting mit kubecost oder OpenCost
• Approval Workflows fuer Produktion

Phase 4 -- Ab Woche 9: Skalierung

• Weitere Templates (Datenbanken, Message Queues, Monitoring-Stacks)
• Self-Service Dashboard mit Echtzeit-Kostenansicht
• Feedback-Loop mit Entwicklerteams

Haeufige Fehler und wie man sie vermeidet

Fehler 1: Zu viele Optionen im Portal. Wenn Entwickler 30 Parameter auswaehlen muessen, nutzen sie das Portal nicht. Halten Sie Templates einfach -- maximal 5 Eingabefelder.

Fehler 2: Keine Standardwerte. Jedes Feld ohne sinnvollen Default erhoet die kognitive Last. CPU-Limit, Memory-Limit, Replicas -- alles sollte Defaults haben.

Fehler 3: Kein Feedback nach der Provisionierung. Entwickler muessen sehen, ob ihre Anfrage durchgegangen ist. Backstage-Plugins fuer ArgoCD zeigen den Sync-Status direkt im Portal.

Fehler 4: Policies ohne Erklaerung. Wenn Kyverno einen Deployment-Versuch blockiert, muss die Fehlermeldung klar sagen warum und was zu tun ist. "Policy violation" allein hilft niemandem.

Metriken fuer den Erfolg

Messen Sie den Fortschritt Ihres Self-Service Portals:

Fazit

Ein Kubernetes Self-Service Portal ist keine einmalige Installation, sondern ein Produkt, das Sie kontinuierlich weiterentwickeln. Starten Sie mit dem groessten Pain Point -- typischerweise Namespace-Provisioning -- und erweitern Sie schrittweise. Die Kombination aus Backstage, Crossplane, ArgoCD und Kyverno bietet ein ausgereiftes Fundament, auf dem Enterprise-Teams skalieren koennen.

Sie moechten ein Self-Service Portal fuer Ihre Kubernetes-Teams aufbauen? Wir unterstuetzen bei Architektur, Implementierung und Rollout -- von der ersten Konzeptphase bis zum produktiven Betrieb. Jetzt Beratung anfragen.