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)
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:
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:
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:
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
Control Loop Struktur:
┌──────────────────┐
│ Desired State │
│ (Configuration) │
└────────┬─────────┘
↓
┌──────────────────┐
│ Current State │◄────┐
│ (Observation) │ │
└────────┬─────────┘ │
↓ │
┌──────────────────┐ │
│ Actions │ │
│ (Reconciliation) │ │
└────────┬─────────┘ │
└───────────────┘
Beispiel einer Controller-Manager Konfiguration:
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:
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:
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
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.
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:
# Ü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:
# Ü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:
# 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:
# 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:
# Swap deaktivieren
sudo swapoff -a
# Swap-Eintrag aus /etc/fstab entfernen
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
# 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:
# 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:
# 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:
# 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:
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.
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
# 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:
# 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
# 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:
# 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.
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:
# 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:
# 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:
# 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:
# Auf dem Control Plane Node:
kubeadm token create --print-join-command
Node Labels und Taints
# 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
# 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:
# 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:
# Ü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:
# 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:
# Ü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.
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:
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
undmaxUnavailable
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:
# 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:
# 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
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
# 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:
# 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:
# 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.
Storage Architektur
┌───────────────┐ ┌───────────────┐
│ StorageClass │ ──► │ PersistentVol │
└───────────────┘ └───────────────┘
▲ ▲
│ │
┌───────────────┐ ┌───────────────┐
│ Application │ ◄── │ PVC │
└───────────────┘ └───────────────┘
Persistent Volume
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.
# 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:
# 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:
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:
# 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:
# 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.
Monitoring & Wartung
┌─────────────────┐ ┌─────────────────┐
│ Monitoring │ │ Wartung │
├─────────────────┤ ├─────────────────┤
│ • Metriken │ │ • Updates │
│ • Alerts │ │ • Backups │
│ • Performance │ │ • Cleaning │
└─────────────────┘ └─────────────────┘
Monitoring-Architektur
Eine typische Kubernetes-Monitoring-Architektur besteht aus mehreren Komponenten:
┌─────────────────────────────────────────────┐
│ 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:
# 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:
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:
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:
┌─────────────────────────────────────────────┐
│ 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:
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:
Performance Dashboard
┌────────────────────────────────────┐
│ Node Performance │
├──────────────┬───────────┬─────────┤
│ CPU Usage │ Memory │ Disk │
│ ▇▇▇▇▇░░░░░ │ ▇▇▇░░░░░░ │ ▇▇░░░░ │
│ 50% │ 35% │ 20% │
└──────────────┴───────────┴─────────┘
Resource Quotas Monitoring
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:
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:
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
# 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:
# 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:
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:
#!/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
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
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:
RBAC Hierarchie
┌─────────────────────────────────────┐
│ RBAC System │
├─────────────┬───────────┬───────────┤
│ Roles │ClusterRoles│ Subjects │
├─────────────┼───────────┼───────────┤
│Permissions │Namespace │Users │
│Rules │Übergreifend│Groups │
│Namespace │Cluster-weit│ServiceAcc│
└─────────────┴───────────┴───────────┘
Role Definition
# 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:
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
Network Policy Übersicht
┌──────────────┐ ┌──────────────┐
│ Frontend Pod │ ───► │ Backend Pod │
└──────────────┘ └──────────────┘
▲ ▲
│ │
┌──────────────┐ ┌──────────────┐
│ Ingress │ │ Allow from │
│ Traffic │ │ Frontend │
└──────────────┘ └──────────────┘
Beispiel einer Network Policy:
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:
# 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:
Container Security Layers
┌─────────────────────────────────────┐
│ Container Image │
├─────────────────┬───────────┬───────┤
│ Base Image │ Libraries │ App │
│ Vulnerabilities│ Security │ Code │
└─────────────────┴───────────┴───────┘
▼ ▼ ▼
┌─────────────────────────────────────┐
│ Security Controls │
│ • Image Scanning │
│ • Trusted Registries │
│ • Image Signing │
└─────────────────────────────────────┘
Image Scanning
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:
# 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:
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
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:
# 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
Security Checklist
┌────────────────────────────────┐
│ Tägliche Überprüfungen │
├────────────────────────────────┤
│ □ Pod Security Policies │
│ □ Network Policies │
│ □ RBAC Konfiguration │
│ □ Secret Management │
│ □ Container Vulnerabilities │
│ □ Audit Logs │
└────────────────────────────────┘
Automatisierte Sicherheitsprüfungen
# 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:
# 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.
Custom Resource Architektur
┌─────────────────────────────────────┐
│ Custom Resource (CR) │
├─────────────┬───────────┬───────────┤
│ Definition │ Validation│ Controller│
│ (CRD) │ Schema │ Logic │
└─────────────┴───────────┴───────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────┐
│ Kubernetes API Server │
└─────────────────────────────────────┘
Custom Resource Definition (CRD)
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.
Operator Pattern
┌──────────────────────────────────────┐
│ Operator │
├──────────────┬────────────┬──────────┤
│ Controller │ Custom │ Domain │
│ Logic │ Resources │ Knowledge│
└──────────────┴────────────┴──────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────────────┐
│ Managed Application │
└──────────────────────────────────────┘
Beispiel-Operator:
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.
Service Mesh Architektur
┌─────────────────────────────────────┐
│ Control Plane │
├─────────────┬───────────┬───────────┤
│ Policy │ Traffic │ Security │
│ Management │ Control │ Config │
└─────────────┴───────────┴───────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────┐
│ Data Plane │
│ (Envoy/Linkerd Proxies) │
└─────────────────────────────────────┘
Istio Service Mesh Konfiguration
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
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
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
selector:
app: webapp
ports:
- port: 80
targetPort: 80
type: ClusterIP
Schritt 3: Ingress einrichten
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
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: webapp-monitor
spec:
selector:
matchLabels:
app: webapp
endpoints:
- port: metrics
Schritt 5: Security Policy anwenden
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:
# Ü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
Offizielle Dokumentation
Praktische Übungen
- Kubernetes Basics Interactive Tutorial
- Minikube Getting Started Guide
- KubeLabs – Interactive Kubernetes Labs
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.