Containerisierung · Images, Helm, Härtung
Anwendungen containerisieren und Kubernetes-ready machen
Aus einer Anwendung, die auf einer VM oder einem Entwicklerrechner läuft, wird ein reproduzierbares, gehärtetes Container-Image mit Health-Checks, Konfiguration über Umgebung und Auslieferung per Helm.
- OCI-Images ohne Geheimnisse
- Zustandslos und zustandsbehaftet
- Ziel: Pod Security Standard Restricted
01Ausgangslage
Wenn „läuft bei mir“ nicht reicht
SKAFFON containerisiert bestehende Anwendungen und macht sie betriebsfähig für Kubernetes. Die Seite richtet sich an Teams, die Anwendungen von virtuellen Maschinen in Container überführen, Docker-Setups produktionsfähig machen oder Monolithen schrittweise modernisieren wollen.
Welcher Cluster und welcher Betrieb dazugehören, klärt die Kubernetes-Beratung. Die tiefergehende Umgestaltung von Anwendungen ist Application-Modernisierung.
02Dabei entsteht
Vom Assessment bis zur Übergabe: was Sie erhalten
-
Assessment je Anwendung
Zustand, Konfiguration, Abhängigkeiten, Startverhalten, Logging. Ergebnis ist die Einstufung nach der Matrix weiter unten.
-
Schlanke OCI-Images
Reproduzierbarer Build nach dem OCI-Image-Standard, mit nicht privilegiertem Benutzer und ohne Geheimnisse im Image.
-
Konfiguration und Zustand getrennt
Konfiguration über Umgebung statt über Dateien im Image; persistente Daten in dafür vorgesehenen Speichern.
-
Auslieferung
Helm-Chart oder Kustomize-Manifeste, Health-Checks, Ressourcenlimits; Übergabe an GitOps und CI/CD.
-
Gehärtete Laufzeit
Sechs Prüfpunkte, orientiert an den Pod Security Standards (siehe Checkliste).
-
Dokumentation und Einweisung
Was gebaut wurde und warum, schriftlich festgehalten; Ihr Team wird eingewiesen, damit es Images und Chart selbst weiterpflegen kann.
03Entscheidung
Welcher Weg passt zu welcher Anwendung?
Die Open Container Initiative definiert Runtime-, Image- und Distribution-Spezifikation; Images nach diesem Standard laufen auf kompatiblen Laufzeiten, das ist die Grundlage für Portabilität zwischen Plattformen.
| Anwendungstyp | Containerisierungsweg | Kubernetes-Ready-Kriterien | Risiko / Hinweis |
|---|---|---|---|
| Zustandslose Webanwendung oder API | Direkt containerisieren; Konfiguration über Umgebung | Health-Check, sauberes Beenden bei Signal, Logs nach stdout | Gering; Sitzungszustand prüfen |
| Anwendung mit lokalem Dateizustand | Zustand in Objektspeicher oder persistentes Volume verlagern | Kein Schreiben ins Container-Dateisystem | Mittel; Anwendungsänderung nötig |
| Datenbank | Meist nicht im Cluster, sondern als Managed Service; im Cluster nur mit Betriebskonzept (Backup, Failover, Updates) | Wiederherstellung getestet, bevor Daten migriert werden | Hoch; Entscheidung vor dem Bau |
| Legacy-Monolith | Schrittweise: erst lauffähig im Container, dann bei Bedarf zerlegen | Reproduzierbarer Build, dokumentierte Abhängigkeiten | Mittel bis hoch; kein Zerlegen ohne Fachgrund |
| Anwendung mit spezieller Hardware- oder Kernelabhängigkeit | Prüfen, ob Container passt; sonst VM belassen | Verfügbarkeit der Abhängigkeit auf Zielknoten | Hoch; oft bleibt die VM die bessere Wahl |
04Entscheidungsfluss
Direkt containerisieren, Zustand auslagern oder VM belassen
Die erste Frage an jede Anwendung ist, ob sie lokalen Zustand hat. Daraus folgt der Weg.
05Sonderfall Datenbank
PostgreSQL im Cluster: Operator oder verwalteter Dienst?
CloudNativePG ist ein Kubernetes-Operator für hochverfügbare PostgreSQL-Cluster mit Primary/Standby-Architektur, automatisiertem Failover und kontinuierlichen Backups in Objektspeicher mit Point-in-Time-Recovery (laut Projektseite).
Ob das für Sie besser ist als ein verwalteter Datenbankdienst, entscheiden Betriebsaufwand, Datenstandort und Wiederherstellungsziele.
- Im Cluster nur mit Betriebskonzept: Backup, Failover, Updates.
- Wiederherstellung wird getestet, bevor Daten migriert werden.
06Härtung
Sechs Prüfpunkte bis Restricted
Die Kubernetes-Dokumentation definiert drei Pod Security Standards: Privileged (unbeschränkt), Baseline (verhindert bekannte Rechteausweitungen) und Restricted (folgt aktuellen Hardening-Praktiken). Unser Ziel für neue Workloads ist Restricted; Abweichungen werden begründet dokumentiert.
- Prozess läuft nicht als Root; keine unnötigen Rechte.
- Basis-Image schlank und aktuell gehalten; Abhängigkeiten werden im Build auf bekannte Schwachstellen geprüft.
- Keine Geheimnisse im Image oder in Build-Argumenten.
- Dateisystem nach Möglichkeit schreibgeschützt; Schreibpfade explizit.
- Ressourcenanforderungen und -limits gesetzt.
- Image wird per Digest ausgeliefert und aus einer kontrollierten Registry bezogen.
07Voraussetzungen
Was wir sehen müssen, bevor wir einschätzen
Wir brauchen Zugriff auf Quellcode und Build-Prozess, Betriebsdokumentation oder Betriebswissen, eine Liste der Abhängigkeiten (Datenbanken, Dateiablagen, externe Dienste), Last- und Verfügbarkeitsanforderungen, die Zielumgebung und einen fachlichen Ansprechpartner.
Ohne Quellcode-Zugriff ist eine Containerisierung nur eingeschränkt möglich; das klären wir im Assessment.
08Grenzen
Wann ein Container nicht die Antwort ist
Wir arbeiten in Ihren Repositories und Umgebungen, zeitlich und rollenbasiert begrenzt. Anwendungslogik ändern wir nur nach Auftrag. Den Clusterbetrieb übernimmt Managed Kubernetes; Vertiefung zur Absicherung: Cloud Security.
Das Vorhaben passt, wenn …
- Quellcode, Build-Prozess und Betriebswissen zugänglich sind.
- Sie Anwendungen reproduzierbar und gehärtet ausliefern wollen.
Das spricht dagegen
- Die Anwendung ist klein und stabil auf einer VM; Containerisierung bringt dann oft keinen Nutzen, und wir sagen das im Assessment.
- Es gibt keinen Zugriff auf den Quellcode und keine Betriebsdokumentation.
- Ein Monolith soll nebenbei in Microservices zerlegt werden; das ist ein eigenes Vorhaben: Application-Modernisierung.
Anfrage
Welche Anwendung soll als Erste umziehen?
Nennen Sie uns Ihre Anwendungen mit Technologie und Zustandsverhalten. Der Aufwand richtet sich nach Zahl und Art der Anwendungen (zustandslos oder zustandsbehaftet), Zustand von Build und Dokumentation, Sicherheitsvorgaben und Zielplattform; danach richtet sich der Umfang des Angebots.