Kubernetes: Eine umfassende Dokumentation zu Container-Orchestrierung

Die moderne Softwareentwicklung steht vor der Herausforderung, komplexe Anwendungen effizient zu verwalten und zu skalieren. Kubernetes (oft als K8s abgekürzt) hat sich als leistungsfähige Lösung für diese Anforderungen etabliert. Als Open-Source-Plattform ermöglicht Kubernetes die automatisierte Verwaltung, Bereitstellung und Skalierung von containerisierten Anwendungen.

Mit seinen umfangreichen Funktionen wie automatischer Lastverteilung, Self-Healing und flexibler Ressourcenverwaltung bietet Kubernetes die notwendigen Werkzeuge für den Betrieb moderner Cloud-nativer Anwendungen. Die Plattform wurde ursprünglich von Google entwickelt und 2014 der Open-Source-Community übergeben, wo sie sich seitdem kontinuierlich weiterentwickelt

⚠️ Wichtiger Hinweis: Dieser Artikel baut auf den Grundlagen aus unserem Wiki-Artikel "DevOps-Grundlagen: Eine Einführung in die moderne Softwareentwicklung" auf. Grundlegende DevOps-Kenntnisse werden vorausgesetzt:

- Grundlegendes Verständnis von Container-Technologien
- Erfahrung mit Linux-Systemen und der Kommandozeile
- Grundlegendes Verständnis in DevOps-Praktiken

Warum Kubernetes?

In modernen Microservice-Architekturen stehen Entwicklungsteams vor komplexen Herausforderungen:

Verwaltung hunderter oder tausender Container
Automatische Skalierung bei Last
Selbstheilung bei Ausfällen
Rolling Updates ohne Downtime
Load Balancing zwischen Services
Service Discovery in dynamischen Umgebungen

Kubernetes löst diese Herausforderungen durch ein ausgeklügeltes System von Abstraktionen und Automatisierungen.

Architektur und Komponenten

Control Plane (Master Node)

Die Control Plane bildet das „Gehirn“ des Kubernetes-Clusters und besteht aus mehreren kritischen Komponenten:

API Server (kube-apiserver)

Markdown

Client → Authentication → Authorization → Admission Control → API Server → etcd

Der API Server ist der zentrale Kommunikationshub und erfüllt folgende Aufgaben:

REST-Schnittstelle für alle Cluster-Operationen
Authentifizierung und Autorisierung von Anfragen
Validierung von Objektkonfigurationen
Persistenz in etcd

Beispiel einer API-Server Konfiguration:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.10
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    image: k8s.gcr.io/kube-apiserver:v1.24.0
    name: kube-apiserver

etcd

Der verteilte Key-Value Store speichert den gesamten Cluster-Status:

Hochverfügbare Datenspeicherung
Konsistente Datenhaltung durch Raft-Konsensus
Versionierte Speicherung aller Kubernetes-Objekte

Beispiel einer etcd-Konfiguration:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: etcd
  namespace: kube-system
spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://192.168.1.10:2379
    - --data-dir=/var/lib/etcd
    - --initial-cluster-state=new
    - --initial-cluster-token=etcd-cluster
    image: k8s.gcr.io/etcd:3.5.3-0
    name: etcd

Scheduler (kube-scheduler)

Der Scheduler ist verantwortlich für die intelligente Platzierung von Pods:

Ressourcenanalyse der Worker Nodes
Berücksichtigung von Affinität/Anti-Affinität
Priorisierung basierend auf definierten Policies

Scheduling-Algorithmus:

Markdown

Pod Creation → Filtering → Scoring → Binding
   ↑                                   |
   └───────────────(Failure)───────────┘

Controller Manager (kube-controller-manager)

Der Controller Manager implementiert die Kernlogik des Kubernetes Control Loops:

Node Controller: Überwacht den Zustand der Nodes
Replication Controller: Stellt sicher, dass die gewünschte Anzahl von Pods läuft
Endpoints Controller: Verknüpft Services mit Pods
Service Account & Token Controller: Verwaltet Zugriffstoken

Markdown

Control Loop Struktur:
┌──────────────────┐
│ Desired State    │
│ (Configuration)  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Current State    │◄────┐
│ (Observation)    │     │
└────────┬─────────┘     │
         ↓               │
┌──────────────────┐     │
│ Actions          │     │
│ (Reconciliation) │     │
└────────┬─────────┘     │
         └───────────────┘

Beispiel einer Controller-Manager Konfiguration:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --bind-address=127.0.0.1
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --cluster-cidr=10.244.0.0/16
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    image: k8s.gcr.io/kube-controller-manager:v1.24.0
    name: kube-controller-manager

Worker Node Komponenten

Kubelet

Der Kubelet ist der primäre Node-Agent:

Pod-Lifecycle-Management
Container Health Checks
Volume-Mounting
Node-Status-Reporting

Beispiel einer Kubelet-Konfiguration:

YAML

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "0.0.0.0"
port: 10250
serializeImagePulls: true
evictionHard:
  memory.available: "100Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"

Container Runtime

Die Container Runtime (z.B. containerd) ist verantwortlich für:

Container-Ausführung
Image-Management
Container-Isolation

Containerd Konfiguration:

YAML

version = 2
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "k8s.gcr.io/pause:3.6"
  [plugins."io.containerd.grpc.v1.cri".containerd]
    default_runtime_name = "runc"
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      runtime_type = "io.containerd.runc.v2"

Kube-proxy

Kube-proxy implementiert das Kubernetes Service-Konzept:

Service-Load-Balancing
IP-Tables-Regeln
Session Affinity

YAML

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
bindAddress: 0.0.0.0
clientConnection:
  acceptContentTypes: ""
  burst: 10
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
  qps: 5
clusterCIDR: 10.244.0.0/16
mode: "ipvs"

Installation und Setup

