Kubernetes Service Catalog: Self-Service-Plattform fuer Entwicklerteams aufbauen

TL;DR

• Ein Service Catalog abstrahiert Infrastruktur-Komplexitaet hinter parametrisierten Templates, sodass Entwickler Datenbanken, Caches und ganze Stacks per Pull Request oder UI anfordern koennen
• Crossplane eignet sich fuer die Cloud-Ressourcen-Provisionierung ueber CRDs, Backstage als Developer Portal, Helm Charts als Packaging-Format fuer interne Workloads
• Starten Sie mit 2-3 Templates fuer die haeufigsten Anwendungsfaelle, nicht mit einem vollstaendigen Katalog -- iterieren Sie auf Basis von echtem Feedback
• RBAC und OPA/Gatekeeper stellen sicher, dass nur freigegebene Konfigurationen deployt werden koennen
• Die typische Amortisationszeit liegt bei 3-6 Monaten, gemessen an reduzierten Ticket-Laufzeiten und weniger Konfigurationsfehlern

Was ist ein Service Catalog und warum brauchen Sie einen?

In den meisten Unternehmen laeuft die Bereitstellung von Infrastruktur ueber Tickets. Ein Entwickler braucht eine PostgreSQL-Datenbank, schreibt ein Ticket, wartet drei Tage, bekommt eine Datenbank mit falscher Collation, schreibt ein zweites Ticket. Das kostet Zeit auf beiden Seiten.

Ein Service Catalog dreht diesen Prozess um. Ops definiert parametrisierte Templates -- sogenannte "Produkte" -- und Entwickler koennen diese selbst instanziieren. Die Templates enthalten bereits alle Sicherheits-, Netzwerk- und Compliance-Vorgaben. Kein Freistil, kein Wildwuchs.

Technisch basiert das auf drei Saeulen:

1. Packaging-Format (Helm Charts, Kustomize Overlays oder Crossplane Compositions)
2. Provisioning-Engine (ArgoCD/Flux fuer GitOps, Crossplane Controller fuer Cloud-Ressourcen)
3. Developer Portal (Backstage, Port, oder ein einfaches Git-Repository mit PR-basiertem Workflow)

Architekturentscheidung: Crossplane vs. Helm-only vs. Terraform

Nicht jedes Setup braucht Crossplane. Hier eine ehrliche Gegenuberstellung:

Empfehlung: Wenn Sie nur Kubernetes-interne Ressourcen (Deployments, Services, ConfigMaps) als Templates anbieten wollen, reicht Helm + ArgoCD voellig aus. Sobald Sie Cloud-Ressourcen wie Managed Databases oder S3-Buckets in den Katalog aufnehmen muessen, fuehrt an Crossplane oder einem Terraform-Wrapper kein Weg vorbei.

Praxisbeispiel 1: Crossplane Composition fuer eine PostgreSQL-Datenbank

Diese Composition definiert eine parametrisierte PostgreSQL-Instanz. Entwickler muessen nur storageGB und version angeben -- alles andere (VPC-Anbindung, Backup-Policy, Encryption) ist vom Plattformteam vorgegeben.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: postgresql-standard
  labels:
    catalog: database
spec:
  compositeTypeRef:
    apiVersion: catalog.internal/v1alpha1
    kind: PostgreSQLInstance
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.crossplane.io/v1alpha1
        kind: DBInstance
        spec:
          forProvider:
            dbInstanceClass: db.t3.medium
            engine: postgres
            masterUsername: app_admin
            allocatedStorage: 20
            storageEncrypted: true
            backupRetentionPeriod: 7
            vpcSecurityGroupIds:
              - sg-0abc123def456
            dbSubnetGroupName: internal-db-subnet
          providerConfigRef:
            name: aws-provider
      patches:
        - fromFieldPath: "spec.storageGB"
          toFieldPath: "spec.forProvider.allocatedStorage"
        - fromFieldPath: "spec.version"
          toFieldPath: "spec.forProvider.engineVersion"

Entwickler erstellen dann eine Claim-Ressource:

apiVersion: catalog.internal/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: orders-db
  namespace: team-commerce
spec:
  storageGB: 50
  version: "16.2"

Das ist alles. Kein Ticket, kein Warten, keine Fehlkonfiguration.

Praxisbeispiel 2: Helm-basiertes Template mit ArgoCD ApplicationSet

Fuer rein Kubernetes-interne Workloads funktioniert ein Helm-basierter Ansatz oft besser. Hier ein ApplicationSet, das fuer jedes Team automatisch eine Instanz eines internen Microservice-Templates deployt:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: web-service-catalog
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://git.internal/platform/service-requests.git
        revision: main
        files:
          - path: "requests/**/config.json"
  template:
    metadata:
      name: '{{team}}-{{service}}'
    spec:
      project: default
      source:
        repoURL: https://git.internal/platform/helm-charts.git
        targetRevision: main
        path: charts/web-service
        helm:
          valueFiles:
            - '../../service-requests/requests/{{team}}/{{service}}/values.yaml'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{team}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Entwickler legen einfach eine config.json und eine values.yaml in das Git-Repository -- ArgoCD erledigt den Rest.

Praxisbeispiel 3: OPA Constraint fuer Template-Validierung

Damit niemand am Katalog vorbei deployen kann, setzen Sie OPA Gatekeeper ein:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-catalog-label
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
    namespaces: ["team-*"]
  parameters:
    labels:
      - key: "catalog.internal/managed-by"
        allowedRegex: "^service-catalog$"

Jedes Deployment in einem Team-Namespace muss das Label catalog.internal/managed-by: service-catalog tragen. Manuelle kubectl-Deployments werden abgelehnt.

