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

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

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:

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

! CC by Cloud Native Spring in Action

5.7 KiB Raw Permalink Blame History