Cloud-Infrastruktur

Bare Metal, Container, Kubernetes — Cloud-Architektur die zur Anforderung passt.

Bare Metal

+ VM Hybrid

2 RZs

GEO-redundant

Rancher

RKE2 Stack

IaC

Terraform, Ansible

Cloud ist kein Ort — es ist eine Architektur

Cloud bedeutet nicht „Server bei AWS mieten“. Cloud ist ein Architekturprinzip: Infrastruktur als Code, horizontale Skalierung, Self-Healing, deklarative Konfiguration. Das funktioniert im öffentlichen Rechenzentrum genauso wie auf Bare Metal im eigenen RZ — solange die Architektur stimmt.

Die richtige Abstraktion für den richtigen Zweck

Nicht jede Anwendung braucht Kubernetes. Nicht jeder Container braucht einen Orchestrator. Die Kunst liegt darin, die richtige Abstraktionsebene zu wählen — passend zur Teamgröße, zur Komplexität und zum Budget.

Container-Runtimes im Vergleich

Alles beginnt mit der Frage: Wie laufen Container auf einem Host? Die Antwort ist weniger eindeutig als man denkt.

Docker

Der Klassiker. Docker Daemon läuft als Root-Prozess, verwaltet Images, Container, Netzwerke und Volumes. Einfach zu bedienen, riesiges Ökosystem, de-facto Standard für Entwicklung. Aber: Single Point of Failure — wenn der Daemon stirbt, sterben alle Container.

Daemon-basiert (dockerd)
Docker Hub als Registry
Docker Compose für Multi-Container
Einfacher Einstieg

Podman

Die Alternative ohne Daemon. Podman ist CLI-kompatibel zu Docker (alias docker=podman), läuft aber rootless und ohne zentralen Prozess. Jeder Container ist ein eigenständiger Prozess unter dem User der ihn startet. Sicherer, systemd-integriert, ideal für Umgebungen mit strengen Sicherheitsanforderungen.

Daemonless & rootless
OCI-kompatibel
Pods wie in Kubernetes
systemd-Integration nativ

Orchestrierung — Docker Compose vs. K3s vs. K8s

Ein Container allein ist nur ein Prozess. Spannend wird es, wenn mehrere Container zusammenarbeiten müssen — und jemand entscheiden muss, wo sie laufen, wie sie skalieren und was passiert wenn einer ausfällt.

Docker Compose

services:
  webapp:
    image: app:2.4.1
    ports: [„8080:80“]
    depends_on: [db, redis]
  db:
    image: mysql:8.0
    volumes: [db_data:/var/lib/mysql]
  redis:
    image: redis:7-alpine

Wann: Einzelner Host, Entwicklung, kleine Projekte. Kein Clustering, kein Auto-Healing. Einfach, schnell, überschaubar.

K3s — Lightweight Kubernetes

curl -sfL https://get.k3s.io | sh –

# Fertig. Ein Node, ein Binary.
# SQLite statt etcd.
# Traefik als Ingress.
# ~512 MB RAM Footprint.

kubectl get nodes
NAME STATUS ROLES
edge-1 Ready control-plane

Wann: Edge-Deployments, IoT, kleine Cluster, CI/CD-Runner. Vollwertiges K8s-API, aber mit minimalem Footprint.

Kubernetes (K8s) / RKE2

# Multi-Node Production Cluster
# RKE2 = „Rancher Next Gen“
# CIS-gehärtet ab Werk
# etcd als Datastore
# Cilium/Calico als CNI

Nodes:      6 (3 Control, 3 Worker)
Namespaces: kunde-a, kunde-b, staging
Ingress:    nginx + cert-manager
GitOps:     ArgoCD
Monitoring: Prometheus + Grafana

Wann: Produktion, Multi-Tenant, Compliance, Skalierung. Mehr Overhead, aber volle Kontrolle über Networking, Storage, RBAC und Lifecycle.

Entscheidungshilfe

„Ich brauche schnell einen Container“
→ Docker Compose

„Ich brauche Orchestrierung, aber minimal“
→ K3s

„Ich brauche Multi-Tenant, RBAC, Compliance“
→ Kubernetes / RKE2

„Ich brauche Container ohne Root-Rechte“
→ Podman

„Ich weiß nicht was ich brauche“
→ Genau dafür gibt es Beratung.

Referenz-Architektur: Cloud-Infrastruktur

So kann eine produktive Cloud-Infrastruktur auf Bare Metal mit GEO-Redundanz aussehen — die einzelnen Schichten im Überblick:

Die Schichten einer Cloud-Infrastruktur

1. Networking

Floating IPs, DNS-Failover zwischen Standorten, Load Balancer vor dem Cluster. Ingress Controller (nginx oder Traefik) terminiert TLS, cert-manager holt Let’s-Encrypt-Zertifikate automatisch. Cilium oder Calico als CNI für Pod-Networking und Network Policies.

2. Compute

Bare-Metal-Server oder VMs als Worker Nodes. Pods laufen mit Resource Requests und Limits — kein Container frisst unbemerkt den ganzen Host. Horizontal Pod Autoscaler skaliert bei Last, Cluster Autoscaler provisioniert neue Nodes wenn nötig.

3. Daten

Datenbanken auf dedizierter Infrastruktur, nicht im Cluster. Galera für MySQL (synchrone Replikation), Patroni für PostgreSQL (Streaming Replication mit automatischem Failover). Cross-Site-Replikation zwischen den Rechenzentren. Point-in-Time-Recovery als Absicherung.

4. Storage

Persistent Volumes über Longhorn (replizierter Block-Storage im Cluster) oder NFS für Shared Storage. Stateful Workloads wie Elasticsearch oder Kafka brauchen Storage Classes mit definierten IOPS und Retention Policies. Backups stündlich, Restore-Tests regelmäßig.

5. Observability

Prometheus scrapt Metriken, Grafana visualisiert, Alertmanager benachrichtigt. Loki für Logs, optional Jaeger für Traces. SLA-Dashboards pro Kunde, Kapazitätsplanung auf Basis historischer Daten. Monitoring ist kein Addon — es gehört zur Architektur.

6. Deployment & Lifecycle

GitOps mit ArgoCD: Desired State liegt im Git-Repo, ArgoCD synchronisiert automatisch. Kein manuelles kubectl apply. Infrastruktur-Provisionierung über Terraform und Ansible. Cluster-Upgrades geplant, getestet, rollbar. Secrets über HashiCorp Vault oder Sealed Secrets.

Best Practice

Eine Cloud-Architektur ist nur so gut wie ihr schwächstes Glied. Networking ohne Redundanz, Datenbanken ohne Failover, Deployments ohne Rollback-Strategie — jeder einzelne Punkt kann zum Ausfall führen. Die Referenz-Architektur oben ist kein Wunschdenken, sondern die Basis auf der produktive Systeme laufen.

Cloud-Architektur planen? Lassen Sie uns über Ihre Anforderungen sprechen