Developer Portal: Backstage oder etwas Einfacheres?

Backstage (von Spotify entwickelt, jetzt CNCF-Projekt) ist der De-facto-Standard fuer Developer Portals. Es bietet einen Software-Katalog, Templates, TechDocs und Plugin-Ecosystem. Aber es bringt auch Komplexitaet mit: React-Frontend, Node.js-Backend, PostgreSQL fuer den Katalog, eigene Plugin-API.

Fuer Teams unter 50 Entwicklern ist Backstage oft Overkill. Alternativen:

Der PR-basierte Workflow funktioniert erstaunlich gut: Entwickler forken ein Template-Repository, fuellen eine YAML-Datei aus, erstellen einen PR. CI validiert die Werte, ein Approver aus dem Plattformteam gibt frei, ArgoCD synchronisiert.

Namespace-Isolation und Multi-Tenancy

Wenn mehrere Teams den gleichen Cluster nutzen, braucht der Service Catalog eine klare Tenant-Trennung. Jedes Team bekommt einen eigenen Namespace (oder eine Namespace-Hierarchie via Hierarchical Namespace Controller). Die Templates deployen ausschliesslich in den Namespace des anfordernden Teams.

Wichtig dabei:

• ResourceQuotas pro Namespace verhindern, dass ein Team den gesamten Cluster belegt
• NetworkPolicies isolieren die Namespaces voneinander (Default-Deny, dann explizite Freigaben)
• RBAC stellt sicher, dass Teams nur in ihren eigenen Namespaces Ressourcen erstellen und lesen koennen

Mehr zur Multi-Tenancy-Strategie finden Sie unter Kubernetes Multi-Tenancy.

Ein typisches ResourceQuota fuer ein Team-Namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-commerce
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    persistentvolumeclaims: "10"
    services.loadbalancers: "2"

Damit kann das Team maximal 8 CPU-Kerne und 16 GB RAM als Requests anfordern -- unabhaengig davon, wie viele Templates sie instanziieren. Das verhindert unkontrolliertes Wachstum.

Rollout-Strategie: Von Null auf Produktiv

Machen Sie nicht den Fehler, sechs Monate im Stillen zu bauen und dann einen Big-Bang-Rollout zu starten. Stattdessen:

Woche 1-2: Identifizieren Sie die drei haeufigsten Infrastruktur-Tickets der letzten 90 Tage. Das sind Ihre ersten Templates.

Woche 3-4: Bauen Sie das erste Template als Helm Chart oder Crossplane Composition. Testen Sie es mit einem einzelnen Entwicklerteam. Holen Sie hartes Feedback ein.

Woche 5-8: Fuegen Sie zwei weitere Templates hinzu. Etablieren Sie den Workflow (PR-basiert oder Portal). Dokumentieren Sie den Prozess in einem kurzen Runbook.

Woche 9-12: Oeffnen Sie den Katalog fuer alle Teams. Messen Sie Ticket-Reduktion und Bereitstellungszeit. Iterieren Sie auf Basis realer Nutzungsdaten.

Metriken: Woran Sie Erfolg messen

Vergessen Sie vage Zufriedenheitsumfragen. Messen Sie harte Zahlen:

Die Bereitstellungszeit ist der staerkste Indikator. Wenn sie nicht signifikant sinkt, stimmt etwas am Workflow oder an den Templates.

Haeufige Fehler und wie Sie sie vermeiden

Zu viele Parameter im Template. Wenn ein Entwickler 25 Felder ausfuellen muss, nutzt niemand den Katalog. Setzen Sie sinnvolle Defaults und exponieren Sie nur das, was wirklich variiert (Image-Tag, Replicas, Speichergroesse).

Kein Feedback-Loop. Plattformteams, die Templates ohne Entwickler-Input bauen, scheitern. Richten Sie einen Slack-Channel oder regelmaessige Feedback-Sessions ein.

Security als Nachgedanke. Integrieren Sie Network Policies und RBAC von Anfang an in die Templates. Jedes Template sollte per Default restriktiv sein.

Kein Lifecycle-Management. Templates deployen ist die halbe Miete. Definieren Sie auch, wie Updates, Skalierung und Dekommissionierung ablaufen. Wer kuemmert sich um Major-Version-Upgrades der provisionierten Datenbanken?

Weitergehende Themen

Ein Service Catalog ist ein Baustein einer groesseren Platform-Engineering-Strategie. Verwandte Themen, die Sie parallel betrachten sollten:

• Kubernetes Platform Team aufbauen -- Organisationsstruktur und Verantwortlichkeiten
• GitOps Security -- Absicherung des Git-basierten Deployment-Workflows
• Observability Stack -- Monitoring und Logging fuer die provisionierten Services
• Secrets Management mit Vault -- Sichere Credential-Verteilung an Katalog-Services

Fazit

Ein Service Catalog ist kein Produkt, das Sie kaufen. Es ist ein Prozess, den Sie etablieren: Templates definieren, Workflow aufsetzen, Feedback einholen, iterieren. Die technischen Bausteine (Crossplane, Helm, ArgoCD, Backstage) sind ausgereift. Der schwierige Teil ist die organisatorische Arbeit -- klare Verantwortlichkeiten, gute Defaults, konsequentes Lifecycle-Management.

Starten Sie klein, messen Sie frueh, und erweitern Sie nur, was tatsaechlich genutzt wird.

Wenn Sie Unterstuetzung beim Aufbau einer internen Developer Platform oder eines Service Catalogs benoetigen, sprechen Sie uns an unter /kontakt.