it-know-how/web und cloud gedoens/Kubernetes.md at 5557ade95b5c2e767074fb533c9bdc87e3985819

mathias2784/it-know-how

Fork 0

Files

T

Mathias Schneider 8d40597732 init at work

2026-03-27 12:58:01 +01:00

8.5 KiB

Executable File

Raw Blame History

#IT #Container #Open-Source #Cloud

1. Was ist Kubernetes – in einem Satz?

Kubernetes ist ein Open-Source‑System zur Orchestrierung von Containern (z. B. Docker), das die Bereitstellung, Skalierung und Verwaltung von Anwendungen automatisiert.

Entwickelt von Google, heute von der CNCF (Cloud Native Computing Foundation) verwaltet
Läuft in der Cloud (AWS, Azure, GCP), im Rechenzentrum (On‑Prem) oder lokal (z. B. mit kind, minikube)

2. Warum braucht man Kubernetes?

2.1 Ausgangslage ohne Kubernetes

Bei klassischen Server- oder Container-Setups müssen viele Dinge manuell oder mit Skripten gelöst werden:

Container starten/stoppen
Lastverteilung zwischen Instanzen
Neustart fehlerhafter Instanzen
Rollout neuer Versionen
Skalierung bei Lastspitzen
Konfigurationsmanagement und Secrets
Self-Healing bei Fehlern

2.2 Ziele von Kubernetes

Kubernetes löst diese Probleme, indem es:

Deklaratives Modell nutzt
- Du beschreibst den „Soll-Zustand“ (z. B. „es sollen 3 Instanzen meiner App laufen“).
- Kubernetes sorgt im Hintergrund dafür, dass dieser Zustand erreicht und gehalten wird.
Automatisierung von:
- Rollouts und Rollbacks
- Skalierung (horizontaler Ausbau: mehr Instanzen)
- Self-Healing (Pods werden bei Absturz neu gestartet)
- Service Discovery & Load Balancing
Abstraktion von Infrastruktur:
- Egal ob deine Knoten VMs in der Cloud oder bare-metal-Server sind – Kubernetes abstrahiert das weg.

3. Hohe Ebene: Aufbau eines Kubernetes-Clusters

Ein Kubernetes-Cluster besteht grob aus:

Control Plane (Master-Komponenten)
Worker Nodes (wo die Container wirklich laufen)

3.1 Control Plane (Steuerungsebene)

Wichtige Komponenten:

kube-apiserver
- Zentraler Einstiegspunkt
- Alle Befehle von kubectl und anderen Komponenten laufen über die API (kubectl)
etcd
- Verteilter Key-Value-Store
- Hält den gesamten Cluster-Zustand (z. B. welche Pods, Deployments, ConfigMaps etc.)
kube-scheduler
- Entscheidet, auf welchem Node neue Pods laufen sollen
- Berücksichtigt Ressourcen (CPU, RAM), Constraints, Affinities etc.
kube-controller-manager
- Mehrere Controller (z. B. für Deployments, Nodes, Endpoints)
- Stellt sicher, dass der Ist-Zustand dem Soll-Zustand entspricht („Reconciliation Loop“)
cloud-controller-manager (optional)
- Integration mit Cloud-Anbietern (z. B. Load Balancer in AWS/Azure/GCP anlegen)

3.2 Worker Nodes (Arbeitsebene)

Auf jedem Worker laufen:

kubelet
- Agent auf dem Node
- Kommuniziert mit der API und sorgt lokal dafür, dass die Pods wie gewünscht laufen
Container Runtime
- Führt Container aus: z. B. containerd, CRI‑O, Docker (früher direkt, heute über CRI)
kube-proxy
- Implementiert das Kubernetes-Service-Netzwerk
- Kümmert sich um Weiterleitung von Netzwerkpaketen zu den richtigen Pods

4. Zentrale Konzepte in Kubernetes

4.1 Pod

Kleinste deploybare Einheit in Kubernetes
Ein Pod enthält einen oder mehrere Container, die:
- sich IP-Adresse und Ports teilen
- sich lokale Volumes teilen
Typischerweise: 1 Container pro Pod (plus evtl. Sidecars)

Beispiel: Ein Pod mit einem Nginx Container:

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

4.2 Deployment

Deklarative Beschreibung von Pods + Skalierung
Sagt z. B.: „Es sollen 3 identische Replikate dieses Pods laufen“
Unterstützt Rollouts und Rollbacks (z. B. kubectl rollout undo)

Beispiel-Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

4.3 Service

Stabile Netzwerk-Adresse (DNS-Name, virtuelle IP) für eine Gruppe von Pods
Entkoppelt Clients von einzelnen Pod-IP-Adressen
Typen:
- ClusterIP: intern im Cluster
- NodePort: nach außen freigegeben über einen Port jedes Nodes
- LoadBalancer: Integration mit einem Cloud-Load-Balancer

