Veröffentlicht am

Kubernetes SLA Management: SLOs, SLIs und Error Budgets

Teilen:
Authors

TL;DR

  • SLIs (Service Level Indicators) messen, was Nutzer tatsaechlich erleben -- Latenz, Verfuegbarkeit und Durchsatz sind die drei wichtigsten
  • SLOs (Service Level Objectives) definieren das interne Qualitaetsziel: "99.9% der Requests unter 200ms" ist konkreter als "System muss schnell sein"
  • Error Budgets geben Teams ein messbares Budget fuer Fehler -- solange Budget vorhanden ist, darf deployed werden
  • Burn-Rate-Alerts ersetzen statische Schwellwerte und warnen, wenn das Error Budget zu schnell aufgebraucht wird
  • Tools wie Sloth und Pyrra generieren PrometheusRules automatisch aus SLO-Definitionen

Kubernetes SLA Management: SLOs, SLIs und Error Budgets

Die Frage "Wie verfuegbar ist unser Service?" klingt einfach, ist aber in Kubernetes-Umgebungen ueberraschend schwer zu beantworten. Uptime-Monitoring auf Node-Ebene reicht nicht aus, wenn ein Pod alle 10 Minuten neu startet und dabei 2% der Requests verliert.

Dieser Guide zeigt, wie Plattform-Teams und SREs sinnvolle SLIs definieren, daraus SLOs ableiten und Error Budgets als Steuerungsinstrument nutzen.

SLA vs. SLO vs. SLI: Die Unterscheidung

SLI (Service Level Indicator)
└── Was wird gemessen?
    └── Beispiel: "Anteil der HTTP-Requests mit Status 2xx und Latenz unter 200ms"

SLO (Service Level Objective)
└── Welches Ziel setzen wir intern?
    └── Beispiel: "99.9% der Requests erfuellen den SLI ueber ein 30-Tage-Fenster"

SLA (Service Level Agreement)
└── Was versprechen wir vertraglich?
    └── Beispiel: "99.5% Verfuegbarkeit, sonst Gutschrift"

Error Budget
└── Wie viel Fehler sind erlaubt?
    └── Bei 99.9% SLO: 0.1% = 43.2 Minuten pro 30 Tage

Wichtige Regel: Das SLO muss strenger sein als das SLA. Wenn das SLA 99.5% verspricht, sollte das interne SLO bei 99.9% liegen -- damit bleibt ein Puffer.

Sinnvolle SLIs fuer Kubernetes-Services definieren

SLI-TypWas wird gemessenTypische Quelle
VerfuegbarkeitAnteil erfolgreicher RequestsIngress Controller, Service Mesh
LatenzAntwortzeit (p50, p95, p99)Application Metrics, Ingress
DurchsatzRequests pro SekundeApplication Metrics

SLI-Recording-Rules als PromQL

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: sli-recording-rules
  namespace: monitoring
spec:
  groups:
  - name: sli-availability
    interval: 1m
    rules:
    - record: sli:availability:ratio_rate5m
      expr: |
        sum by (service) (
          rate(http_requests_total{code!~"5.."}[5m])
        )
        /
        sum by (service) (
          rate(http_requests_total[5m])
        )

    - record: sli:latency:ratio_rate5m
      expr: |
        sum by (service) (
          rate(http_request_duration_seconds_bucket{le="0.2"}[5m])
        )
        /
        sum by (service) (
          rate(http_request_duration_seconds_count[5m])
        )

Fuer einen umfassenden Einstieg in Kubernetes Monitoring und die Grundlagen von Prometheus empfehlen wir unseren Monitoring und Observability Guide.

SLOs definieren und Error Budgets berechnen

SLO-Definitionen fuer typische Mittelstands-Services

Service-Kategorie    | Verfuegbarkeits-SLO | Latenz-SLO (p99) | Error Budget (30d)
--------------------|--------------------|--------------------|-------------------
Kunden-Frontend      | 99.95%             | 300ms              | 21.6 min
API-Gateway          | 99.9%              | 200ms              | 43.2 min
Backend-Services     | 99.9%              | 500ms              | 43.2 min
Batch-Processing     | 99.5%              | -                  | 3.6 Stunden
Interne Tools        | 99.0%              | 1000ms             | 7.2 Stunden

Error-Budget-Policy

Budget > 50%:
├── Normaler Feature-Entwicklungs-Modus
├── Deployments jederzeit moeglich
└── Experimentelle Changes erlaubt

Budget 20-50%:
├── Erhoehte Vorsicht bei Deployments
├── Rollback-Plan fuer jedes Deployment Pflicht
└── Keine experimentellen Changes