⚠️ Wichtiger Hinweis: In diesem Artikel verwenden wir Ubuntu/Debian als Beispiel-Distribution. Die grundlegenden Konzepte sind auf allen Linux-Systemen gleich, aber die Installation von Paketen und einige Konfigurationspfade können sich je nach Distribution unterscheiden. Wenn du eine andere Distribution verwendest, konsultiere bitte die entsprechende Dokumentation für die spezifischen Installationsbefehle und Pfade.

Voraussetzungen

Bevor wir mit der eigentlichen Installation beginnen, ist es wichtig zu verstehen, welche Anforderungen ein Kubernetes-Cluster an die Hardware und Software stellt. Ein produktiver Cluster besteht typischerweise aus mehreren Nodes, die verschiedene Rollen erfüllen.

Markdown

Cluster-Komponenten
┌─────────────────────┐
│   Control Plane     │
├─────────────────────┤
│ • API Server        │
│ • etcd              │
│ • Scheduler         │
│ • Controller Mgr    │
└────────┬────────────┘
         │
    ┌────┴────┐
    │ Worker  │
    │ Nodes   │
    └─────────┘

Hardwareanforderungen

Die Hardwareanforderungen variieren je nach Einsatzzweck und erwarteter Last. Hier sind die Mindestanforderungen für verschiedene Szenarien:

Control Plane Node (Master):

CPU:
- Minimum: 2 Cores
- Empfohlen: 4 Cores
- Produktiv: 8+ Cores
RAM:
- Minimum: 2 GB
- Empfohlen: 4 GB
- Produktiv: 16+ GB
Festplatte:
- Minimum: 50 GB
- Empfohlen: 100 GB
- Produktiv: 250+ GB (SSD empfohlen)

Worker Nodes:

CPU:
- Minimum: 1 Core
- Empfohlen: 2 Cores
- Produktiv: 4+ Cores
RAM:
- Minimum: 1 GB
- Empfohlen: 2 GB
- Produktiv: 8+ GB
Festplatte:
- Minimum: 20 GB
- Empfohlen: 50 GB
- Produktiv: 100+ GB

⚠️ Wichtige Hinweise zur Planung:
- Plane die Cluster-Größe entsprechend deiner Workloads
- Berücksichtige Hochverfügbarkeitsanforderungen
- Beachte Network-Policy-Anforderungen
- Plane Storage-Ressourcen sorgfältig

Softwareanforderungen

Kubernetes stellt spezifische Anforderungen an das Betriebssystem und dessen Konfiguration:

Betriebssystem:

Bash

# Überprüfung der Ubuntu-Version
lsb_release -a

# Mindestanforderungen:
# - Ubuntu 20.04 LTS oder neuer
# - Linux-Kernel 3.10 oder höher
uname -r

Systemkonfiguration:

Der Linux-Kernel muss bestimmte Module und Parameter aktiviert haben:

Bash

# Überprüfung der erforderlichen Kernel-Module
lsmod | grep -e br_netfilter -e overlay

# Falls nicht geladen, Module aktivieren:
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
overlay
EOF

modprobe br_netfilter
modprobe overlay

Netzwerkkonfiguration

Des weiteren benötigt Kubernetes spezielle Netzwerkeinstellungen:

Bash

# Kernel-Parameter für Kubernetes
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# Parameter aktivieren
sysctl --system

# Überprüfung
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.bridge.bridge-nf-call-ip6tables
sysctl net.ipv4.ip_forward

Installation der Grundkomponenten

Bevor wir mit der eigentlichen Kubernetes-Installation beginnen, müssen wir sicherstellen, dass alle notwendigen Systemkomponenten installiert und korrekt konfiguriert sind.

Systemvorbereitung

Zunächst aktualisieren wir das System und installieren wichtige Basispakete:

Bash

# System aktualisieren
sudo apt update
sudo apt upgrade -y

# Notwendige Basispakete installieren
sudo apt install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release \
    software-properties-common

⚠️ Wichtig: Nach dem Systemupdate solltest du prüfen, ob ein Neustart erforderlich ist und stelle sicher, dass swap deaktiviert ist:

Bash

# Swap deaktivieren
sudo swapoff -a

# Swap-Eintrag aus /etc/fstab entfernen
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

Bash

# Prüfen, ob ein Neustart erforderlich ist
if [ -f /var/run/reboot-required ]; then
    echo 'Neustart erforderlich!'
fi

Container Runtime Installation

Kubernetes benötigt eine Container Runtime. Wir verwenden containerd, da es der aktuelle Standard ist:

Bash

# Docker Repository hinzufügen
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# containerd installieren
sudo apt update
sudo apt install -y containerd.io

Konfiguration von containerd:

Bash

# Standard-Konfiguration erstellen
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# SystemdCgroup aktivieren
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# containerd neu starten
sudo systemctl restart containerd
sudo systemctl enable containerd

⚠️ Best Practices für containerd:

Konfiguriere SystemdCgroup
Setze angemessene Resource Limits
Aktiviere Log Rotation

Kubernetes-Komponenten Installation

Jetzt können wir die eigentlichen Kubernetes-Komponenten installieren:

Bash

# Kubernetes Repository hinzufügen
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

# Kubernetes-Komponenten installieren
sudo apt update
sudo apt install -y kubelet kubeadm kubectl

# Versionen pinnen um ungewollte Updates zu verhindern
sudo apt-mark hold kubelet kubeadm kubectl

⚠️ Wichtig: Überprüfe die installierten Versionen:

Bash

kubectl version --client
kubeadm version
kubelet --version

⚠️ Typische Fallstricke:

Vergessen der Kernel-Module Aktivierung
Inkorrekte Netzwerk-Konfiguration
Unzureichende Ressourcen

Cluster-Initialisierung

Control Plane Setup

Die Cluster-Initialisierung ist ein kritischer Schritt beim Aufbau eines Kubernetes-Clusters. Hier ist eine detaillierte Anleitung mit Best Practices und typischen Fallstricken.

Markdown

Cluster-Initialisierung
┌─────────────────────┐     ┌─────────────────────┐
│   Control Plane     │ ──► │   Worker Nodes      │
│ • kubeadm init      │     │ • kubeadm join      │
│ • CNI Installation  │     │ • Node Labels       │
└─────────────────────┘     └─────────────────────┘
         │                           │
         └───────────► Netzwerk ◄────┘
                  • Calico CNI
                  • Network Policies