Beispiel-Service:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  type: ClusterIP
  selector:
    app: my-nginx
  ports:
    - port: 80
      targetPort: 80

4.4 Namespace

Logische Unterteilung innerhalb eines Clusters
Dient zur:
- Trennung von Umgebungen (dev, test, prod)
- Multi-Tenancy
- Ressourcenkontrolle (ResourceQuotas, Limits)
Standard-Namespace: default, daneben z. B. kube-system, kube-public

4.5 ConfigMap & Secret

ConfigMap: Konfiguration (nicht sensibel), z. B. Properties, ENV-Variablen
Secret: sensible Daten (Passwörter, Tokens, Zertifikate)
Werden in Pods als ENV oder als Files (Volumes) bereitgestellt

4.6 Volume & PersistentVolume

Volumes: Daten, die nicht verschwinden, wenn ein Container neu startet
PersistentVolume (PV): repräsentiert eine physische/Cloud-Speicher-Ressource
PersistentVolumeClaim (PVC): „Anforderung“ eines Pods an Speicher (Größe, Klasse)

5. Wie arbeitet Kubernetes? – Das „Desired State“-Modell

Du definierst Ressourcen (YAML/JSON), z. B.:
- „Deployment mit 3 Replikas meiner App“
- „Service, der auf Port 80 erreichbar ist“
Du übernimmt diese Definition per:
```
kubectl apply -f deployment.yaml
```
Die API speichert diese Definition in etcd.
Controller und Scheduler beobachten den Zustand und führen eine Reconciliation Loop aus:
- Ist-Zustand (z. B. 2 Pods laufen) vs. Soll-Zustand (3 Pods sollen laufen)
- Kubernetes startet einen weiteren Pod
- Fällt ein Pod aus → wird automatisch ersetzt

6. Typischer Entwickler-Workflow mit Kubernetes

Container-Image bauen
- z. B. mit Docker oder Buildpacks
Image registrieren
- In einer Container Registry (Docker Hub, GitHub Container Registry, ECR, GCR…)
Kubernetes-Manifest(e) schreiben
- Deployment, Service, ConfigMap, Secret, etc.
Deployen
- kubectl apply -f .
- Oder über CI/CD-Pipelines (GitLab CI, GitHub Actions, Argo CD, Jenkins etc.)
Monitoring & Logging
- Über Tools wie Prometheus, Grafana, ELK/EFK-Stack, Loki, etc.

7. Kubernetes im Ökosystem / Erweiterungen

Kubernetes ist eine Basis, auf der vieles aufbaut:

Helm
- „Package Manager“ für Kubernetes
- Erleichtert das Installieren komplexer Anwendungen (Charts)
Ingress & Ingress Controller
- HTTP/HTTPS-Routing auf Services
- Ermöglicht virtuelle Hosts, Pfad-basiertes Routing usw.
Service Mesh (z. B. Istio, Linkerd)
- Feinere Kontrolle über Traffic, Observability, Security (mTLS)
Operators
- Kubernetes-Erweiterungen, die komplexe Anwendungen als „Custom Resources“ managen (z. B. Datenbanken)
GitOps (z. B. Argo CD, Flux)
- Zustände des Clusters werden aus Git-Repositories synchronisiert

8. Vorteile von Kubernetes

Hohe Portabilität über verschiedene Infrastrukturen
Automatisierte Skalierung und Self-Healing
Standardisierte Schnittstellen (API-first)
Große Community und reiches Ökosystem
Gut geeignet für Microservices und verteile Systeme

9. Herausforderungen und Komplexität

Steile Lernkurve: viele Konzepte (Pods, Deployments, Services, Ingress, RBAC, Storage…)
Betrieb eines eigenen Clusters ist nicht trivial
- Viele Unternehmen nutzen Managed Services: GKE, AKS, EKS, OpenShift, Rancher etc.
Observability: Logs, Metrics, Tracing sind komplexer als bei einer einzigen VM
Sicherheit (RBAC, NetworkPolicies, Secrets-Management) erfordert Planung

10. Wie kann man praktisch starten?

Konkrete Schritte, um anzufangen:

Lokale Umgebung:
- kind (Kubernetes in Docker)
- minikube oder k3d
Übungen:
- Einen einfachen Webserver als Deployment & Service bereitstellen
- Mit kubectl get, describe, logs spielen
- Scaling testen: kubectl scale deployment my-deployment --replicas=5
- Eine neue Version deployen und Rollback ausprobieren
Doku & Lernressourcen:
- Offizielle Doku: https://kubernetes.io/docs/
- Interaktive Tutorials: Katacoda-ähnliche Labs, Kubernetes Bootcamps, z. B. von Cloud-Anbietern

8.5 KiB Executable File Raw Blame History Unescape Escape