--- title: "Anwendungen containerisieren für Kubernetes | SKAFFON" description: "Containerisierung als Dienstleistung: Anwendungs-Assessment, OCI-Images, zustandslos und zustandsbehaftet (CloudNativePG), Härtung nach Pod Security Standards." url: https://skaffon.de/leistungen/containerisierung/ --- ![Containerhafen im Sonnenuntergang mit Verladekränen und gestapelten Frachtcontainern](/_astro/containerhafen-sonnenuntergang.D2OuT3v3_Z1ggzIJ.jpg) 1. [Startseite](/) 2. [Leistungen](/leistungen/) 3. Anwendungen containerisieren und Kubernetes-ready machen 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. [Anwendungen nennen](/projekt-anfragen/) [Alle Leistungen](/leistungen/) - OCI-Images ohne Geheimnisse - Zustandslos und zustandsbehaftet - Ziel: Pod Security Standard Restricted Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## 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](/leistungen/kubernetes-beratung/). Die tiefergehende Umgestaltung von Anwendungen ist [Application-Modernisierung](/software/application-modernisierung/). Typische Auslöser Konfiguration auf VMs wird von Hand gepflegt. Ein Docker-Setup läuft nur auf dem Entwicklerrechner. Eine Datenbank soll mit in den Cluster, und niemand weiß, ob das sinnvoll ist. Die Anwendung kennt weder Health-Checks noch sauberes Beenden. Dabei 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](/leistungen/gitops-argocd/) und [CI/CD](/leistungen/ci-cd-pipelines/). - ### 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. Entscheidung ## Welcher Weg passt zu welcher Anwendung? Die [Open Container Initiative](https://opencontainers.org/about/overview/) definiert Runtime-, Image- und Distribution-Spezifikation; Images nach diesem Standard laufen auf kompatiblen Laufzeiten, das ist die Grundlage für Portabilität zwischen Plattformen. __Entscheidungsmatrix: Anwendungstyp, Containerisierungsweg, Kubernetes-Ready-Kriterien und Risiko__ | 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 | Entscheidungsfluss ## Direkt containerisieren, Zustand auslagern oder VM belassen Die erste Frage an jede Anwendung ist, ob sie lokalen Zustand hat. Daraus folgt der Weg. Sonderfall Datenbank ## PostgreSQL im Cluster: Operator oder verwalteter Dienst? [CloudNativePG](https://cloudnative-pg.io/) 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. [PostgreSQL-Datenbanken](/daten/postgresql-datenbanken/) ![Aufgeschnittene Festplatte mit Platine und Datenträgermechanik vor hellem Hintergrund](/_astro/aufgeschnittene-festplatte-platine-datentraegermechanik.DuN5FhAN_Z2bIR4E.jpg) Härtung ## Sechs Prüfpunkte bis Restricted Die Kubernetes-Dokumentation definiert drei [Pod Security Standards](https://kubernetes.io/docs/concepts/security/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. Voraussetzungen ## 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. ![Haftnotizen an einem Whiteboard bei einer Planungsrunde](/_astro/haftnotizen-whiteboard-planungsrunde.B6KPQtWW_Z1x7iP5.jpg) Grenzen ## 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](/managed-services/managed-kubernetes/); Vertiefung zur Absicherung: [Cloud Security](/cybersecurity/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](/software/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. [Projekt anfragen](/projekt-anfragen/) [Alle Leistungen](/leistungen/)