Budget < 20%:
├── Feature-Freeze: Nur Bug-Fixes und Reliability-Work
├── Jedes Deployment braucht SRE-Approval
└── Post-Incident-Reviews fuer alle Incidents

Budget aufgebraucht (0%):
├── Kompletter Deployment-Freeze
├── Alle Ressourcen auf Stabilitaet
└── Eskalation an Engineering-Leitung

SLO-basiertes Alerting mit Burn-Rate

Klassische Alerts ("CPU ueber 80%") erzeugen Alert-Fatigue. Burn-Rate-Alerts sind praeziser: Sie warnen nur, wenn das Error Budget zu schnell verbraucht wird.

Burn-Rate = Tatsaechliche Fehlerrate / Erlaubte Fehlerrate

Beispiel bei 99.9% SLO (erlaubte Fehlerrate: 0.1%):
- Aktuelle Fehlerrate 0.1% -> Burn Rate = 1.0 (normal)
- Aktuelle Fehlerrate 0.5% -> Burn Rate = 5.0 (5x schneller als erlaubt)
- Aktuelle Fehlerrate 1.0% -> Burn Rate = 10.0 (Budget in 3 Tagen aufgebraucht)

Alert-Schwellwerte (Google SRE Empfehlung):
├── Burn Rate 14.4x ueber 1h  -> Page (sofort reagieren)
├── Burn Rate 6x ueber 6h     -> Page (dringend)
└── Burn Rate 3x ueber 1d     -> Ticket (bald reagieren)

Burn-Rate-Alerts als PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: slo-burn-rate-alerts
  namespace: monitoring
spec:
  groups:
  - name: slo-burn-rate
    rules:
    - record: slo:error_ratio:rate1h
      expr: |
        1 - (
          sum by (service) (rate(http_requests_total{code!~"5.."}[1h]))
          /
          sum by (service) (rate(http_requests_total[1h]))
        )

    - alert: SLOBurnRateCritical
      expr: |
        slo:error_ratio:rate1h{service="order-api"} > (14.4 * 0.001)
        and
        slo:error_ratio:rate5m{service="order-api"} > (14.4 * 0.001)
      for: 2m
      labels:
        severity: critical
        slo: availability
      annotations:
        summary: "SLO Burn Rate kritisch fuer {{ $labels.service }}"
        description: "Error Budget wird mit 14.4x Geschwindigkeit verbraucht."

    - alert: SLOBurnRateWarning
      expr: |
        slo:error_ratio:rate6h{service="order-api"} > (6 * 0.001)
        and
        slo:error_ratio:rate1h{service="order-api"} > (6 * 0.001)
      for: 15m
      labels:
        severity: warning
        slo: availability
      annotations:
        summary: "SLO Burn Rate erhoet fuer {{ $labels.service }}"
        description: "Error Budget wird mit 6x Geschwindigkeit verbraucht."

Sloth: SLO-Management automatisieren

Sloth generiert automatisch die komplexen PrometheusRules aus einfachen SLO-Definitionen.

# Sloth installieren via Helm
helm repo add sloth https://slok.github.io/sloth
helm repo update

helm install sloth sloth/sloth \
  --namespace monitoring \
  --set commonPlugins.enabled=true

SLO-Definition mit Sloth

apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
  name: order-api-slos
  namespace: monitoring
spec:
  service: "order-api"
  labels:
    team: commerce
    tier: critical
  slos:
  - name: "availability"
    objective: 99.9
    description: "99.9% der Requests muessen erfolgreich sein"
    sli:
      events:
        errorQuery: |
          sum(rate(http_requests_total{service="order-api",code=~"5.."}[{{.window}}]))
        totalQuery: |
          sum(rate(http_requests_total{service="order-api"}[{{.window}}]))
    alerting:
      name: OrderAPIAvailability
      labels:
        team: commerce
      pageAlert:
        labels:
          severity: critical
      ticketAlert:
        labels:
          severity: warning

Wie Observability-Stacks in der Praxis aufgebaut werden, erfahren Sie in unserem Artikel zum Observability Stack.

SLO-Reporting und Dashboards

Woechentlicher SLO-Report per CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: slo-weekly-report
  namespace: monitoring
spec:
  schedule: "0 8 * * 1"  # Montags um 08:00 Uhr
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reporter
            image: curlimages/curl:latest
            env:
            - name: PROMETHEUS_URL
              value: "http://prometheus-server.monitoring:9090"
            - name: SLACK_WEBHOOK
              valueFrom:
                secretKeyRef:
                  name: slack-webhook
                  key: url
            command:
            - /bin/sh
            - -c
            - |
              BUDGET=$(curl -s "$PROMETHEUS_URL/api/v1/query?query=slo:error_budget_remaining:ratio" | \
                jq -r '.data.result[] | "\(.metric.service): \(.value[1] | tonumber * 100 | round)%"')
              curl -X POST "$SLACK_WEBHOOK" \
                -H 'Content-type: application/json' \
                -d "{\"text\": \"*Woechentlicher SLO Report*\n\`\`\`\n${BUDGET}\n\`\`\`\"}"
          restartPolicy: OnFailure

