Was ist Kubernetes (K8s)?

Kubernetes ist eine Open-Source-Plattform, die Deployment, Skalierung und Betrieb containerisierter Anwendungen über viele Maschinen hinweg automatisiert. Die Kernidee ist deklarativ: Sie beschreiben den gewünschten Endzustand – drei Replikas dieses Containers, so viel Arbeitsspeicher, erreichbar auf diesem Port –, und das System arbeitet fortlaufend daran, die Wirklichkeit daran anzugleichen: Es startet neu, plant um und skaliert, ohne dass Sie eingreifen müssen.

Das Wichtigste in Kürze

Das Manifest: So sprechen Sie mit Kubernetes

Alles ist eine Deklaration. Das hier ist ein minimales, echtes Deployment – mit Anmerkungen in verständlichem Deutsch:

apiVersion: apps/v1
kind: Deployment              # "halte N Kopien davon am Laufen"
metadata:
  name: api
spec:
  replicas: 3                 # der Soll-Zustand: drei Pods
  selector:
    matchLabels: { app: api }
  template:                   # was jeder Pod enthält
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# Anwenden, einen Pod beenden, zusehen, wie Kubernetes ihn wiederbelebt. Genau das ist das Produkt.

Zum Vergleich – dasselbe Ergebnis (ein deploytes, skaliertes, selbstheilendes Backend) als Dienst genutzt, bei dem Manifest, Cluster und der Abgleich um 3 Uhr nachts das YAML von jemand anderem sind:

// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}

// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}

Ein Blick in den Cluster

Das Vokabular in je einer Zeile: Ein Cluster ist das Gesamtsystem; ein Node ist eine Maschine; ein Pod ist die kleinste deploybare Einheit (ein oder mehrere Container, die sich Netzwerk und Speicher teilen); ein Deployment verwaltet replizierte Pods mit Rolling Updates und Rollbacks; ein Service gibt kurzlebigen Pods eine stabile Adresse; ein Ingress leitet Traffic von außen hinein; ConfigMaps und Secrets transportieren die Konfiguration; Namespaces teilen einen Cluster zwischen Teams auf. Die offizielle Übersicht ist der maßgebliche nächste Schritt in die Tiefe.

Kubernetes vs. Docker

Die ewige Verwechslung hat ein Datum: Seit v1.24 (2022) hat Kubernetes seinen Docker-spezifischen Runtime-Shim entfernt und spricht nur noch mit standardkonformen Container-Runtimes. Kaputt ging nichts – Images folgen dem offenen OCI-Standard –, aber die Rollen wurden dadurch klar: Docker ist die Werft, Kubernetes die Hafenbehörde. Der Name wusste das schon immer: Kubernetes ist griechisch für Steuermann – das Projekt wurde im Juni 2014 als Open Source veröffentlicht, erreichte 2015 Version 1.0 und legte den Grundstein für die CNCF. Damit wurde ein Jahrzehnt Erfahrung im Betrieb von Containern im Flottenmaßstab zu einem öffentlichen Gemeingut.

Typische Anwendungsfälle

• Microservice-Flotten. Dutzende Dienste mit unabhängiger Skalierung und unabhängigen Deployments – genau der Workload, für den Kubernetes geformt wurde.
• Plattform-Teams. Aufbau einer internen Plattform auf einem einheitlichen Unterbau, der in jeder Cloud und On-Premises identisch läuft.
• Große Workloads mit Lastspitzen. Batch-Jobs, Daten-Pipelines, ML-Training – dicht gepackt auf gemeinsam genutzter Kapazität.
• Multi-Cloud- und Portabilitätsstrategien. Die Compute-Schicht einer Abwehr gegen Vendor-Lock-in – mit der Einschränkung, dass die umgebenden verwalteten Dienste weiterhin binden.
• Selbstheilende Produktionsumgebungen. Überall dort, wo “um 3 Uhr nachts ist eine Maschine ausgefallen” ein Nicht-Ereignis sein muss statt eines nächtlichen Alarms.

Sollten Sie Kubernetes betreiben? Eine Entscheidungsmatrix

Der stille Konsens der Branche: Die meisten Teams, die Kubernetes betreiben, liegen unterhalb des Maßstabs, ab dem es sich rechnet. Die Leiter der Alternativen – ein Host mit Compose-Datei, ein verwalteter Container-Dienst, ein PaaS, ein BaaS – deckt alles bis zu echten Flottenproblemen ab, und Managed Kubernetes deckt den Großteil des Rests ab.

Grenzen und Trade-offs

• Die Lernkurve ist der Schatten des Produkts. Pods, Services, Ingress, RBAC, Operators, Helm – Routine misst sich in Monaten, und der Cluster wartet nicht.
• Betriebliche Angriffsfläche. Upgrades, Zertifikatsrotation, Netzwerk-Plugins und der Zustand des State Stores verzeihen keine Fehler; deshalb haben sich verwaltete Control Planes durchgesetzt.
• Ausufernde YAML-Dateien. Deklarative Konfiguration wird im großen Maßstab zu einer eigenen Codebasis, mit eigenen Reviews, Bugs und Drift.
• Es orchestriert Container, keine Architektur. Ein schlecht geschnittenes System auf Kubernetes bleibt dasselbe System, nur jetzt verteilt – der Cluster verstärkt das Design, ob gut oder schlecht.
• Kubernetes ist kein PaaS. Es bringt bewusst kein CI/CD, keine Standard-Datenbank und keine Dienste auf Anwendungsebene mit – die Plattform darüber müssen Sie selbst zusammenbauen, und genau diese Arbeit verkaufen höhere Abstraktionen als Produkt zurück.

Kubernetes mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Das Verhältnis zu Kubernetes ist eine ehrliche Arbeitsteilung: Was die meisten Anwendungsteams tatsächlich von einem Cluster wollen – deployte, skalierte, selbstheilende Backend-Dienste –, liefert die BaaS-Schicht, ohne dass Sie ein einziges Manifest schreiben. Und für Workloads, die wirklich Container sind, betreibt Back4app Containers diese als verwalteten Dienst: Image pushen, Orchestrierung erhalten, ohne selbst den Hafen zu betreiben.