Docker und Kubernetes erklärt – Wenn Infrastruktur zum Code wird

Früher war das Problem: "It works on my machine." Developer programmiert auf seinem Laptop mit Python 3.8, MySQL 5.7. Der Code funktioniert. Der Code geht auf den Production Server mit Python 3.6, MySQL 5.5. Der Code läuft nicht mehr. Warum? Die Umgebungen sind unterschiedlich.

```dockerfile # Dockerfile – Description wie Container gebaut wird FROM python:3.8 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . EXPOSE 5000 CMD ["python", "app.py"] ``` Mit diesem Dockerfile: ```bash docker build -t my-app:1.0 . docker run -p 5000:5000 my-app:1.0 ``` Jetzt läuft deine App in einem Container.

Docker läuft auf einen Server gut. Aber was wenn der Server ausfällt? Deine App ist offline. Du brauchst mehrere Container auf mehreren Servern. Aber wer managt das? - Welcher Container läuft wo? - Welcher ist down und muss restart? - Wie load-balanciert man Requests? Das ist wo Kubernetes kommt.

Pod: Die kleinste Unit in Kubernetes. Usually 1 Container per Pod. Deployment: Beschreibung wie viele Pods du willst, wie du updaten willst Service: Load Balancer zwischen Pods Cluster: Viele Nodes (Server) zusammen ```yaml # Deployment – "Ich will 3 Pods von meiner App" apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 # 3 Pods selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: app image: my-app:1.0 ports: - containerPort: 5000 ```

Brauch Docker wenn: - Deine App hat komplexe Dependencies - Du willst konsistent über Entwicklung -> Production Brauch Kubernetes wenn: - Deine App hat viele Nutzer (Skalierung) - Du willst High Availability (mehrere Server) - Du willst Automation von Deployments Für Anfänger: Docker allein ist oft genug. Kubernetes später.