Container haben die Art und Weise verändert, wie Software entwickelt, ausgeliefert und betrieben wird. Docker als Container-Runtime und Kubernetes als Orchestrierungsplattform sind heute Standard für moderne Anwendungen. Wir bauen produktive Container-Setups – mit allem, was dazugehört: Sicherheits-Härtung, Monitoring, Auto-Scaling und sinnvollem Resource-Management.
Warum Container?
Container lösen das „Bei mir funktioniert es”-Problem. Anwendungen laufen in isolierten, reproduzierbaren Umgebungen – egal ob auf dem Entwickler-Laptop, in der Staging-Umgebung oder in Produktion. Das macht Deployments planbar, Tests aussagekräftig und Skalierung einfach.
Docker für Standalone-Setups
Was wir mit Docker bauen
- Multi-Stage-Dockerfiles für minimale Image-Größen und schnelle Builds
- Docker-Compose-Setups für lokale Entwicklungsumgebungen
- Container-Sicherheits-Härtung mit Distroless-Images, Non-Root-Usern, Read-Only-Filesystems
- Private Container-Registries mit GitLab Registry, AWS ECR, GitHub Packages
- Vulnerability-Scanning mit Trivy oder Snyk
Kubernetes für komplexe Setups
Kubernetes ist die De-facto-Standard-Plattform für Container-Orchestrierung. Wir bauen Kubernetes-Cluster auf verschiedenen Plattformen:
Managed Kubernetes
Amazon EKS, Azure AKS, Google GKE, IONOS Managed Kubernetes – Hyperscaler-Plattformen mit Control-Plane als Service. Schnell zu starten, weniger administrativer Aufwand, dafür Vendor-spezifische Details.
Self-Managed Kubernetes
Für volle Kontrolle und maximale Flexibilität: Self-Managed-Cluster mit kubeadm oder k3s auf eigenen Servern. Sinnvoll bei strengen Compliance-Anforderungen oder Cost-Optimization in größeren Setups.
OpenShift für Enterprise
Red Hats OpenShift erweitert Kubernetes um Enterprise-Features: integriertes CI/CD, strenger Security-Default, RBAC out-of-the-box. Häufig die Wahl im Großkonzern- und Behörden-Umfeld.
Kubernetes-Best-Practices, die wir umsetzen
Helm und Kustomize für Manifest-Management
Statt jede YAML-Datei einzeln zu pflegen, nutzen wir Helm für versionierte, parametrisierbare Releases und Kustomize für umgebungsspezifische Overlays. Damit wird Kubernetes-Konfiguration handhabbar.
Resource-Limits und Requests
Jeder Pod hat definierte CPU- und Memory-Anforderungen. Damit verteilt der Scheduler Pods sinnvoll, und ein außer Kontrolle geratener Container reißt nicht den ganzen Node mit.
Liveness- und Readiness-Probes
Kubernetes muss wissen, wann ein Pod gesund ist. Wir konfigurieren Liveness-Probes (restartet defekte Pods), Readiness-Probes (entfernt Pods aus Load-Balancer, wenn sie nicht bereit sind) und Startup-Probes (für Anwendungen mit langer Startup-Zeit).
Network-Policies
Default-Deny-Netzwerk – Pods kommunizieren nur, wenn explizit erlaubt. Das ist „Zero Trust” auf Kubernetes-Ebene und stoppt Lateral-Movement bei kompromittierten Containern.
Secrets Management
Keine Secrets in Plain-Text-YAML. Wir nutzen External Secrets Operator mit HashiCorp Vault oder AWS Secrets Manager, oder Sealed Secrets für Git-fähige verschlüsselte Secrets.
Wann Kubernetes Sinn ergibt – und wann nicht
Kubernetes ist mächtig, aber nicht für jede Anwendung notwendig. Wir empfehlen Kubernetes wenn:
- Sie mehrere Microservices betreiben
- Auto-Scaling über mehrere Dimensionen nötig ist
- Mehrere Teams parallel deployen wollen
- Multi-Tenancy oder Multi-Region-Setups gefordert sind
Für einfachere Anwendungen empfehlen wir Container Services wie AWS ECS, Azure Container Apps, Google Cloud Run oder schlicht VM-basierte Setups – weniger Komplexität, oft günstiger.
Verwandte Leistungen
Container-Images entstehen in CI/CD-Pipelines. Kubernetes-Cluster werden über Infrastructure as Code deklariert. Container-Sicherheit ist Teil von DevSecOps. Sichtbarkeit über Cluster und Pods: Monitoring & Observability. Übersicht: DevOps-Engineering.
Mini-Case aus unserer Praxis
Container-Migration mittelständischer Anwendung
Migration einer klassisch deployten PHP/MySQL-Anwendung auf containerbasiertes Setup. Ausgangslage: zwei dedizierte Server mit manuell installierter Software, Deployment per rsync, kein Staging, Updates mit Risiko. Maßnahmen: Multi-Stage-Dockerfile für die Anwendung (Build-Stage + Production-Stage), Docker Compose für lokale Entwicklung und Staging, Migration auf Kubernetes-Cluster bei IONOS Managed Kubernetes für Production, Helm-Charts für Versionierung der Konfiguration, Sealed Secrets für sicheres Secret-Management. Resultat: Deployment-Zeit drastisch reduziert, identische Umgebungen über Dev/Staging/Production, automatische Selbstheilung bei Pod-Ausfällen.
Häufige Fragen zu Kubernetes und Docker
Brauchen wir wirklich Kubernetes?
Ehrliche Antwort: oft nicht. Kubernetes ist mächtig, aber auch komplex und betreuungs-intensiv. Für kleinere Anwendungen reichen Container-Services wie AWS ECS, Azure Container Apps oder Google Cloud Run vollkommen aus. Kubernetes lohnt sich ab mehreren Microservices, Multi-Tenant-Setups oder spezifischen Skalierungs-Anforderungen.
Managed Kubernetes oder Self-Managed?
Für 90 Prozent unserer Kunden: Managed (EKS, AKS, GKE, IONOS Managed Kubernetes). Vorteile: keine Control-Plane-Wartung, automatisierte Updates, Cloud-Integration out-of-the-box. Self-Managed nur bei sehr spezifischen Compliance-Anforderungen oder wenn vollständige Kontrolle technisch erforderlich ist.
Wie groß sollte ein Kubernetes-Cluster sein?
Eine Mindestgröße von 3 Worker-Nodes für Production – damit Pod-Disruption-Budgets und Rolling-Updates ohne Service-Unterbrechung funktionieren. Skalierung erfolgt auf Wunsch automatisch über Cluster-Autoscaler bei Lastspitzen.
Was ist mit Container-Sicherheit?
Wir nutzen Distroless oder Alpine-basierte minimale Base-Images, Non-Root-User für alle Container, Read-Only-Filesystems wo möglich. Vulnerability-Scanning mit Trivy in der Pipeline, Runtime-Security mit Falco. Network Policies erzwingen Default-Deny zwischen Pods. Mehr unter DevSecOps.