Control Plane Initialisierung

⚠️ Vor der Initialisierung prüfen:

Alle Voraussetzungen erfüllt
Ausreichend Ressourcen verfügbar
Netzwerk-Ports erreichbar
Hostname und DNS korrekt konfiguriert

Bash

# Cluster initialisieren
sudo kubeadm init \
    --pod-network-cidr=192.168.0.0/16 \
    --kubernetes-version=$(kubeadm version -o short) \
    --control-plane-endpoint="$(hostname -I | awk '{print $1}')" \
    --upload-certs

# kubeconfig für den aktuellen Benutzer einrichten
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

⚠️ Wichtige Hinweise zur Cluster-Initialisierung:

Notiere dir den kubeadm join-Befehl, der am Ende der Initialisierung ausgegeben wird
Sichere die Zertifikate und Token-Informationen
Der Control Plane Node ist standardmäßig nicht für Workloads vorgesehen

Netzwerk-Plugin Installation

Wir verwenden Calico als CNI-Plugin aufgrund seiner Flexibilität und fortgeschrittenen Netzwerkfunktionen:

Bash

# Calico Operator installieren
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/tigera-operator.yaml

# Calico Custom Resources erstellen
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/custom-resources.yaml

Network Policy Konfiguration

YAML

# Beispiel einer grundlegenden Network Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

⚠️ Typische Fallstricke bei der Netzwerkkonfiguration:

Überlappende Pod-CIDR-Bereiche
Fehlende Network Policies
Inkorrekte MTU-Einstellungen
DNS-Probleme

Überprüfung der Installation:

Bash

# Cluster-Status überprüfen
kubectl get nodes
kubectl get pods --all-namespaces
kubectl cluster-info

# CNI-Status überprüfen
kubectl get pods -n calico-system

Worker Node Integration

Die Integration von Worker Nodes ist entscheidend für die Skalierbarkeit des Clusters. Hier erfährst du, wie du Worker Nodes korrekt vorbereitest und in den Cluster integrierst.

Markdown

Worker Node Setup Flow
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Vorbereitung    │ ──► │ Integration     │ ──► │ Validierung     │
│ • System-Setup  │     │ • Node Join     │     │ • Node Status   │
│ • Runtime       │     │ • Labels        │     │ • Pod Placement │
│ • Kubernetes    │     │ • Taints        │     │ • Networking    │
└─────────────────┘     └─────────────────┘     └─────────────────┘

Worker Node Vorbereitung

Führe auf jedem Worker Node die gleichen Vorbereitungsschritte aus:

Bash

# Systemaktualisierung und Basispaketinstallation
sudo apt update && sudo apt upgrade -y
sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release

# Container Runtime (containerd) Installation
# (Gleiche Schritte wie beim Control Plane Node)
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y containerd.io

⚠️ Wichtige Vorbereitungsschritte:

Hostname eindeutig setzen
Firewall-Regeln anpassen
Ressourcen überprüfen
SELinux/AppArmor konfigurieren

Worker Node Konfiguration

Konfiguriere containerd und Kubernetes-Komponenten:

Bash

# containerd konfigurieren
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

# Kubernetes-Komponenten installieren
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Worker Node Join

Verbinde den Worker Node mit dem Cluster:

Bash

# Token auf dem Control Plane Node generieren
kubeadm token create --print-join-command

# Auf dem Worker Node ausführen
sudo kubeadm join <control-plane-ip>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

⚠️ Wichtige Hinweise:

Der Join-Befehl muss mit Root-Rechten ausgeführt werden
Token sind standardmäßig 24 Stunden gültig

Bei abgelaufenem Token kann ein neuer erstellt werden:

Bash

# Auf dem Control Plane Node:
kubeadm token create --print-join-command

Node Labels und Taints

YAML

# Node Labeling für spezifische Workloads
kubectl label node worker-1 workload=production
kubectl label node worker-2 workload=staging

# Taint für dedizierte Workloads
kubectl taint nodes worker-1 dedicated=production:NoSchedule

⚠️ Best Practices für Node Management:

Implementiere systematische Naming-Konventionen
Nutze Labels für Workload-Segregation
Plane Node-Kapazitäten sorgfältig
Implementiere Node Auto-Scaling

Validierung und Troubleshooting

Bash

# Node-Status überprüfen
kubectl get nodes -o wide

# Node-Details anzeigen
kubectl describe node worker-1

# System-Komponenten Status
kubectl get pods -n kube-system

Erweiterte Netzwerkkonfiguration

Netzwerk-Policies

Konfiguration von Netzwerk-Policies für die Cluster-Sicherheit:

YAML

# Beispiel einer grundlegenden Network Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Service-Netzwerk Konfiguration

Einrichtung des Service-CIDR und Cluster-DNS:

Bash

# Überprüfung der Service-CIDR-Konfiguration
kubectl cluster-info dump | grep -m 1 service-cluster-ip-range

# CoreDNS Status überprüfen
kubectl get pods -n kube-system -l k8s-app=kube-dns

Load Balancing

Konfiguration des externen Load Balancings:

YAML

# Beispiel eines LoadBalancer Services
apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: example

Überprüfung der Installation

Abschließende Kontrollen des Cluster-Status:

Bash

# Überprüfung der Node-Status
kubectl get nodes -o wide

# Überprüfung der System-Pods
kubectl get pods --all-namespaces

# Cluster-Komponenten Status
kubectl get componentstatuses

# Netzwerk-Funktionalität testen
kubectl run test-pod --image=busybox -- sleep 3600
kubectl exec test-pod -- ping -c 3 8.8.8.8

⚠️ Wichtig: Dokumentiere alle durchgeführten Konfigurationsschritte und bewahre wichtige Informationen wie Tokens und Zertifikate sicher auf.

Praktische Implementierung