Team-Accountability und Incident-Integration

SLO-Ownership-Modell

ServiceSLO-OwnerVerfuegbarkeits-SLOLatenz-SLO (p99)
Order APITeam Commerce99.9%200ms
Payment GatewayTeam Finance99.95%150ms
Search ServiceTeam Discovery99.5%500ms
Batch ImportTeam Data99.0%-

Alertmanager-Routing fuer SLO-Alerts

# Alertmanager-Konfiguration (Auszug)
route:
  group_by: ['alertname', 'service', 'slo']
  routes:
  - match:
      severity: critical
      slo: availability
    receiver: 'pagerduty-slo'
  - match:
      severity: warning
      slo: availability
    receiver: 'slack-slo-warnings'

receivers:
- name: 'pagerduty-slo'
  pagerduty_configs:
  - service_key_file: /etc/alertmanager/pagerduty-key
- name: 'slack-slo-warnings'
  slack_configs:
  - channel: '#slo-warnings'
    title: 'SLO Warning: {{ .GroupLabels.service }}'

Fuer einen tieferen Einblick in Health Checks und Probes, die Ihre SLIs direkt beeinflussen, lesen Sie unseren Health Checks und Probes Guide.

OpenTelemetry fuer praezise SLIs

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: sli-collector
  namespace: monitoring
spec:
  mode: deployment
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
    processors:
      batch:
        timeout: 10s
    exporters:
      prometheus:
        endpoint: 0.0.0.0:8889
        resource_to_telemetry_conversion:
          enabled: true
    service:
      pipelines:
        metrics:
          receivers: [otlp]
          processors: [batch]
          exporters: [prometheus]

Wie OpenTelemetry in Kubernetes integriert wird, beschreibt unser Artikel zu OpenTelemetry fuer Kubernetes.

Checkliste: SLO-Management einfuehren

  • SLIs fuer alle kritischen Services definiert (Verfuegbarkeit + Latenz)
  • SLOs pro Service festgelegt und dokumentiert
  • Error-Budget-Policy mit dem Team vereinbart
  • Sloth oder Pyrra installiert und konfiguriert
  • Burn-Rate-Alerts in Prometheus aktiv
  • Alertmanager-Routing fuer SLO-Alerts konfiguriert
  • Grafana-Dashboard mit Error-Budget-Uebersicht
  • Woechentlicher SLO-Report automatisiert
  • SLO-Ownership pro Service zugewiesen
  • Deployment-Freeze-Policy bei aufgebrauchtem Error Budget

Fazit

SLO-basiertes Management ersetzt das Bauchgefuehl durch messbare Qualitaetsziele. Statt "der Service fuehlt sich langsam an" gibt es "wir haben noch 67% Error Budget und die Latenz-SLO liegt bei 99.2%". Das schafft eine gemeinsame Sprache zwischen Entwicklung, Operations und Business.

Der wichtigste erste Schritt: Fangt mit einem Service an. Definiert einen Verfuegbarkeits-SLI, setzt ein SLO, richtet Burn-Rate-Alerts ein. Wenn das funktioniert, erweitert auf weitere Services. Ein einfaches SLO, das gemessen wird, ist besser als ein komplexes SLO-Framework, das nie live geht.

Sie moechten SLO-Management fuer Ihre Kubernetes-Plattform einfuehren? Wir unterstuetzen Sie bei der Definition sinnvoller SLIs, der Einrichtung von Burn-Rate-Alerts und dem Aufbau einer SRE-Kultur. Kontaktieren Sie uns fuer ein unverbindliches Erstgespraech.

Diskutieren auf Twitter

Kubernetes-Beratung gesucht?

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

Termin buchenKontakt aufnehmen

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen

kubernetesobservability

Prometheus PCA Zertifizierung für Kubernetes Monitoring

Die Prometheus Certified Associate (PCA) Zertifizierung bietet eine fundierte Validierung von Kubernetes Monitoring-Kenntnissen mit Prometheus. Erfahren Sie, wie diese offizielle CNCF-Zertifizierung deutschen Unternehmen hilft, ihre Observability-Strategien zu professionalisieren und die Betriebsstabilität ihrer Cloud-nativen Infrastrukturen zu gewährleisten – essenziell für ein zuverlässiges Kubernetes Monitoring in Deutschland.

Weiterlesen →
Alle Artikel durchsuchen