Überblick über das Kubernetes-Deployment

MobilityManager liefert Kubernetes-Manifeste unter k8s/ aus, organisiert als Kustomize-Basis mit Overlays je Umgebung. Dieser Artikel erläutert die Struktur und wie Sie die Anwendung in einem Cluster bereitstellen.

Aufbau der Manifeste

Die Anwendungsmanifeste liegen unter k8s/mobilitymanager:

• base/ — das Deployment, der Service und das PodDisruptionBudget, die von allen Umgebungen gemeinsam genutzt werden.
• overlays/dev/ und overlays/prod/ — umgebungsspezifische ConfigMap, Ingress und Kustomize-Patches.

Das Basis-Deployment betreibt zwei Replikate des Containers auf Port 8080, mit Pod-Anti-Affinität über Zonen hinweg und einem PodDisruptionBudget, das mindestens einen Pod verfügbar hält.

Konfiguration und Geheimnisse

Nicht sensible Einstellungen stammen aus einer ConfigMap (mobilitymanager-config) und Geheimnisse aus einem Secret (mobilitymanager-secrets), beide über envFrom eingespeist:

• ConfigMap: ASPNETCORE_ENVIRONMENT, ASPNETCORE_URLS, DatabaseProvider, LicensePortal__BaseUrl und DocumentStorage__EnableEncryptionAtRest.
• Secret: ConnectionStrings__SystemConnection, ConnectionStrings__TenantConnection und Jwt__Key.

Erstellen oder aktualisieren Sie das Secret, ohne Zugangsdaten einzuchecken. Zum Beispiel:

kubectl -n mobilitymanager-prod create secret generic mobilitymanager-secrets \
  --from-literal=ConnectionStrings__SystemConnection='...' \
  --from-literal=ConnectionStrings__TenantConnection='...' \
  --from-literal=Jwt__Key='...' \
  --dry-run=client -o yaml | kubectl apply -f -

Warnung: secret.example.yaml ist lediglich eine Vorlage. Checken Sie niemals echte Verbindungszeichenfolgen oder Signaturschlüssel ein; verwalten Sie diese über den Secret-Store Ihres Clusters.

Health-Probes und Sicherheitskontext

Das Deployment verbindet die integrierten Health-Endpunkte mit Kubernetes-Probes: /livez für Liveness, /readyz für Readiness und /healthz als Startup-Probe. Der Pod läuft gehärtet: eine numerische Nicht-Root-UID, ein schreibgeschütztes Root-Dateisystem, entzogene Linux-Capabilities und keine Privilegienerhöhung. Beschreibbare Pfade werden als emptyDir-Volumes für /tmp, /app/data und /app/logs bereitgestellt.

Mit Kustomize bereitstellen

1. Stellen Sie sicher, dass die ConfigMap-Werte und das Secret im Zielnamespace vorhanden sind.
2. Zeigen Sie die gerenderten Manifeste in der Vorschau an:

   kubectl kustomize k8s/mobilitymanager/overlays/prod

3. Wenden Sie das Overlay an:

   kubectl apply -k k8s/mobilitymanager/overlays/prod

4. Beobachten Sie den Rollout:

   kubectl -n mobilitymanager-prod rollout status deployment/mobilitymanager

Hinweis: Der enthaltene Ingress verwendet eine Ingress-Klasse für Cloudflare Tunnel und terminiert TLS außerhalb des Pods. Ersetzen Sie die Ingress-Klasse und die Hostnamen, damit sie zu Ihrem eigenen Cluster passen.

Verwandte Artikel

• Überblick über die Bereitstellungsarchitektur
• Die Datenbank-Verbindungszeichenfolgen konfigurieren
• Die Health-Endpunkte verstehen
• Checkliste zur Produktionshärtung