In diesem Abschnitt lernen wir die praktische Anwendung von Kubernetes kennen. Wir werden verschiedene Deployment-Strategien, Service-Konfigurationen und Storage-Management-Optionen im Detail betrachten.

Markdown

Kubernetes Ressourcen
┌─────────────────┐
│   Workloads     │
├─────────────────┤
│ • Pods          │
│ • Deployments   │
│ • StatefulSets  │
│ • DaemonSets    │
└─────────────────┘

Deployment-Strategien

Kubernetes bietet verschiedene Strategien für das Deployment von Anwendungen. Die Wahl der richtigen Strategie ist entscheidend für die Verfügbarkeit und Zuverlässigkeit deiner Anwendungen.

⚠️ Best Practices für Deployments:

Setze immer Resource Limits
Definiere Readiness/Liveness Probes
Nutze Labels für bessere Organisation
Plane Update-Strategien sorgfältig

Rolling Updates

Rolling Updates sind die Standardstrategie in Kubernetes und ermöglichen Updates ohne Downtime:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Maximale Anzahl zusätzlicher Pods
      maxUnavailable: 1  # Maximale Anzahl nicht verfügbarer Pods
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

⚠️ Wichtige Hinweise zum Rolling Update:

Die Parameter maxSurge und maxUnavailable bestimmen die Update-Geschwindigkeit
Readiness Probes sind kritisch für erfolgreiche Rolling Updates
Setze Resource Limits und Requests für vorhersehbares Verhalten

Blue-Green Deployments

Blue-Green Deployments ermöglichen risikoarme Updates durch parallele Umgebungen:

YAML

# Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Service für Blue-Green Switch
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue  # Ändern zu 'green' für Switch
  ports:
  - port: 80
    targetPort: 8080

Canary Deployments

Canary Deployments ermöglichen das schrittweise Testen neuer Versionen mit einem Teil des Traffics:

YAML

# Stable Deployment (90% Traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-stable
spec:
  replicas: 9  # 90% der Pods
  selector:
    matchLabels:
      app: myapp
      version: stable
  template:
    metadata:
      labels:
        app: myapp
        version: stable
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
---
# Canary Deployment (10% Traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1  # 10% der Pods
  selector:
    matchLabels:
      app: myapp
      version: canary
  template:
    metadata:
      labels:
        app: myapp
        version: canary
    spec:
      containers:
      - name: myapp
        image: myapp:2.0

⚠️ Wichtig für Canary Deployments:

Implementiere gründliches Monitoring
Plane Rollback-Strategien
Nutze Service Mesh für feingranulare Traffic-Kontrolle

Service- und Ingress-Konfiguration

Markdown

Traffic Flow
┌──────────┐     ┌─────────┐     ┌─────────┐
│ Ingress  │ ──► │ Service │ ──► │  Pods   │
└──────────┘     └─────────┘     └─────────┘

Service Types

Services ermöglichen die Kommunikation zwischen Pods und die Exposition von Anwendungen. Ingress bietet Layer-7 Routing für externen Zugriff.

⚠️ Wichtig: Wähle den Service-Typ basierend auf deinen Anforderungen:

ClusterIP: Intern
NodePort: Direkt über Node-Ports
LoadBalancer: Cloud-Provider Integration

YAML

# ClusterIP (Default)
apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080
---
# NodePort
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: NodePort
  selector:
    app: frontend
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080  # Port zwischen 30000-32767
---
# LoadBalancer
apiVersion: v1
kind: Service
metadata:
  name: public-service
spec:
  type: LoadBalancer
  selector:
    app: public
  ports:
  - port: 80
    targetPort: 8080

Ingress-Konfiguration

Ingress ermöglicht Layer-7 Routing und SSL-Terminierung:

YAML

# Ingress Controller Installation (nginx)
apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
---
# Ingress Resource
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

⚠️ Best Practices:

Konfiguriere SSL/TLS
Setze Rate Limiting
Implementiere Pfad-basiertes Routing
Nutze sinnvolle Annotations

Service Mesh Integration

Beispiel für Istio Service Mesh Integration:

YAML

# Virtual Service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Storage-Management

Persistent Volumes

Persistenter Storage ist essentiell für zustandsbehaftete Anwendungen in Kubernetes. Die richtige Konfiguration sichert Datenpersistenz und Performance.

Markdown

Storage Architektur
┌───────────────┐     ┌───────────────┐
│ StorageClass  │ ──► │ PersistentVol │
└───────────────┘     └───────────────┘
        ▲                    ▲
        │                    │
┌───────────────┐     ┌───────────────┐
│ Application   │ ◄── │ PVC           │
└───────────────┘     └───────────────┘

Persistent Volume

YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /mnt/data
---
# Persistent Volume Claim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

Storage Classes

Storage Classes definieren verschiedene Speichertypen und deren Eigenschaften. Sie ermöglichen die dynamische Bereitstellung von Persistent Volumes basierend auf den Anforderungen der Anwendungen.

YAML

# Definition einer Storage Class für SSD-Storage
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs  # Beispiel für AWS
parameters:
  type: gp3
  iopsPerGB: "10"
  encrypted: "true"
reclaimPolicy: Retain
allowVolumeExpansion: true

⚠️ Wichtige Hinweise zu Storage Classes:

Der Provisioner hängt von deiner Cloud-Plattform oder Storage-Lösung ab
Parameter variieren je nach Provisioner
Der ReclaimPolicy bestimmt, was mit dem Volume nach dem Löschen des PVC passiert

Volume Snapshots

Snapshots ermöglichen Backups und Point-in-Time-Recovery von Persistent Volumes:

YAML

# Volume Snapshot Class
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-hostpath-snapclass
driver: hostpath.csi.k8s.io
deletionPolicy: Delete
---
# Volume Snapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-snapshot
spec:
  volumeSnapshotClassName: csi-hostpath-snapclass
  source:
    persistentVolumeClaimName: example-pvc

Erweiterte Storage-Konfigurationen

Multi-Path Storage

Für hochverfügbare Storage-Konfigurationen:

YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: multipath-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - _netdev
    - multipath
  fc:
    targetWWNs:
      - "50060e801049cfd1"
      - "50060e801049cfd2"
    lun: 0
    fsType: ext4

Verschlüsselter Storage

Implementation von verschlüsseltem Storage mit LUKS:

YAML

# Secret für Verschlüsselungsschlüssel
apiVersion: v1
kind: Secret
metadata:
  name: luks-key
type: Opaque
data:
  key: <base64-encoded-key>
---
# Encrypted PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: encrypted-pv
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  encryption:
    secretRef:
      name: luks-key
  hostPath:
    path: /mnt/encrypted-data

⚠️ Wichtige Sicherheitshinweise:

Verschlüsselungsschlüssel müssen sicher verwaltet werden
Regelmäßige Backup-Strategien implementieren
Zugriffsrechte sorgfältig konfigurieren

Storage Monitoring und Wartung

Implementation von Storage-Monitoring:

YAML

# Prometheus StorageClass Monitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: storage-monitor
spec:
  selector:
    matchLabels:
      k8s-app: storage-provisioner
  endpoints:
  - port: metrics

Monitoring-Metriken die du im Auge behalten solltest:

Speicherauslastung
I/O-Performance
Latenzzeiten
Fehlerraten
Snapshot-Status

Best Practices für Storage-Management

Kapazitätsplanung:
- Implementiere proaktives Monitoring
- Plane Wachstum voraus
- Setze sinnvolle Quotas
Backup-Strategien:
- Regelmäßige Snapshots
- Off-site Backups
- Disaster Recovery Tests
Performance-Optimierung:
- Wähle passende Storage-Klassen
- Optimiere Chunk-Größen
- Implementiere Caching wo sinnvoll

Monitoring und Wartung

Das Monitoring und die Wartung eines Kubernetes-Clusters sind entscheidend für den stabilen Betrieb. In diesem Abschnitt lernen wir die verschiedenen Aspekte des Cluster-Monitorings und der proaktiven Wartung kennen.

Markdown

Monitoring & Wartung
┌─────────────────┐     ┌─────────────────┐
│   Monitoring    │     │    Wartung      │
├─────────────────┤     ├─────────────────┤
│ • Metriken      │     │ • Updates       │
│ • Alerts        │     │ • Backups       │
│ • Performance   │     │ • Cleaning      │
└─────────────────┘     └─────────────────┘

Monitoring-Architektur

Eine typische Kubernetes-Monitoring-Architektur besteht aus mehreren Komponenten:

Markdown

┌─────────────────────────────────────────────┐
│           Grafana Dashboard                 │
├─────────────────────────────────────────────┤
│                                             │
│  ┌──────────────┐    ┌──────────────┐       │
│  │   Prometheus │    │ AlertManager │       │
│  └──────┬───────┘    └─────┬────────┘       │
│         │                  │                │
│  ┌──────┴───────┐    ┌─────┴────────┐       │
│  │  Node        │    │  Container   │       │
│  │  Exporter    │    │  Exporter    │       │
│  └──────────────┘    └──────────────┘       │
│                                             │
└─────────────────────────────────────────────┘

Prometheus Installation

Prometheus ist das De-facto-Standard-Tool für Kubernetes-Monitoring. Installation über den Prometheus Operator:

YAML

# Namespace erstellen
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring

---
# Prometheus Operator Installation
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-operator
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-operator
  template:
    metadata:
      labels:
        app: prometheus-operator
    spec:
      containers:
      - name: prometheus-operator
        image: quay.io/prometheus-operator/prometheus-operator:v0.59.1
        args:
        - --kubelet-service=kube-system/kubelet
        - --config-reloader-image=jimmidyson/configmap-reload:v0.5.0

⚠️ Wichtige Hinweise zur Prometheus-Installation:

Stelle sicher, dass genügend Ressourcen verfügbar sind
Konfiguriere Retention Policies entsprechend deiner Anforderungen
Plane die Skalierung der Storage-Anforderungen

Monitoring-Konfiguration

Service Monitoring

Definition eines ServiceMonitors für Custom Metrics:

YAML

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

Alert Rules

Definition von Alerting-Regeln:

YAML

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node-alerts
  namespace: monitoring
spec:
  groups:
  - name: node.rules
    rules:
    - alert: HighCPUUsage
      expr: node_cpu_usage_percentage > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        description: "CPU usage is above 80% for 5 minutes"

Grafana Dashboards

Visualisierung der Metriken durch Grafana:

Markdown

┌─────────────────────────────────────────────┐
│ Cluster Overview                            │
├────────────────┬───────────────┬────────────┤
│ CPU Usage      │ Memory Usage  │ Network    │
│ ▄█████████▋    │ ▄█████▋       │ ▄███▋      │
│ 95%            │ 55%           │ 35%        │
├────────────────┼───────────────┼────────────┤
│ Pod Status     │ Node Status   │ Storage    │
│ Running: 45    │ Ready: 5      │ Used: 70%  │
│ Failed: 2      │ NotReady: 0   │ Free: 30%  │
└────────────────┴───────────────┴────────────┘

Alerting und Benachrichtigungen

Ein effektives Alerting-System ist entscheidend für proaktives Monitoring. Hier ein Beispiel für eine umfassende Alert-Konfiguration:

YAML

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-alerts
  namespace: monitoring
spec:
  groups:
  - name: kubernetes.rules
    rules:
    - alert: KubernetesPodCrashLooping
      expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
      for: 15m
      labels:
        severity: warning
      annotations:
        description: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"
        summary: "Pod is crash looping"

⚠️ Wichtige Hinweise zum Alerting:

Definiere sinnvolle Schwellenwerte
Vermeide Alert-Fatigue durch zu viele Benachrichtigungen
Implementiere Escalation Paths

Performance-Monitoring

Visualisierung der Performance-Metriken:

Markdown

Performance Dashboard
┌────────────────────────────────────┐
│ Node Performance                   │
├──────────────┬───────────┬─────────┤
│ CPU Usage    │ Memory    │ Disk    │
│ ▇▇▇▇▇░░░░░   │ ▇▇▇░░░░░░ │ ▇▇░░░░  │
│ 50%          │ 35%       │ 20%     │
└──────────────┴───────────┴─────────┘

