Zum Inhalt

Cloud-Native-Übersicht

KanjiIQ wurde nach Cloud-Native-Prinzipien entwickelt und ist dadurch auf jeder Kubernetes-konformen Plattform portierbar. Die Anwendung verwendet Standard-Kubernetes-APIs ohne proprietäre Cloud-Anbieter-Erweiterungen.

12-Factor-App-Übereinstimmung

Faktor KanjiIQ-Implementierung
I. Codebase Einzelnes Git-Repository (Forgejo), versionskontrolliert
II. Abhängigkeiten Explizit deklariert in pubspec.yaml (Dart) und requirements-docs.txt (Python)
III. Konfiguration Umgebungsvariablen, injiziert über Kubernetes Secrets und ConfigMaps
IV. Unterstützende Dienste PostgreSQL über DATABASE_URL angebunden — austauschbar ohne Codeänderungen
V. Build, Release, Run Mehrstufige Docker-Builds → getaggte Images → Kubernetes Rolling Updates
VI. Prozesse Zustandslose Anwendungscontainer; Zustand lebt in PostgreSQL
VII. Port-Bindung Services eigenständig: Frontend auf :80, Backend auf :8080
VIII. Nebenläufigkeit Horizontale Skalierung über Kubernetes-Replikate
IX. Entsorgbarkeit Schneller Start, ordnungsgemäßes Herunterfahren, Gesundheitsprobes
X. Gleichheit Entwicklung/Produktion Staging-Namespace spiegelt Produktionsmanifeste
XI. Logs Stdout/stderr (Kubernetes erfasst im Node-Dateisystem)
XII. Admin-Prozesse Datenbankmigrationen als einmalige Befehle ausgeführt

Was macht KanjiIQ Cloud-Native?

Ausschließlich Standard-Kubernetes-APIs

Alle Ressourcen verwenden Standard-API-Gruppen apps/v1, v1 und networking.k8s.io/v1:

  • Deployment (keine cloud-spezifischen verwalteten Dienste)
  • Service (ClusterIP — funktioniert überall)
  • Ingress (Standard-Networking-API)
  • PersistentVolumeClaim (cloud-agnostische Speicheranforderung)
  • Secret (Standard-Konfigurationsmanagement)

Die einzigen nicht-standardmäßigen CRDs sind Traefik Middlewares — diese können durch gleichwertige Ingress-Controller-Funktionen auf jeder Plattform ersetzt werden.

Alles containerisiert

Jede Komponente hat ein produktionsreifes Dockerfile:

Komponente Dockerfile Basis-Image
Frontend Dockerfile.frontend nginx:alpine
Backend Dockerfile.backend dart:stable
Dokumentation Dockerfile.docs nginx:alpine

Alle Images:

  • Verwenden mehrstufige Builds (kleine Produktions-Images)
  • Laufen als Non-Root (UID 1000)
  • Enthalten Gesundheitsprüfungen
  • Werden in eine Container-Registry gepusht (portierbar zu jeder Registry)

Infrastructure as Code

100% der Infrastruktur ist in versionskontrolliertem YAML definiert:

k8s/
├── 00-namespace.yaml
├── 01-secrets.yaml (template)
├── 02-postgres-pvc.yaml
├── 03-postgres-deployment.yaml
├── 05-deployment.yaml
├── 06-service.yaml
├── 07-ingress.yaml
├── 08-security-middlewares.yaml
└── ...

Die Neuerstellung der gesamten Umgebung von Grund auf erfordert nur:

kubectl apply -f k8s/

Portabilitätsbewertung

Komponente Portabilität Hinweise
Anwendungs-Deployments Vollständig portierbar Standard-k8s-Manifeste
Services Vollständig portierbar ClusterIP funktioniert überall
Ingress Größtenteils portierbar Ingress-Klasse muss ggf. geändert werden
PVC Vollständig portierbar Cloud-Anbieter stellen Speicher automatisch bereit
Secrets Vollständig portierbar Gleiche API über alle Clouds
Traefik Middlewares Erfordert Anpassung Durch cloud-native Alternativen ersetzen
Container-Images Vollständig portierbar Push zu jeder OCI-Registry
CI/CD Erfordert Anpassung Forgejo Actions → GitHub Actions / Cloud Build

Siehe Portabilität für detaillierte Migrationsleitfäden zu AWS und GCP.