Cloud-Portabilität¶

Die Kubernetes-Manifeste von KanjiIQ sind zu ungefähr 90% portierbar über Cloud-Anbieter hinweg. Diese Seite beschreibt den Migrationspfad zu AWS und GCP und hebt hervor, was gleich bleibt und was geändert werden muss.

Was überall gleich bleibt¶

Diese Ressourcen funktionieren identisch auf jedem CNCF-konformen Kubernetes-Cluster:

Deployments: Pod-Spezifikationen, Container-Definitionen, Ressourcenlimits, Gesundheitsprobes
Services: ClusterIP-Services, Port-Zuordnungen, Selektoren
Secrets: Opaque Secrets mit stringData
PersistentVolumeClaims: Speicheranforderungen (Cloud-Provisioner übernehmen den Rest)
Namespaces: Isolierungsgrenzen
Docker-Images: OCI-konform, laufen auf jeder Container-Runtime

Migration zu AWS (EKS)¶

Architektur-Zuordnung¶

graph TB
    subgraph Current["Current: Hetzner k3s"]
        A1[k3s] --> A2[Traefik]
        A1 --> A3[PostgreSQL on k8s]
        A1 --> A4[Forgejo Registry]
        A1 --> A5[cert-manager]
    end

    subgraph AWS["Target: AWS EKS"]
        B1[EKS] --> B2[ALB Ingress Controller<br/>or Traefik]
        B1 --> B3[RDS PostgreSQL]
        B1 --> B4[ECR]
        B1 --> B5[ACM<br/>or cert-manager]
    end

    Current -.->|Migration| AWS

Komponente für Komponente¶

Aktuell	AWS-Äquivalent	Erforderliche Änderung
k3s	EKS	Cluster-Bereitstellung (eksctl/Terraform)
Traefik	ALB Ingress Controller oder Traefik beibehalten	Ingress-Annotationen ändern sich
PostgreSQL auf k8s	RDS	`DATABASE_URL`-Secret aktualisieren; PG-Manifeste entfernen
Forgejo Registry	ECR	Image-URLs in Deployments aktualisieren; CI/CD aktualisieren
cert-manager	ACM	cert-manager-Annotationen durch ACM ARN ersetzen
Forgejo Actions	GitHub Actions oder CodePipeline	Workflow-Dateien neu schreiben
Lokales PV	EBS (gp3)	PVC funktioniert unverändert; EKS stellt automatisch EBS bereit

Manifest-Änderungen¶

Ingress (bei Wechsel zu ALB):

# Before (Traefik)
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
spec:
  ingressClassName: traefik

# After (AWS ALB)
metadata:
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:...
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
spec:
  ingressClassName: alb

Datenbank (Wechsel zu RDS):

# Update the secret with RDS endpoint
stringData:
  database-url: "postgresql://user:[email protected]:5432/jlpt_flashcard"

Dann 02-postgres-pvc.yaml und 03-postgres-deployment.yaml löschen — RDS übernimmt alles.

Geschätzter Aufwand¶

Cluster-Einrichtung: 1-2 Tage (EKS + Netzwerk)
Manifest-Anpassung: 1 Tag (Ingress, Secrets, Image-URLs)
CI/CD-Neuschreibung: 1 Tag (GitHub Actions oder CodePipeline)
Datenmigration: 1 Tag (pg_dump → RDS-Import)
DNS-Umstellung: 1 Stunde
Gesamt: ~4-5 Tage

Migration zu GCP (GKE)¶

Komponenten-Zuordnung¶

Aktuell	GCP-Äquivalent	Erforderliche Änderung
k3s	GKE	Cluster-Bereitstellung (gcloud/Terraform)
Traefik	GKE Ingress oder Traefik beibehalten	Ingress-Annotationen ändern sich
PostgreSQL auf k8s	Cloud SQL	`DATABASE_URL` aktualisieren; PG-Manifeste entfernen
Forgejo Registry	Artifact Registry	Image-URLs aktualisieren
cert-manager	Google-verwaltete Zertifikate oder cert-manager beibehalten	Annotation-Änderung
Forgejo Actions	Cloud Build oder GitHub Actions	Pipelines neu schreiben
Lokales PV	Persistent Disk	PVC funktioniert unverändert

Manifest-Änderungen¶

Ingress (GKE nativ):

metadata:
  annotations:
    networking.gke.io/managed-certificates: kanjiiq-cert
spec:
  ingressClassName: gce

Geschätzter Aufwand¶

Cluster-Einrichtung: 1-2 Tage
Manifest-Anpassung: 1 Tag
CI/CD-Neuschreibung: 1 Tag
Datenmigration: 1 Tag
Gesamt: ~4-5 Tage

Multi-Cloud-Strategie¶

Für Organisationen, die Multi-Cloud-Deployment benötigen:

Portabel bleiben¶

Traefik beibehalten anstelle von cloud-nativem Ingress (funktioniert identisch auf EKS, GKE, AKS)
cert-manager beibehalten anstelle von ACM/Google-Zertifikaten (cloud-agnostisches TLS)
PostgreSQL auf k8s beibehalten, wenn Anbieter-Lock-in vermieden werden soll (Kompromiss: mehr betrieblicher Aufwand)
Eine cloud-agnostische Registry verwenden wie Harbor (selbst gehostet, funktioniert mit jedem k8s)

Cloud-Dienste akzeptieren¶

Für vereinfachten Betrieb verwaltete Dienste pro Cloud nutzen:

Datenbank: RDS (AWS) / Cloud SQL (GCP) — deutlich weniger betrieblicher Aufwand
Registry: ECR (AWS) / Artifact Registry (GCP) — enge Integration mit IAM
TLS: ACM (AWS) / Managed Certs (GCP) — wartungsfreie Zertifikate

Die richtige Wahl hängt davon ab, ob Sie Portabilität (cloud-agnostisch bleiben) oder betriebliche Einfachheit (verwaltete Dienste nutzen) priorisieren.