Resource Quotas Monitoring

YAML

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

Log-Aggregation

Implementation einer zentralen Logging-Lösung:

Markdown

Log Flow Architecture
Source → Collection → Processing → Storage → Analysis
 │         │            │           │          │
 ├─ Pods   ├─ Fluentd   ├─ Logstash ├─ Elastic ├─ Kibana
 ├─ Nodes  ├─ Vector    ├─ Filters  ├─ Loki    ├─ Grafana
 └─ Apps   └─ Filebeat  └─ Parse    └─ S3      └─ Alerts

Wartungsstrategien

Die regelmäßige Wartung eines Kubernetes-Clusters ist essentiell für einen stabilen Betrieb. Hier behandeln wir die wichtigsten Aspekte der Cluster-Wartung.

Cluster-Updates

Ein strukturierter Update-Prozess ist entscheidend für die Systemstabilität:

Markdown

Update-Prozess Workflow
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  Vorbereitung   │ ──► │    Update       │ ──► │   Validierung   │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                       │                        │
        ▼                       ▼                        ▼
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Backup erstellen│     │Node Drain/Cordon│     │ Tests ausführen │
│ Plan erstellen  │     │Komponenten-     │     │ Monitoring      │
│ Change-Window   │     │  Updates        │     │ Rollback-Plan   │
└─────────────────┘     └─────────────────┘     └─────────────────┘

Update-Prozedur für Control Plane

Bash

# 1. Backup wichtiger Komponenten
ETCD_BACKUP_DIR="/backup/etcd-$(date +%Y%m%d)"
mkdir -p $ETCD_BACKUP_DIR

# etcd Snapshot erstellen
kubectl exec -n kube-system etcd-master-1 -- etcdctl snapshot save \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  $ETCD_BACKUP_DIR/etcd-snapshot.db

⚠️ Wichtige Hinweise zum Update-Prozess:

Führe Updates immer zuerst in einer Testumgebung durch
Plane ausreichende Wartungsfenster ein
Halte Rollback-Prozeduren bereit
Dokumentiere jeden Schritt sorgfältig

Node Maintenance

Systematische Wartung der Cluster-Nodes:

YAML

# Node Drain Beispiel
apiVersion: v1
kind: Pod
metadata:
  name: node-maintenance
  namespace: kube-system
spec:
  serviceAccountName: node-maintenance
  containers:
  - name: kubectl
    image: bitnami/kubectl:latest
    command:
    - /bin/sh
    - -c
    - |
      kubectl drain node-01 \
        --ignore-daemonsets \
        --delete-emptydir-data \
        --force

Backup und Recovery

Implementation einer robusten Backup-Strategie:

Markdown

Backup-Komponenten
┌────────────────────────────────────────────────┐
│               Backup-Strategie                 │
├────────────────┬────────────────┬──────────────┤
│  etcd Daten    │  Kubernetes    │ Anwendungs-  │
│                │  Manifeste     │   daten      │
├────────────────┼────────────────┼──────────────┤
│ - Snapshots    │ - GitOps Repo  │ - PV/PVC     │
│ - Intervalle   │ - Helm Charts  │ - Snapshots  │
│ - Retention    │ - Secrets      │ - Backups    │
└────────────────┴────────────────┴──────────────┘

Automatisiertes Backup-Script:

Bash

#!/bin/bash
# Backup-Script für kritische Cluster-Komponenten

# Variablen
BACKUP_DIR="/backup/k8s-$(date +%Y%m%d)"
RETENTION_DAYS=30

# Verzeichnisstruktur erstellen
mkdir -p "${BACKUP_DIR}"/{etcd,manifests,secrets}

# etcd Backup
etcdctl snapshot save "${BACKUP_DIR}/etcd/snapshot.db"

# Kubernetes Manifeste sichern
kubectl get all --all-namespaces -o yaml > \
  "${BACKUP_DIR}/manifests/all-resources.yaml"

# Secrets sichern (verschlüsselt)
kubectl get secrets --all-namespaces -o yaml | \
  gpg --encrypt > "${BACKUP_DIR}/secrets/all-secrets.yaml.gpg"

# Alte Backups bereinigen
find /backup -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} +

Metriken-Erfassung

Die systematische Erfassung von Metriken ist essentiell für ein effektives Kubernetes-Monitoring. Hier sind die wichtigsten Bereiche:

Cluster-Metriken

Markdown

Cluster-Metriken Übersicht
┌─────────────────────────────────────────┐
│ Cluster Health                          │
├───────────────┬─────────────┬───────────┤
│ Node Status   │ Pod Status  │ Services  │
│ Available: 5  │ Running: 45 │ Up: 12    │
│ NotReady: 0   │ Failed: 2   │ Down: 0   │
└───────────────┴─────────────┴───────────┘

Wichtige Cluster-Metriken:

Node-Verfügbarkeit
Cluster-Kapazität
API-Server-Latenz
etcd-Performance

Resource-Metriken

YAML

apiVersion: v1
kind: Pod
metadata:
  name: resource-monitor
spec:
  containers:
  - name: prometheus-exporter
    image: prom/node-exporter
    ports:
    - containerPort: 9100
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Sicherheit und Best Practices

Die Sicherheit eines Kubernetes-Clusters ist von entscheidender Bedeutung. In diesem Abschnitt behandeln wir die wichtigsten Sicherheitsaspekte und Best Practices für den produktiven Einsatz.

RBAC (Role-Based Access Control)

RBAC ist das primäre Zugriffskontrollsystem in Kubernetes:

Markdown

RBAC Hierarchie
┌─────────────────────────────────────┐
│            RBAC System              │
├─────────────┬───────────┬───────────┤
│   Roles     │ClusterRoles│ Subjects │
├─────────────┼───────────┼───────────┤
│Permissions  │Namespace   │Users     │
│Rules        │Übergreifend│Groups    │
│Namespace    │Cluster-weit│ServiceAcc│
└─────────────┴───────────┴───────────┘

