Showback und Chargeback: Kubernetes-Kosten zuordnen

TL;DR

Showback zeigt Teams ihre Kubernetes-Kosten transparent auf, Chargeback belastet sie tatsaechlich. Beides erfordert konsistente Labels, klare Regeln fuer Shared Costs und automatisierte Reports. Dieser Artikel zeigt Label-Konventionen, Namespace-basierte Abrechnung, Shared-Cost-Verteilung und Reporting mit Kubecost und OpenCost -- inklusive der organisatorischen Seite.

Showback vs. Chargeback: Der Unterschied

Viele Teams nutzen die Begriffe synonym, aber es gibt einen wichtigen Unterschied:

• Showback: Teams sehen ihre Kosten, aber es findet keine interne Verrechnung statt. Ziel ist Transparenz und Bewusstsein.
• Chargeback: Teams bekommen ihre Kosten tatsaechlich auf ihr Budget gebucht. Ziel ist finanzielle Verantwortung.

Die meisten Organisationen starten mit Showback und wechseln nach 6-12 Monaten zu Chargeback, wenn die Datenqualitaet stimmt und die Teams Vertrauen in die Zahlen haben.

# Schneller Check: Welche Namespaces verursachen die meisten Kosten?
kubectl top pods --all-namespaces --sort-by=cpu | head -20

# Resource Requests pro Namespace aggregieren
kubectl get pods --all-namespaces -o json | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
ns_cpu = {}
for pod in data['items']:
    ns = pod['metadata']['namespace']
    for c in pod['spec'].get('containers', []):
        req = c.get('resources', {}).get('requests', {})
        cpu = req.get('cpu', '0')
        if cpu.endswith('m'):
            cpu_val = int(cpu[:-1])
        else:
            cpu_val = int(float(cpu) * 1000)
        ns_cpu[ns] = ns_cpu.get(ns, 0) + cpu_val
for ns, cpu in sorted(ns_cpu.items(), key=lambda x: -x[1]):
    print(f'{ns:30s} {cpu:6d}m CPU requested')
"

Label-Konventionen: Die Grundlage

Ohne Labels keine Kostenzuordnung. Das klingt offensichtlich, aber in der Praxis fehlen Labels bei 30-60% der Workloads. Definiert eine verbindliche Label-Policy:

# Empfohlene Kosten-Labels fuer alle Workloads
metadata:
  labels:
    # Pflicht-Labels
    team: "platform-engineering"      # Verantwortliches Team
    cost-center: "CC-4200"            # Kostenstelle aus der Buchhaltung
    environment: "production"         # prod, staging, dev

    # Optionale Labels fuer granulare Zuordnung
    project: "checkout-redesign"      # Projekt oder Initiative
    service: "payment-gateway"        # Microservice-Name
    managed-by: "helm"                # Deployment-Methode

Labels per Policy erzwingen

Labels manuell zu setzen funktioniert nicht. Nutzt einen Policy-Controller:

# Kyverno ClusterPolicy: team und cost-center Labels erzwingen
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cost-labels
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cost-labels
      match:
        any:
          - resources:
              kinds:
                - Deployment
                - StatefulSet
                - DaemonSet
              namespaces:
                - "production*"
                - "staging*"
      validate:
        message: "Labels 'team' und 'cost-center' sind Pflicht fuer {{request.object.kind}} in {{request.object.metadata.namespace}}"
        pattern:
          metadata:
            labels:
              team: "?*"
              cost-center: "CC-*"
          spec:
            template:
              metadata:
                labels:
                  team: "?*"
                  cost-center: "CC-*"

Namespace-basierte Abrechnung

Der einfachste Ansatz: ein Namespace pro Team oder Projekt. Alle Kosten im Namespace gehoeren dem Team.

Vorteile: einfach zu implementieren, klare Grenzen. Nachteile: Shared Services (Ingress, Monitoring) lassen sich nicht einem Team zuordnen. Dafuer braucht ihr Shared-Cost-Verteilung.

Shared Costs fair verteilen

Bestimmte Kosten lassen sich nicht direkt zuordnen:

• Cluster-Overhead: kube-system, monitoring, logging, ingress
• Idle Costs: reservierte aber ungenutzte Kapazitaet
• Shared Infrastructure: Load Balancer, DNS, Storage-Backend

Drei gaengige Verteilungsmodelle:

Proportional nach Verbrauch: Shared Costs werden anteilig nach CPU/RAM-Verbrauch verteilt. Team A nutzt 40% der Cluster-CPU und traegt 40% der Shared Costs.

Gleichmaessig: Jedes Team zahlt den gleichen Anteil. Einfach, aber unfair bei unterschiedlichem Verbrauch.

Gewichtet nach Requests: Verteilung basierend auf Resource Requests statt tatsaechlicher Nutzung. Motiviert Teams, Requests realistisch zu setzen.

# Kubecost SharedCost-Konfiguration (values.yaml)
kubecostModel:
  shareTenancyCosts: true
  shareNamespaces: "kube-system,monitoring,ingress-nginx,cert-manager"
  shareLabels: ""
  shareCost: "weighted"  # proportional, even, weighted
  shareSplit: "weighted"

Reporting mit Kubecost und OpenCost

Kubecost: Monatlicher Team-Report per API

#!/bin/bash
# monthly-chargeback-report.sh
# Generiert einen Chargeback-Report fuer alle Teams

WINDOW="lastmonth"
KUBECOST_URL="http://kubecost-cost-analyzer.kubecost:9090"

echo "=========================================="
echo "  Kubernetes Chargeback Report"
echo "  Zeitraum: $(date -d 'last month' +'%B %Y')"
echo "=========================================="
echo ""

