Sovereign Cloud mit Kubernetes: Architektur, Tooling und Praxis

TL;DR

• Eine Sovereign Cloud bedeutet volle Kontrolle ueber Infrastruktur, Daten und Betrieb -- nicht nur "Rechenzentrum in der EU".
• Kubernetes eignet sich dafuer besonders gut, weil es herstellerunabhaengig ist und auf Open-Source-Komponenten aufbaut.
• Die entscheidenden Bausteine sind: eigene oder kontrollierte Hardware, ein gehärteter Kubernetes-Stack, GitOps-basiertes Deployment und ein durchdachtes Secrets-Management.
• Der Betriebsaufwand ist hoeher als bei Managed Services der Hyperscaler, aber die Unabhaengigkeit ist real.
• Dieser Artikel zeigt eine konkrete Referenzarchitektur mit Terraform, YAML und Tooling-Empfehlungen.

Was "Sovereign Cloud" tatsaechlich bedeutet

Der Begriff wird inflationaer verwendet. Viele Anbieter labeln ihre Produkte als "souveraen", sobald ein Rechenzentrum in der EU steht. Das greift zu kurz.

Echte Souveraenitaet erfordert Kontrolle auf mehreren Ebenen:

Kubernetes ist fuer diesen Ansatz gut geeignet, weil es als Open-Source-Projekt keine Herstellerbindung erzwingt. Die Container Orchestration Engine laeuft identisch auf Bare Metal, in VMs oder in einer Private Cloud.

Referenzarchitektur

Der folgende Stack bildet eine produktionsreife Sovereign-Cloud-Plattform. Alle Komponenten sind Open Source oder quelloffen.

Compute und Betriebssystem

Als Basis dient ein gehaertetes Linux. Flatcar Container Linux oder Talos Linux sind gute Optionen, weil sie immutable sind und ausschliesslich fuer Container-Workloads ausgelegt wurden. Klassische Distributionen wie Debian oder RHEL funktionieren ebenfalls, erfordern aber mehr Haertungsarbeit.

Kubernetes Control Plane

Fuer den Eigenbetrieb der Control Plane gibt es mehrere Wege:

• kubeadm: Der offizielle Kubernetes-Bootstrapper. Flexibel, aber manuell.
• Cluster API (CAPI): Deklaratives Cluster-Lifecycle-Management. Gut fuer Multi-Cluster-Setups.
• k3s: Leichtgewichtig, ideal fuer Edge oder kleinere Umgebungen.
• RKE2: Fokus auf Sicherheit und FIPS-Compliance.

Fuer eine souveraene Umgebung empfiehlt sich Cluster API mit dem Infrastructure Provider fuer Bare Metal oder vSphere, weil damit auch Day-2-Operations wie Upgrades deklarativ abgebildet werden.

Networking

Cilium ist aktuell die staerkste Wahl fuer das CNI-Plugin. Es bietet eBPF-basierte Network Policies, transparente Verschluesselung mit WireGuard und Observability ueber Hubble. Fuer den Ingress eignet sich der NGINX Ingress Controller oder Envoy Gateway.

Storage

Persistent Storage ist in souveraenen Umgebungen kritisch, weil die Daten das kontrollierte Netzwerk nicht verlassen duerfen. Rook-Ceph ist die verbreitetste Open-Source-Loesung fuer verteilten Block- und Object-Storage. Fuer kleinere Setups reicht Longhorn. Mehr dazu im Artikel Kubernetes Storage: DSGVO-konforme Loesungen.

Secrets Management

Kubernetes Secrets sind nur Base64-kodiert und bieten keinen echten Schutz. In einer souveraenen Umgebung ist ein externer Secrets Store Pflicht.

HashiCorp Vault ist der De-facto-Standard. Alternativ gibt es das CNCF-Projekt External Secrets Operator, der Secrets aus verschiedenen Backends in Kubernetes-Secrets synchronisiert.

Observability

• Monitoring: Prometheus + Grafana (oder der kube-prometheus-stack Helm Chart)
• Logging: Loki + Promtail oder ein OpenSearch-Cluster
• Tracing: Jaeger oder Tempo ueber OpenTelemetry

Alle Komponenten laufen innerhalb des Clusters und senden keine Daten nach aussen. Details zu Monitoring-Strategien finden Sie unter Kubernetes Monitoring: Kosten senken mit Open Source.

CI/CD und GitOps

GitOps ist der bevorzugte Deployment-Ansatz, weil er auditierbare, reproduzierbare Deployments ermoeglicht. Flux CD oder Argo CD synchronisieren den Cluster-Zustand mit einem Git-Repository.

Die CI-Pipeline (z.B. GitLab CI, Woodpecker CI oder Tekton) baut Container-Images und pusht sie in eine selbst gehostete Registry wie Harbor.

Terraform: Cluster-Infrastruktur provisionieren

Das folgende Terraform-Beispiel provisioniert die Basis-Infrastruktur fuer einen Kubernetes-Cluster auf einem vSphere-Umfeld. In einer Bare-Metal-Umgebung wuerde man stattdessen MAAS oder Tinkerbell verwenden.

