Kubernetes einfach erklärt – Cluster, Pods, Deployments

Kubernetes einfach erklärt - Cluster, Pods, Deployments - IT-Glossary

Du möchtest Container zuverlässig starten, skalieren und aktualisieren, ohne jeden Host manuell anzufassen. Genau hier hilft Kubernetes. Die Plattform übernimmt Planung, Selbstheilung und Rollouts, während du dich auf deine Anwendung konzentrierst. In diesem Guide lernst du die Grundbausteine wie Cluster, Pods und Deployments kennen, verstehst ihren Zusammenspiel und bekommst einen Mini-Workflow, mit dem du direkt starten kannst.

Was ist Kubernetes – die Idee dahinter

Kubernetes ist ein Orchestrator für containerisierte Anwendungen. Es verteilt Container auf Nodes, überwacht Zustände und bringt den Ist-Zustand dauerhaft in den Soll-Zustand. Du beschreibst per YAML, wie viele Instanzen laufen sollen und welche Ressourcen nötig sind. Kubernetes erledigt Scheduling, Neustarts bei Fehlern und Rollbacks, wenn etwas schiefgeht.

Der Cluster – Kontrollzentrum und Rechenpower

Ein Cluster besteht aus Steuerungsebene und Worker-Nodes. Auf der Steuerungsebene arbeiten API Server, Scheduler und Controller zusammen. Die Nodes führen deine Workloads aus, betreut vom kubelet und der Container Runtime. Für dich ist der API Server das Tor zum System. Alles, was du tust, läuft über diese Schnittstelle.

Pods – die kleinste Einheit zur Laufzeit

Ein Pod ist die kleinste deploybare Einheit. Er enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Das ist praktisch, wenn Prozesse eng zusammenarbeiten, zum Beispiel ein Webserver mit einem Sidecar für Logging. Pods sind vergänglich. Kubernetes ersetzt sie automatisch, wenn ein Node ausfällt oder ein Update ansteht.

Deployments – deklarativ ausrollen und aktualisieren

Ein Deployment verwaltet die Replikate deiner Anwendung. Du sagst, dass 3 Pods laufen sollen, und Kubernetes sorgt dafür. Rolling Updates tauschen alte Pods schrittweise gegen neue, Rollbacks stellen den alten Stand wieder her. So aktualisierst du ohne Downtime, solange deine App mehrere Instanzen verträgt.

Services – stabile Adressen für wechselnde Pods

Pods bekommen dynamische IPs. Ein Service liefert eine stabile Adresse und verteilt Anfragen per Load Balancing auf passende Pods. Für den externen Zugriff nutzt du NodePort, LoadBalancer oder einen Ingress. Ein Ingress bringt Routing und TLS mit und ist der übliche Weg, HTTP sauber nach außen zu veröffentlichen.

Konfiguration und Geheimnisse

ConfigMaps enthalten Konfigurationswerte wie URLs oder Feature-Flags. Secrets speichern Passwörter, Tokens oder Zertifikate. Beide kannst du als Umgebungsvariablen oder Dateien in Pods einbinden. Trenne Image und Konfiguration, damit du ohne Neubau Einstellungen ändern kannst.

Speicher – Daten über den Pod hinaus

Pods sind kurzlebig. Für persistente Daten nutzt du Volumes. Über PersistentVolumeClaims (PVC) fordert deine App Speicher an, den ein Storage Backend bereitstellt. So überlebt eine Datenbank den Neustart eines Pods, weil die Daten nicht im Container, sondern auf dem Volume liegen.

Gesundheit und Skalierung

Mit Liveness und Readiness Probes prüfst du Gesundheit und Bereitschaft. Erst wenn eine App bereit ist, nimmt der Service sie in den Traffic. Der Horizontal Pod Autoscaler (HPA) skaliert anhand Metriken wie CPU oder benutzerdefinierten Werten. So bleibt die App bei Last reaktionsschnell und spart bei Ruhe Ressourcen.

Ein kleiner YAML-Start – von 0 zu lauffähig

Das folgende Minimalbeispiel zeigt Deployment und Service für eine Web-App. Du kannst es in einer Testumgebung mit kubectl apply -f ausrollen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo-web
  template:
    metadata:
      labels:
        app: demo-web
    spec:
      containers:
        - name: web
          image: nginx:stable
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet: { path: "/", port: 80 }
          livenessProbe:
            httpGet: { path: "/", port: 80 }
---
apiVersion: v1
kind: Service
metadata:
  name: demo-web
spec:
  type: ClusterIP
  selector:
    app: demo-web
  ports:
    - port: 80
      targetPort: 80

Mit replicas: 3 erhältst du drei identische Pods. Der Service macht sie im Cluster unter Port 80 erreichbar. Für den externen Zugriff ergänzt du einen Ingress oder änderst den Service auf LoadBalancer, je nach Umgebung.

Typische Anfängerfragen – kurz und verständlich

Worin liegt der Unterschied zwischen Pod und Container

Ein Pod ist ein Wrapper um einen oder mehrere Container mit gemeinsamem Netzwerk und Speicher. Kubernetes plant Pods, nicht einzelne Container.

Warum brauche ich einen Service, wenn Pods schon laufen

Weil Pods wechselnde IPs haben. Der Service bietet eine stabile Adresse und verteilt Traffic zuverlässig auf passende Pods.

Wie aktualisiere ich sicher

Du änderst die Image-Version im Deployment. Kubernetes führt ein Rolling Update aus. Falls Fehler auftreten, machst du einen Rollback. Health Checks sorgen dafür, dass nur gesunde Pods Traffic bekommen.

Ein pragmatischer Einstiegsplan

Starte mit einem kleinen Cluster lokal oder in der Cloud. Erstelle ein Deployment für deine App und binde ConfigMaps für Einstellungen ein. Schalte einen Service davor und teste Readiness Probes. Ergänze Persistenz über PVC, wenn Daten bleiben müssen. Miss Last und richte den HPA ein. So wächst deine App schrittweise und bleibt stabil.

Häufige Fehler vermeiden

Verzichte auf hart codierte Secrets im Image und auf fehlende Probes. Achte auf Ressourcenlimits, damit einzelne Pods nicht den gesamten Node blockieren. Prüfe Logs über kubectl logs und beobachte Zustände mit kubectl get pods und kubectl describe. Kleine Checks sparen dir später viel Zeit.

Fazit

Kubernetes bringt Ordnung in den Containerbetrieb. Mit Pods als Laufzeiteinheit, Deployments für Rollouts und Services für stabile Erreichbarkeit entsteht ein robustes Fundament. Wenn du Konfiguration sauber trennst, Persistenz über PVC regelst und Health Checks plus Autoscaling einsetzt, läuft deine Anwendung zuverlässig und bleibt wartbar. Starte klein, beschreibe den Soll-Zustand, und lass Kubernetes den Rest automatisieren.

0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert