---
categories:
  - Documentation
created: 2025-06-04
---
# Kubernetes

- Von Google ursprünglich entwickelt, inzwischen unter der Schirmherrschaft von Cloud Native Computing Foundation
- Seit 2014 Open-Source

## Warum Kubernetes?

- **Skalierbarkeit**: Automatische Skalierung von Anwendungen basierend auf der aktuellen Nachfrage. Ermöglicht effiziente Resourcennutzung
- **Portabilität**: Man kann Anwendungen, die bereits in einem Kubernetes Cluster laufen leicht zwischen verschiedenen Cloud-Providern verschieben, da einheitliche API
- **Verfügbarkeit**: Startet fehlerhafte Container neu und verteilt Lasten gleichmäßig dank eingebautem Load-Balancer
- **Integration**: Nahtlose Deployments via CI/CD

## Aufbau
![[Diagram 1.svg]]

### Master Node

- **API Server**: Stellt die API für die Interaktion mit dem Kubernetes Cluster bereit. Alle Interaktionen laufen über diesen API Server (z. B. das erstellen von Pods)
- **etcd**: eine verteilte, konsistente Schlüssel-Wert-Datenbank. Dient als Konfigurations- und Zustandsspeicher für Kubernetes

### Worker Node

- **kubelet**: Agent, verantwortlich, dass Container in den Pods ausgeführt werden. Überwacht Zustand der Pods und kommuniziert mit dem API Server
- **kube-proxy**: Kümmert sich um die Netzwerkregeln und leitet den Netzwerkverkehr zu den richtigen Pods
- **Container Runtime**: z. B. Docker, containerd, CRI-O (kommt auf die Kubernetes Implementierung an)

## Kubernetes objects

- **Namespaces**: Isoliert Resourcen innerhalb des Clusters. Z. B. könnte es Namespaces für "Development", "Testing" oder "Production" geben. Aber auch verschiedene Applikations-Namespaces sind denkbar.
- **Deployments**: Gewünschter Zustand einer Anwendung, zusammen mit Replicas (Instanzen) und Container-Images, die ausgeführt werden sollen. Damit kann man Rollouts, Updates und Rollbacks ausführen.
- **ReplicaSets**: Stellt sicher, dass Pod Instanzen in der deklarierten Anzahl vorhanden sind (siehe Deployments). Werden vom Deployment verwaltet.
- **Services**: Ein Service stellt eine stabile Netzwerkadresse für eine dynamische Gruppe von Pods bereit. Kümmert sich auch um den Netzwerkzugriff auf Pods innerhalb des Clusters von außen.
	- *Load Balancing*: verteilt den eingehenden Datenverkehr auf die verfügbaren Pods
	- *Service Discovery*: Damit können Pods innerhalb des Clusters über definierte Namen kommunizieren
	- *Typen*:
		- *ClusterIP*: Default, interne IP im Cluster
		- *NodePort*: Öffnet definierten Port auf allen Nodes um diesen Service zugänglich zu machen
		- *LoadBalancer*: externer Load Balancer
		- *ExternalName*: Leitet Anfragen an einen externen DNS-Namen weiter

![[Diagram 2.svg]]
- **ConfigMaps**: Konfigurationsdaten in Form von Schlüssel-Wert-Paaren. Kann als Umgebungsvariablen, Argumente oder Konfigurationsdateien eingebunden werden.
- **Secrets**: Wie ConfigMaps nur verschlüsselt. Gedacht für Passwörter oder Schlüssel.

### Additional mentions

- **Jobs**: Führt einen Pod eine angegebenen Anzahl an Versuchen aus (damit könnte man z. B. händische SQL Skripte ausführen)
- **CronJobs**: Wiederholtes ausführen von Pods anhand von CronJob Regeln
- **DaemonSet**: lässt einen Pod auf jedem Node laufen (z. B. um Logdateien aufzusammeln und an einen Service zu schicken)

## Autoscaling

Einer der Möglichkeiten innerhalb von Kubernetes ist es, Horizontal Scaling zu aktivieren. Das bedeutet, dass die ReplicaSets anhand von zusätzlichen Informationen angepasst werden. Z. B. wenn es eine Load-Spitze gibt, kann
Kubernetes neue Pods erzeugen und via LoadBalancer die Last entsprechend verteilen.

```
kubectl autoscale deployment your-deployment --cpu-percent=50 --min=1 --max=10
```

Man kann auch custom metrics nutzen, um Autoscaling zu aktiveren. Z. B. könnte man innerhalb einer Message Queue die Nachrichten zählen und die Pods anhand der Nachrichten skalieren.

## Rollout & Rollback

Kubernetes unterstützt auch beim Rollout. Falls ein Deployment ausgerollt wird, welches aber eventuelle Seiteneffekte verursacht, welche nicht gewünscht sind so kann man sich die History anhand von diesem Befehl anschauen:

```
kubectl rollout history deployment/your-deployment -n your-namespace
```

Mögliche Ausgabe:

```bash
deployment.apps/pes-resource-management-test
REVISION  CHANGE-CAUSE
63        <none>
64        <none>
65        <none>
```

## Context

Möglicherweise sollen mehrere Cluster verwaltet werden. Dafür hat Kubernetes sog. Contexte eingeführt. In der Datei `$USER/.kube/config` können mehrere Kontexte definiert werden. Diese bestehen aus

- Cluster
- User

Eine typische kubeconfig Datei sieht folgendermaßen aus

```
apiVersion: v1
kind: Config
clusters:
- cluster:
    server: https://...
    certificate-authority-data: ...
  name: k8s-pes-ciplus-dev
- cluster:
    server: https://...
    certificate-authority-data: ...
  name: k8s-pes-ciplus-prod
users:
- name: k8s-pes-ciplus-dev
  user:
    client-certificate-data: ...
    client-key-data: ...
- name: k8s-pes-ciplus-prod
  user:
    client-certificate-data: ...
    client-key-data: ...
contexts:
- context: k8s-pes-ciplus-dev
    cluster: k8s-pes-ciplus-dev
    user: k8s-pes-ciplus-dev
  name: k8s-pes-ciplus-dev
- context: k8s-pes-ciplus-prod
    cluster: k8s-pes-ciplus-prod
    user: k8s-pes-ciplus-prod
  name: k8s-pes-ciplus-prod
current-context: k8s-pes-ciplus-dev
preferences: {}
```

Man kann dies auch mit `kubectl config current-context` auslesen. Damit bekommt man den aktuellen Cluster auf dem man arbeitet. Möchte man den Cluster wechseln und alle nachfolgenden `kubectl` Befehle an den anderen Cluster senden so
kann man dies mit `kubectl config use-context k8s-pes-ciplus-prod` erreichen.
# Typical Lifecycle for a Java application

![[Diagram.svg]]
CC by Cloud Native Spring in Action