# Kosten pro Team abrufen
curl -s "$KUBECOST_URL/model/allocation?window=$WINDOW&aggregate=label:team&accumulate=true" | \
  python3 -c "
import json, sys
data = json.load(sys.stdin)
total = 0
print(f'{'Team':20s} {'CPU':>10s} {'RAM':>10s} {'Storage':>10s} {'Network':>10s} {'Shared':>10s} {'TOTAL':>10s}')
print('-' * 82)
for alloc in data.get('data', []):
    for team, costs in sorted(alloc.items()):
        if team.startswith('__'):
            continue
        cpu = costs.get('cpuCost', 0)
        ram = costs.get('ramCost', 0)
        pv = costs.get('pvCost', 0)
        net = costs.get('networkCost', 0)
        shared = costs.get('sharedCost', 0)
        t = cpu + ram + pv + net + shared
        total += t
        print(f'{team:20s} {cpu:9.2f}€ {ram:9.2f}€ {pv:9.2f}€ {net:9.2f}€ {shared:9.2f}€ {t:9.2f}€')
print('-' * 82)
print(f'{'GESAMT':20s} {'':>10s} {'':>10s} {'':>10s} {'':>10s} {'':>10s} {total:9.2f}€')
"

OpenCost: Kosten per API aggregieren

# OpenCost: Kosten der letzten 30 Tage pro cost-center Label
curl -s "http://opencost.opencost:9090/allocation/compute\
?window=30d\
&aggregate=label:cost-center\
&accumulate=true" | python3 -m json.tool

# Kosten als CSV fuer die Buchhaltung exportieren
curl -s "http://opencost.opencost:9090/allocation/compute?window=lastmonth&aggregate=label:cost-center" | \
  python3 -c "
import json, sys, csv
data = json.load(sys.stdin)
writer = csv.writer(sys.stdout)
writer.writerow(['Kostenstelle', 'CPU_EUR', 'RAM_EUR', 'Storage_EUR', 'Total_EUR'])
for alloc in data.get('data', []):
    for cc, costs in alloc.items():
        writer.writerow([cc, f\"{costs.get('cpuCost',0):.2f}\", f\"{costs.get('ramCost',0):.2f}\", f\"{costs.get('pvCost',0):.2f}\", f\"{costs.get('totalCost',0):.2f}\"])
" > chargeback-$(date +%Y%m).csv

Fuer die OpenCost-Installation und Prometheus-Integration: OpenCost: Kubernetes-Kosten pro Team aufschluesseln.

Organisatorisches Change Management

Die Technik ist der einfache Teil. Die groessere Herausforderung liegt in der Organisation:

Phase 1 -- Transparenz schaffen (Monat 1-3): Showback-Reports einfuehren. Keine Konsequenzen, nur Sichtbarkeit. Teams lernen, ihre Kosten zu lesen und zu verstehen.

Phase 2 -- Optimierung motivieren (Monat 4-6): Monatliche Reviews mit Team-Leads. Auffaelligkeiten besprechen: Warum hat Team X doppelt so hohe Kosten wie letzten Monat? Erste Quick Wins umsetzen: ueberdimensionierte Requests anpassen, ungenutzte Namespaces aufraeumen.

Phase 3 -- Chargeback einfuehren (Monat 7-12): Kosten werden tatsaechlich auf Budgets gebucht. Voraussetzung: Die Zahlen stimmen, die Teams vertrauen dem System und es gibt einen Eskalationspfad bei Unstimmigkeiten.

Haeufige Fehler bei der Einfuehrung:

• Zu frueh Chargeback: Wenn die Daten noch ungenau sind, verlieren Teams das Vertrauen.
• Keine Feedback-Schleife: Reports verschicken reicht nicht. Es braucht regelmaessige Gespraeche.
• Shared Costs ignorieren: Wenn 30% der Kosten keinem Team zugeordnet sind, fehlt der Anreiz zur Optimierung.
• Kein Executive Sponsor: Ohne Rueckendeckung vom Management wird Chargeback nicht durchgesetzt.

FAQ

Was kostet die Einfuehrung von Showback/Chargeback?

Die Tools (OpenCost, Kubecost Free) sind kostenlos. Der Aufwand liegt in der Label-Standardisierung (2-4 Wochen), der Tool-Installation (1-2 Tage) und dem organisatorischen Prozess (3-6 Monate bis Chargeback produktiv ist).

Wie genau sind die Kostenzuordnungen?

Bei guter Label-Abdeckung (>90%) und korrekt gesetzten Resource Requests liegt die Genauigkeit bei 85-95%. Die groesste Ungenauigkeit entsteht durch Shared Costs und Idle Resources.

Soll ich nach Requests oder nach tatsaechlicher Nutzung abrechnen?

Empfehlung: nach Requests abrechnen. Das motiviert Teams, Requests realistisch zu setzen, und verhindert, dass Teams absichtlich niedrige Requests setzen, um Kosten zu druecken -- auf Kosten der Cluster-Stabilitaet.

Wie gehe ich mit Burst-Workloads um (z.B. ML-Training)?

Eigene Namespaces mit eigenen Node-Pools und Spot/Preemptible Instances. Die Kosten sind klar zuordenbar und durch Spot-Preise deutlich guenstiger. Budget-Alerts warnen, wenn ein Training-Job die erwarteten Kosten ueberschreitet.

Brauche ich Kubecost Enterprise oder reicht OpenCost?

OpenCost reicht fuer Single-Cluster-Showback und einfaches Chargeback. Kubecost Enterprise lohnt sich bei Multi-Cluster-Setups, wenn ihr automatische Optimierungsempfehlungen oder rollenbasierte Dashboards braucht.