300 lines
8.5 KiB
Markdown
Executable File
300 lines
8.5 KiB
Markdown
Executable File
#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:
|
||
|
||
1. **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.
|
||
|
||
2. **Automatisierung** von:
|
||
- Rollouts und Rollbacks
|
||
- Skalierung (horizontaler Ausbau: mehr Instanzen)
|
||
- Self-Healing (Pods werden bei Absturz neu gestartet)
|
||
- Service Discovery & Load Balancing
|
||
|
||
3. **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:
|
||
|
||
```yaml
|
||
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:
|
||
|
||
```yaml
|
||
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:
|
||
|
||
```yaml
|
||
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
|
||
|
||
1. Du definierst Ressourcen (YAML/JSON), z. B.:
|
||
|
||
- „Deployment mit 3 Replikas meiner App“
|
||
- „Service, der auf Port 80 erreichbar ist“
|
||
|
||
2. Du übernimmt diese Definition per:
|
||
|
||
```bash
|
||
kubectl apply -f deployment.yaml
|
||
```
|
||
|
||
3. Die API speichert diese Definition in **etcd**.
|
||
|
||
4. 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
|
||
|
||
1. **Container-Image bauen**
|
||
- z. B. mit Docker oder Buildpacks
|
||
|
||
2. **Image registrieren**
|
||
- In einer Container Registry (Docker Hub, GitHub Container Registry, ECR, GCR…)
|
||
|
||
3. **Kubernetes-Manifest(e) schreiben**
|
||
- Deployment, Service, ConfigMap, Secret, etc.
|
||
|
||
4. **Deployen**
|
||
- `kubectl apply -f .`
|
||
- Oder über CI/CD-Pipelines (GitLab CI, GitHub Actions, Argo CD, Jenkins etc.)
|
||
|
||
5. **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:
|
||
|
||
1. **Lokale Umgebung**:
|
||
- `kind` (Kubernetes in Docker)
|
||
- `minikube` oder `k3d`
|
||
|
||
2. **Ü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
|
||
|
||
3. **Doku & Lernressourcen**:
|
||
- Offizielle Doku: https://kubernetes.io/docs/
|
||
- Interaktive Tutorials: Katacoda-ähnliche Labs, Kubernetes Bootcamps, z. B. von Cloud-Anbietern
|