# main.tf -- Kubernetes Node VMs auf vSphere

resource "vsphere_virtual_machine" "k8s_control_plane" {
  count            = 3
  name             = "k8s-cp-${count.index}"
  resource_pool_id = data.vsphere_resource_pool.pool.id
  datastore_id     = data.vsphere_datastore.ds.id

  num_cpus = 4
  memory   = 8192

  network_interface {
    network_id = data.vsphere_network.k8s_network.id
  }

  disk {
    label            = "disk0"
    size             = 100
    thin_provisioned = true
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.talos_template.id
  }

  lifecycle {
    ignore_changes = [disk]
  }
}

resource "vsphere_virtual_machine" "k8s_worker" {
  count            = 5
  name             = "k8s-worker-${count.index}"
  resource_pool_id = data.vsphere_resource_pool.pool.id
  datastore_id     = data.vsphere_datastore.ds.id

  num_cpus = 8
  memory   = 32768

  network_interface {
    network_id = data.vsphere_network.k8s_network.id
  }

  disk {
    label            = "disk0"
    size             = 200
    thin_provisioned = true
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.talos_template.id
  }
}

Dieses Setup erzeugt 3 Control-Plane-Nodes und 5 Worker-Nodes. Die Talos-Linux-Vorlage stellt sicher, dass das Betriebssystem minimal und immutable ist.

Pod Security: Workloads einschraenken

In einer souveraenen Umgebung muessen Pods restriktiv konfiguriert sein. Der folgende YAML-Snippet zeigt ein Deployment mit gehaertetem Security Context:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend-api
  template:
    metadata:
      labels:
        app: backend-api
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        fsGroup: 65534
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api
          image: harbor.internal.example.com/production/backend-api:v2.4.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 512Mi
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir:
            sizeLimit: 100Mi

Die wichtigsten Punkte:

• automountServiceAccountToken: false verhindert, dass der Pod unnoetig ein Service-Account-Token erhaelt.
• readOnlyRootFilesystem: true schuetzt vor Manipulation des Container-Dateisystems.
• Alle Linux Capabilities werden gedroppt.
• Das Container-Image kommt aus einer internen Harbor-Registry, nicht von Docker Hub.

Network Policy: Segmentierung durchsetzen

Ohne Network Policies kann jeder Pod im Cluster mit jedem anderen Pod kommunizieren. Das ist in einer souveraenen Umgebung inakzeptabel.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-api-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
        - podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Diese Policy erlaubt dem Backend-API nur Ingress vom API-Gateway auf Port 8080 und Egress zur Datenbank auf Port 5432 sowie DNS-Aufloesung. Alles andere wird blockiert. Weitergehende Netzwerk-Strategien beschreibt der Artikel Kubernetes Network Policies: Fortgeschrittene Konzepte.

Managed vs. Self-Managed: Entscheidungshilfe

Fuer viele Organisationen ist ein hybrider Ansatz sinnvoll: ein Managed Kubernetes eines europaeischen Anbieters fuer die Basis, ergaenzt durch eigene Kontrolle ueber Deployment-Pipelines, Secrets und Observability.

Haeufige Fehler

1. DSGVO mit Datenresidenz gleichsetzen. DSGVO-Konformitaet ist mehr als der physische Standort der Server. Es geht auch um Zugriffskontrollen, Auftragsverarbeitung und Betroffenenrechte. Der Artikel Cloud-DSGVO-Compliance mit Kubernetes geht darauf detailliert ein.

2. Harbor deployen, aber Docker Hub nicht sperren. Wenn Worker-Nodes weiterhin Images von Docker Hub pullen koennen, ist die interne Registry wertlos. Admission Controller wie Kyverno oder OPA Gatekeeper muessen durchsetzen, dass nur Images aus der internen Registry erlaubt sind.

3. Monitoring-Daten nach aussen senden. Viele Grafana-Cloud- oder Datadog-Integrationen senden Metriken an externe Endpoints. In einer souveraenen Umgebung muessen Prometheus und Loki lokal betrieben werden.

4. etcd nicht verschluesseln. Kubernetes speichert Secrets im Klartext in etcd, sofern Encryption at Rest nicht explizit konfiguriert ist. Das ist in jeder produktiven Umgebung ein Problem, in einer souveraenen Umgebung ein Showstopper.

Fazit

Eine Sovereign Cloud mit Kubernetes ist machbar, erfordert aber Disziplin bei der Auswahl der Komponenten und im Betrieb. Der Open-Source-Stack bietet alle notwendigen Bausteine. Die eigentliche Herausforderung liegt nicht in der Technologie, sondern in der organisatorischen Reife: Teams muessen in der Lage sein, den Stack zu betreiben, zu patchen und weiterzuentwickeln.

Wer diesen Weg geht, gewinnt echte Unabhaengigkeit und kann Compliance-Anforderungen aus einer Position der Staerke heraus erfuellen, statt sie als Last zu empfinden.

Wenn Sie Unterstuetzung beim Aufbau oder der Bewertung Ihrer souveraenen Kubernetes-Plattform benoetigen, finden Sie weitere Informationen auf unserer Kontaktseite.