Compose Migration zu Kubernetes: Mapping von Services, Volumes, Secrets

Die Migration von Docker Compose zu Kubernetes ist ein strategischer Schritt, wenn Anwendungen skalierbar, hochverfügbar und cloud-native betrieben werden sollen. Während Compose für lokale Multi-Container-Stacks geeignet ist, bietet Kubernetes ein mächtiges Orchestrierungsframework für verteilte Umgebungen. In diesem Tutorial beleuchten wir praxisnah, wie Services, Volumes und Secrets aus Compose in Kubernetes-Objekte überführt werden können, welche Unterschiede zu beachten sind und welche Best Practices für eine reibungslose Migration gelten.

1. Vergleich: Compose vs. Kubernetes

Bevor die Migration beginnt, ist es wichtig, die grundlegenden Unterschiede zwischen Compose und Kubernetes zu verstehen:

Compose

• Single-Host oder begrenztes Multi-Host-Setup
• Multi-Container-Stacks über YAML definiert
• Keine eingebaute Hochverfügbarkeit oder automatische Rescheduling
• Volumes und Netzwerke lokal gebunden

Kubernetes

• Cluster-Management über mehrere Nodes
• Services, Deployments, StatefulSets für orchestrierte Container
• Automatisches Scheduling, Self-Healing, Rolling Updates
• Persistent Volumes, ConfigMaps und Secrets für Storage und Konfiguration

2. Mapping von Services

In Compose werden Services direkt definiert. Kubernetes nutzt Deployments, StatefulSets oder DaemonSets:

Deployment Beispiel

Ein einfacher Webservice in Compose:

version: '3.9'
services:
  web:
    image: myapp:latest
    ports:
      - "8080:80"
    environment:
      - ENV=prod

In Kubernetes als Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: myapp:latest
        ports:
        - containerPort: 80
        env:
        - name: ENV
          value: "prod"

Service Definition

Für den externen Zugriff definiert man einen Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80

3. Volumes und Storage Mapping

Volumes in Compose können als Bind-Mounts oder Named Volumes definiert sein. Kubernetes trennt zwischen Persistent Volumes (PV) und Persistent Volume Claims (PVC).

Compose Named Volume

volumes:
  db-data:
services:
  db:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data

Kubernetes PV/PVC Mapping

apiVersion: v1
kind: PersistentVolume
metadata:
  name: db-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data/postgres

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: db-pvc

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 10Gi

apiVersion: apps/v1

kind: StatefulSet

metadata:

name: db

spec:

serviceName: "db"

replicas: 1

selector:

matchLabels:

app: db

template:

metadata:

labels:

app: db

spec:

containers:

- name: db

image: postgres:15

volumeMounts:

- name: db-storage

mountPath: /var/lib/postgresql/data

volumeClaimTemplates:


metadata:

name: db-storage

spec:

accessModes: [ "ReadWriteOnce" ]

resources:

requests:

storage: 10Gi

4. Secrets und Configs

Compose nutzt Umgebungsvariablen oder secrets-Definitionen. In Kubernetes wird zwischen Secrets und ConfigMaps unterschieden:

Compose Secret

secrets:
  db-password:
    file: ./db-password.txt
services:
  db:
    secrets:
      - db-password

Kubernetes Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: 

apiVersion: apps/v1

kind: Deployment

metadata:

name: db

spec:

replicas: 1

selector:

matchLabels:

app: db

template:

metadata:

labels:

app: db

spec:

containers:

- name: db

image: postgres:15

env:

- name: POSTGRES_PASSWORD

valueFrom:

secretKeyRef:

name: db-secret

key: password

5. Netzwerke und Service Discovery

Compose definiert Netzwerke innerhalb eines Hosts. Kubernetes setzt auf interne DNS-basierte Service Discovery:

• Service-Namen dienen als Hostnames innerhalb des Clusters
• ClusterIP Services ermöglichen interne Kommunikation
• LoadBalancer Services oder Ingress für externen Zugriff

Ingress Beispiel

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

6. Migration Best Practices

• Schrittweise Migration: zuerst non-critical Services testen
• Versionierte Images und Tags für Rollback-Fähigkeit
• Secrets und ConfigMaps zentralisieren und sicher handhaben
• Staging-Cluster aufbauen, um Verhalten und Netzwerk zu testen
• Monitoring und Logging anpassen (Prometheus, Loki, OpenTelemetry)

Die Migration von Docker Compose zu Kubernetes erfordert sorgfältige Planung, insbesondere bei Volumes, Secrets und Netzwerk-Architekturen. Mit einem klaren Mapping von Services, PV/PVCs und Secrets lassen sich die Vorteile von Kubernetes für Skalierbarkeit, Hochverfügbarkeit und orchestrierte Deployments nutzen, ohne bestehende Container-Stacks komplett neu entwickeln zu müssen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.