Role Definition

YAML

# Namespace-spezifische Rolle
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# Cluster-weite Rolle
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader-global
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

⚠️ Wichtige RBAC-Prinzipien:

Principle of Least Privilege
Regelmäßige Audit-Reviews
Dokumentation aller Rollen und Berechtigungen

Pod Security Policies

Definition von Sicherheitsrichtlinien für Pods:

YAML

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: RunAsAny
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'persistentVolumeClaim'

Network Policies

Markdown

Network Policy Übersicht
┌──────────────┐      ┌──────────────┐
│ Frontend Pod │ ───► │ Backend Pod  │
└──────────────┘      └──────────────┘
       ▲                     ▲
       │                     │
┌──────────────┐      ┌──────────────┐
│ Ingress      │      │ Allow from   │
│ Traffic      │      │ Frontend     │
└──────────────┘      └──────────────┘

Beispiel einer Network Policy:

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Secrets Management

Sichere Verwaltung von sensiblen Daten:

YAML

# Secret Definition
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  db-password: BASE64_ENCODED_PASSWORD
  api-key: BASE64_ENCODED_API_KEY

⚠️ Best Practices für Secrets:

Verschlüsselung im Ruhezustand
Regelmäßige Rotation
Zugriffsbeschränkung
Audit-Logging

Container Security

Container-Sicherheit ist ein fundamentaler Aspekt der Kubernetes-Sicherheit. Hier sind die wichtigsten Praktiken:

Markdown

Container Security Layers
┌─────────────────────────────────────┐
│           Container Image           │
├─────────────────┬───────────┬───────┤
│  Base Image     │ Libraries │ App   │
│  Vulnerabilities│ Security  │ Code  │
└─────────────────┴───────────┴───────┘
         ▼             ▼         ▼
┌─────────────────────────────────────┐
│         Security Controls           │
│ • Image Scanning                    │
│ • Trusted Registries                │
│ • Image Signing                     │
└─────────────────────────────────────┘

Image Scanning

YAML

apiVersion: aquasecurity.github.io/v1alpha1
kind: ImageScan
metadata:
  name: nginx-scan
spec:
  image: nginx:latest
  failOnCritical: true
  scanOnPush: true
  webhookURL: "https://security-team-webhook"

Cluster Hardening

Implementiere diese kritischen Sicherheitsmaßnahmen für den Cluster:

YAML

# Pod Security Policy
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535

Audit Logging

Konfiguration des Audit-Loggings für bessere Sicherheitskontrolle:

YAML

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["pods", "services"]
- level: Metadata
  resources:
  - group: ""
    resources: ["configmaps"]
- level: None
  users: ["system:kube-proxy"]
  resources:
  - group: ""
    resources: ["endpoints"]

Compliance und Sicherheits-Best-Practices

Die Einhaltung von Sicherheitsstandards und Best Practices ist entscheidend für einen sicheren Kubernetes-Betrieb.

Security Compliance Framework

Markdown

Compliance Übersicht
┌──────────────────────────────────────────┐
│           Security Standards             │
├──────────────┬─────────────┬─────────────┤
│    CIS       │    NIST     │   DSGVO     │
│ Benchmarks   │ Framework   │ Compliance  │
├──────────────┼─────────────┼─────────────┤
│ • K8s Setup  │ • Controls  │ • Data      │
│ • Hardening  │ • Policies  │ • Privacy   │
│ • Monitoring │ • Response  │ • Rights    │
└──────────────┴─────────────┴─────────────┘

CIS Kubernetes Benchmark

Implementierung der CIS-Richtlinien:

YAML

# API Server Security Configuration
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --anonymous-auth=false
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-log-path=/var/log/audit.log
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction,PodSecurityPolicy
    - --encryption-provider-config=/etc/kubernetes/encryption/config.yaml
    name: kube-apiserver

Sicherheits-Checkliste

Markdown

Security Checklist
┌────────────────────────────────┐
│ Tägliche Überprüfungen         │
├────────────────────────────────┤
│ □ Pod Security Policies        │
│ □ Network Policies             │
│ □ RBAC Konfiguration           │
│ □ Secret Management            │
│ □ Container Vulnerabilities    │
│ □ Audit Logs                   │
└────────────────────────────────┘

Automatisierte Sicherheitsprüfungen

YAML

# Kube-bench Job für automatisierte CIS-Checks
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    spec:
      hostPID: true
      containers:
      - name: kube-bench
        image: aquasec/kube-bench:latest
        command: ["kube-bench", "--benchmark", "cis-1.6"]
        volumeMounts:
        - name: var-lib-kubelet
          mountPath: /var/lib/kubelet
        - name: etc-systemd
          mountPath: /etc/systemd
        - name: etc-kubernetes
          mountPath: /etc/kubernetes
      restartPolicy: Never
      volumes:
      - name: var-lib-kubelet
        hostPath:
          path: "/var/lib/kubelet"
      - name: etc-systemd
        hostPath:
          path: "/etc/systemd"
      - name: etc-kubernetes
        hostPath:
          path: "/etc/kubernetes"

Regelmäßige Sicherheitsaudits

Implementierung von automatisierten Sicherheitsaudits:

YAML

# Falco Security Rules
apiVersion: falco.security.dev/v1beta1
kind: FalcoRule
metadata:
  name: privilege-escalation
spec:
  rule: |
    - rule: Detect Privilege Escalation
      desc: Detect attempts to escalate privileges
      condition: >
        evt.type = setuid and evt.dir = < and
        proc.name != "sudo" and proc.name != "su"
      output: "Privilege escalation attempt (user=%user.name command=%proc.cmdline)"
      priority: WARNING

Fortgeschrittene Konzepte

Die fortgeschrittenen Konzepte in Kubernetes ermöglichen es, die Plattform zu erweitern und komplexere Anwendungsfälle zu realisieren.

Custom Resources

Custom Resources (CRs) erweitern die Kubernetes API um benutzerdefinierte Ressourcentypen.

