1~
2Wenn Sie in der Softwareentwicklung arbeiten, haben Sie sicherlich schon von Kubernetes gehört. Aber was genau ist es und warum ist es zum De-facto-Standard für die Verwaltung von containerisierten Anwendungen geworden? Diese Anleitung führt Sie von den Grundlagen zu den fundamentalen Konzepten, mit praktischen Beispielen und Diagrammen, die Ihnen das Verständnis erleichtern.
3~
4## Vor Kubernetes: Ein kurzer historischer Rückblick
5~
6Um zu verstehen, warum Kubernetes so revolutionär ist, machen wir einen Schritt zurück.
7~
81.  **Traditionelles Deployment**: Anfangs wurden Anwendungen auf physischen Servern ausgeführt. Dieser Ansatz war teuer, schwer zu skalieren und anfällig für Ressourcenkonflikte.
92.  **Virtualisiertes Deployment**: Dann kamen die Virtuellen Maschinen (VMs). VMs ermöglichten es, mehrere isolierte Anwendungen auf derselben Hardware auszuführen, was die Ressourcennutzung und Sicherheit verbesserte. Jede VM führt jedoch ein ganzes Betriebssystem aus und verbraucht viele Ressourcen.
103.  **Containerisiertes Deployment**: Container (wie Docker) sind die nächste Entwicklungsstufe. Sie teilen sich dasselbe Host-Betriebssystem, führen aber isolierte Prozesse aus. Sie sind leichtgewichtig, schnell zu starten und portabel.
11~
12Container lösten das Portabilitätsproblem, schufen aber ein neues: Wie verwaltet man Hunderte (oder Tausende) von Containern in einer Produktionsumgebung? Wie stellt man sicher, dass sie immer laufen, miteinander kommunizieren können und je nach Last skalieren?
13~
14Hier kommt **Kubernetes** ins Spiel.
15~
16## Was ist Kubernetes?
17~
18Kubernetes (oft als **K8s** abgekürzt) ist eine Open-Source-Plattform zur Orchestrierung von Containern. Vereinfacht ausgedrückt, automatisiert es das Deployment, die Skalierung und die Verwaltung von containerisierten Anwendungen. Von Google entwickelt und jetzt von der Cloud Native Computing Foundation (CNCF) gepflegt, ist Kubernetes zum unverzichtbaren Werkzeug für jeden geworden, der mit Microservices im großen Stil arbeitet.
19~
20## Die Architektur eines Kubernetes-Clusters
21~
22Eine Kubernetes-Umgebung wird als **Cluster** bezeichnet. Ein Cluster besteht aus einer Reihe von Maschinen, den **Nodes**, auf denen unsere Anwendungen laufen. Die Architektur gliedert sich in zwei Hauptteile: die Control Plane und die Worker Nodes.
23~
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32~
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "Kommuniziert mit" --> E
47    A -- "Kommuniziert mit" --> J
48    User -- "kubectl" --> A
49    C -- "Weist Pods Nodes zu" --> E
50    D -- "Hält Zustand aufrecht" --> A
51    A -- "Speichert/Liest Zustand" --> B
52```
53~
54### Control Plane
55~
56Die Control Plane ist das "Gehirn" des Clusters. Sie trifft globale Entscheidungen (wie das Scheduling) und erkennt und reagiert auf Cluster-Ereignisse. Ihre Hauptkomponenten sind:
57~
58-   **API Server (`kube-apiserver`)**: Das Gateway zum Cluster. Er stellt die Kubernetes-API bereit, die von Benutzern (über `kubectl`), Cluster-Komponenten und externen Tools zur Kommunikation verwendet wird.
59-   **etcd**: Eine konsistente und hochverfügbare Key-Value-Datenbank. Sie speichert alle Cluster-Daten und repräsentiert den gewünschten und aktuellen Zustand des Systems.
60-   **Scheduler (`kube-scheduler`)**: Weist neu erstellte Pods einem verfügbaren Worker Node zu, unter Berücksichtigung von Ressourcenanforderungen, Richtlinien und anderen Einschränkungen.
61-   **Controller Manager (`kube-controller-manager`)**: Führt Controller aus, das sind Kontrollschleifen, die den Zustand des Clusters überwachen und daran arbeiten, ihn in den gewünschten Zustand zu bringen. Zum Beispiel verwaltet der `Node Controller` die Nodes, während der `Replication Controller` sicherstellt, dass die richtige Anzahl von Pods läuft.
62~
63### Worker Node
64~
65Worker Nodes sind die Maschinen (physisch oder virtuell), auf denen die Anwendungen tatsächlich ausgeführt werden. Jeder Node wird von der Control Plane verwaltet und enthält die folgenden Komponenten:
66~
67-   **Kubelet**: Ein Agent, der auf jedem Node läuft. Er stellt sicher, dass die in den Pods beschriebenen Container laufen und fehlerfrei sind.
68-   **Kube-proxy**: Ein Netzwerk-Proxy, der die Netzwerkregeln auf den Nodes verwaltet. Er ermöglicht die Netzwerkkommunikation zu den Pods von Netzwerksitzungen innerhalb oder außerhalb des Clusters.
69-   **Container Runtime**: Die Software, die für die Ausführung von Containern verantwortlich ist. Docker ist am bekanntesten, aber Kubernetes unterstützt auch andere Runtimes wie `containerd` und `CRI-O`.
70~
71## Grundlegende Kubernetes-Objekte
72~
73In Kubernetes wird alles durch **Objekte** dargestellt. Diese Objekte sind "Absichtserklärungen": Sobald Sie ein Objekt erstellen, arbeitet Kubernetes ständig daran, sicherzustellen, dass es existiert und dem gewünschten Zustand entspricht.
74~
75Hier sind die wichtigsten:
76~
77### Pod
78~
79Der **Pod** ist die kleinste Ausführungseinheit in Kubernetes. Er repräsentiert einen oder mehrere Container, die zusammen auf demselben Node ausgeführt werden und Ressourcen wie Netzwerk und Speicher teilen.
80~
81Im Allgemeinen führen Sie nur einen Container pro Pod aus, aber in fortgeschrittenen Szenarien (wie "Sidecar-Containern" für Logging oder Monitoring) können Sie mehr haben.
82~
83Sie erstellen fast nie Pods direkt. Sie verwenden übergeordnete Abstraktionen wie Deployments.
84~
85### Deployment
86~
87Ein **Deployment** ist das Objekt, das Sie am häufigsten verwenden werden. Es beschreibt den gewünschten Zustand für eine Gruppe identischer Pods. Der Deployment-Controller ist verantwortlich für:
88~
89-   Das Erstellen und Verwalten eines **ReplicaSet** (ein anderes Objekt, das sicherstellt, dass eine bestimmte Anzahl von Replikaten eines Pods immer läuft).
90-   Das **Skalieren** der Anzahl der Pods nach oben oder unten.
91-   Die Verwaltung von Anwendungs-**Updates** auf kontrollierte Weise (z.B. *Rolling Update*), ohne Ausfallzeiten.
92~
93Hier ist eine Beispiel-YAML-Datei für ein Deployment, das 3 Replikate eines NGINX-Servers ausführt:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120Pods in Kubernetes sind kurzlebig: Sie können jederzeit erstellt und zerstört werden. Jeder Pod hat seine eigene IP-Adresse, aber diese IP ist nicht stabil. Wie stellen wir also sicher, dass unsere Anwendung zuverlässig erreichbar ist?
121~
122Mit einem **Service**. Ein Service ist eine Abstraktion, die eine logische Menge von Pods und eine Richtlinie für den Zugriff darauf definiert. Er bietet einen **stabilen Zugangspunkt** (eine virtuelle IP-Adresse und einen DNS-Namen) für eine Gruppe von Pods.
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Anfrage an nginx-service" --> A
141```
142~
143Der Service verwendet einen `selector` basierend auf `labels`, um die Pods zu finden, an die er den Verkehr weiterleiten soll.
144~
145So erstellen Sie einen Service für unser NGINX-Deployment:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Standard - macht den Service nur innerhalb des Clusters verfügbar
161```
162~
163Es gibt verschiedene Arten von Services:
164- `ClusterIP`: Macht den Service unter einer cluster-internen IP verfügbar (Standard).
165- `NodePort`: Macht den Service auf einem statischen Port auf jedem Worker Node verfügbar.
166- `LoadBalancer`: Erstellt einen externen Load Balancer im Cloud-Anbieter (z.B. AWS, GCP) und weist dem Service eine öffentliche IP zu.
167~
168### Ingress
169~
170Ein `LoadBalancer`-Service ist großartig, aber einen für jeden Service zu erstellen, kann teuer sein. Um mehrere HTTP/HTTPS-Dienste nach außen verfügbar zu machen, verwenden Sie einen **Ingress**.
171~
172Ein Ingress fungiert als "intelligenter Router" für externen Verkehr. Er ermöglicht es Ihnen, Routing-Regeln basierend auf dem Host (z.B. `api.meineseite.com`) oder dem Pfad (z.B. `meineseite.com/api`) zu definieren.
173~
174```mermaid
175graph LR
176    User -- "meineseite.com/api" --> Ingress
177    User -- "meineseite.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185~
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190~
191Hier ist ein Beispiel für einen Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: meineseite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### Weitere nützliche Objekte
220~
221-   **Namespace**: Ermöglicht es Ihnen, "virtuelle Cluster" innerhalb eines physischen Clusters zu erstellen. Nützlich zur Isolierung von Umgebungen (z.B. `development`, `staging`, `production`) oder Teams.
222-   **ConfigMap und Secret**: Zur Verwaltung von Konfigurationsdaten und Geheimnissen (wie Passwörtern oder API-Schlüsseln), entkoppelt vom Container-Image.
223-   **StatefulSet**: Ähnlich wie ein Deployment, aber spezifisch für zustandsbehaftete Anwendungen (wie Datenbanken), die stabile Netzwerkidentitäten und persistenten Speicher benötigen.
224-   **PersistentVolume (PV) und PersistentVolumeClaim (PVC)**: Zur Verwaltung von persistentem Speicher im Cluster.
225~
226## Fazit
227~
228Kubernetes ist ein unglaublich mächtiges Werkzeug, aber die Lernkurve kann steil sein. Diese Anleitung hat nur an der Oberfläche gekratzt, aber wir hoffen, sie hat Ihnen ein solides Verständnis der grundlegenden Konzepte vermittelt.
229~
230**Was nun?**
231- **Lokal experimentieren**: Installieren Sie [Minikube](https://minikube.sigs.k8s.io/docs/start/) oder [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/), um einen Kubernetes-Cluster auf Ihrem Computer zu erstellen.
232- **`kubectl` verwenden**: Machen Sie sich mit dem `kubectl`-Befehl vertraut, Ihrem Hauptwerkzeug zur Interaktion mit dem Cluster. Versuchen Sie, das NGINX-Deployment und den Service aus diesem Artikel zu erstellen.
233- **Die offiziellen Tutorials erkunden**: Die [Kubernetes-Dokumentation](https://kubernetes.io/docs/tutorials/) ist eine fantastische Ressource voller Beispiele.
234~
235Container-Orchestrierung ist eine grundlegende Fähigkeit in der Cloud-nativen Welt, und die Beherrschung von Kubernetes wird Ihnen eine Welt voller Möglichkeiten eröffnen. Viel Spaß!