Markdown

Custom Resource Architektur
┌─────────────────────────────────────┐
│        Custom Resource (CR)         │
├─────────────┬───────────┬───────────┤
│ Definition  │ Validation│ Controller│
│    (CRD)    │  Schema   │  Logic    │
└─────────────┴───────────┴───────────┘
        │           │           │
        ▼           ▼           ▼
┌─────────────────────────────────────┐
│      Kubernetes API Server          │
└─────────────────────────────────────┘

Custom Resource Definition (CRD)

YAML

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webapps.mycompany.com
spec:
  group: mycompany.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                image:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
  scope: Namespaced
  names:
    plural: webapps
    singular: webapp
    kind: WebApp
    shortNames:
    - wa

Operators

Operators automatisieren die Verwaltung komplexer Anwendungen in Kubernetes.

Markdown

Operator Pattern
┌──────────────────────────────────────┐
│            Operator                  │
├──────────────┬────────────┬──────────┤
│ Controller   │  Custom    │ Domain   │
│   Logic      │ Resources  │ Knowledge│
└──────────────┴────────────┴──────────┘
        │            │            │
        ▼            ▼            ▼
┌──────────────────────────────────────┐
│         Managed Application          │
└──────────────────────────────────────┘

Beispiel-Operator:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      name: mysql-operator
  template:
    metadata:
      labels:
        name: mysql-operator
    spec:
      containers:
        - name: operator
          image: mysql-operator:v1.0
          ports:
          - containerPort: 8080
          env:
            - name: WATCH_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace

Service Mesh

Ein Service Mesh bietet erweiterte Netzwerk- und Sicherheitsfunktionen für Microservices.

Markdown

Service Mesh Architektur
┌─────────────────────────────────────┐
│           Control Plane             │
├─────────────┬───────────┬───────────┤
│  Policy     │  Traffic  │ Security  │
│ Management  │  Control  │ Config    │
└─────────────┴───────────┴───────────┘
        │           │           │
        ▼           ▼           ▼
┌─────────────────────────────────────┐
│            Data Plane               │
│     (Envoy/Linkerd Proxies)         │
└─────────────────────────────────────┘

Istio Service Mesh Konfiguration

YAML

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Übung

In dieser Übung werden wir eine Webanwendung mit allen wichtigen Kubernetes-Konzepten deployen.

Übungsziele

Erstellen eines Deployments mit mehreren Replicas
Konfiguration eines Services und Ingress
Implementierung von Monitoring
Anwendung von Security Policies

Voraussetzungen

Funktionierender Kubernetes Cluster (mind. Version 1.24)
kubectl CLI-Tool
Helm (optional)
Ein Docker Image (wir nutzen nginx:latest als Beispiel)

Schritt 1: Deployment erstellen

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Schritt 2: Service konfigurieren

YAML

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Schritt 3: Ingress einrichten

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
spec:
  rules:
  - host: webapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80

Schritt 4: Monitoring aktivieren

YAML

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: webapp-monitor
spec:
  selector:
    matchLabels:
      app: webapp
  endpoints:
  - port: metrics

Schritt 5: Security Policy anwenden

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-policy
spec:
  podSelector:
    matchLabels:
      app: webapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: allowed

Überprüfung der Übung

Führe folgende Befehle aus, um den Status zu prüfen:

Bash

# Überprüfe Deployment-Status
kubectl get deployments
kubectl get pods

# Überprüfe Service und Ingress
kubectl get services
kubectl get ingress

# Teste den Zugriff
curl -H "Host: webapp.example.com" http://CLUSTER-IP

Erwartete Ergebnisse

Drei laufende Pod-Replicas
Funktionierender Service
Erreichbare Webanwendung über Ingress
Aktives Monitoring
Implementierte Sicherheitsrichtlinien

Wichtige Ressourcen

Für ein tieferes Verständnis und die weitere Entwicklung deiner Kubernetes-Kenntnisse empfehlen wir folgende Ressourcen:

Interne Wiki-Artikel

DevOps-Grundlagen: Eine Einführung in die moderne Softwareentwicklung

Offizielle Dokumentation

Praktische Übungen

Community und Support

Tools und Utilities

⚠️ Wichtiger Hinweis: Die Kubernetes-Landschaft entwickelt sich ständig weiter. Stelle sicher, dass du immer die aktuellste Dokumentation konsultierst.

Fazit

Kubernetes hat sich als De-facto-Standard für Container-Orchestrierung etabliert und bietet eine robuste Plattform für moderne Cloud-native Anwendungen. Die in diesem Artikel behandelten Konzepte und Praktiken zeigen die Vielseitigkeit und Leistungsfähigkeit von Kubernetes. Von der grundlegenden Installation über die praktische Implementierung bis hin zu fortgeschrittenen Konzepten wie Custom Resources und Service Mesh – Kubernetes bietet die notwendigen Werkzeuge für den Betrieb komplexer Containerumgebungen.

Die kontinuierliche Weiterentwicklung von Kubernetes, insbesondere im Bereich der Automatisierung und Sicherheit, macht die Plattform zukunftssicher. Mit der steigenden Adoption von Cloud-nativen Technologien und der zunehmenden Bedeutung von DevOps-Praktiken wird Kubernetes weiterhin eine zentrale Rolle in der modernen IT-Infrastruktur spielen. Neue Entwicklungen wie GitOps, KubeVirt für VM-Management und die verstärkte Integration von KI-gestützten Operationen werden die Plattform in Zukunft noch leistungsfähiger machen.

Für Entwickler und Administratoren bedeutet dies, dass kontinuierliches Lernen und die Anpassung an neue Best Practices essentiell bleiben. Die in diesem Artikel vorgestellten Grundlagen und fortgeschrittenen Konzepte bilden dabei eine solide Basis für den erfolgreichen Einsatz von Kubernetes in Produktivumgebungen. Mit dem wachsenden Ökosystem und der aktiven Community wird Kubernetes auch in Zukunft neue Möglichkeiten für die Container-Orchestrierung und das Management verteilter Systeme bieten.