Container-Infrastruktur aufbauen: 7 Entscheidungen

Ein neues digitales Produkt startet oft mit wenigen Services, einem Repository und einem Deployment-Skript. Spätestens wenn mehrere Teams entwickeln, Integrationen zu SAP oder Drittsystemen hinzukommen und Verfügbarkeit zur Geschäftsanforderung wird, reicht das nicht mehr. Wer eine Container-Infrastruktur aufbauen möchte, trifft daher keine reine Hosting-Entscheidung. Es geht um eine Betriebsplattform, die Entwicklung beschleunigt, Risiken kontrolliert und mit dem Produkt wachsen kann.

Die zentrale Frage lautet nicht: Brauchen wir Kubernetes? Sie lautet: Welche Betriebsfähigkeit benötigt unser Produkt in den nächsten zwei bis drei Jahren? Eine überdimensionierte Plattform bindet Budget und Spezialwissen. Eine zu einfache Lösung erzeugt später manuelle Abläufe, Sicherheitslücken und schwer planbare Releases. Gute Architektur beginnt deshalb beim Geschäftsmodell, den Prozessen und den tatsächlichen Lastprofilen.

1. Das Betriebsmodell vor der Technologie festlegen

Container sind eine Verpackungseinheit für Anwendungen. Sie lösen noch nicht, wie Teams Releases koordinieren, Geheimnisse verwalten, Fehler erkennen oder im Störungsfall reagieren. Bevor Sie konkrete Tools auswählen, sollten Verantwortlichkeiten und Betriebsziele klar sein.

Für ein internes Fachsystem mit wenigen Nutzern gelten andere Anforderungen als für eine SaaS-Plattform mit Kundenportal, mobilen Apps und zeitkritischen Schnittstellen. Prüfen Sie insbesondere, welche Verfügbarkeit erforderlich ist, welche Daten verarbeitet werden, wie schnell neue Versionen produktiv gehen sollen und wer außerhalb der Entwicklungszeit auf Incidents reagiert.

Auch die Frage nach dem Betriebsort gehört früh auf den Tisch. Eine Public Cloud bietet schnell verfügbare Managed Services und flexible Skalierung. Ein deutsches Rechenzentrum oder eine souveräne Cloud kann bei regulatorischen Vorgaben, sensiblen Daten oder Beschaffungsregeln die passendere Wahl sein. Hybrid-Szenarien sind sinnvoll, wenn bestehende On-Premises-Systeme angebunden werden müssen. Sie erhöhen jedoch die Komplexität bei Netzwerken, Identitäten und Monitoring.

2. Die passende Orchestrierung wählen

Nicht jede Anwendung braucht vom ersten Tag an einen großen Kubernetes-Cluster. Für überschaubare Anwendungen mit klaren Lastprofilen kann ein Managed Container Service oder eine einfache Orchestrierung die wirtschaftlichere Wahl sein. Teams erhalten reproduzierbare Deployments, ohne eine umfangreiche Cluster-Administration etablieren zu müssen.

Kubernetes spielt seine Stärken aus, wenn mehrere Services, Umgebungen und Teams zuverlässig koordiniert werden sollen. Es unterstützt automatisierte Rollouts, Selbstheilung, horizontale Skalierung und eine konsistente Auslieferung über Entwicklungs-, Test- und Produktionsumgebungen hinweg. Der Preis dafür ist eine höhere fachliche und operative Komplexität. Cluster-Upgrades, Netzwerkregeln, Rechtekonzepte und Kostensteuerung benötigen klare Ownership.

Ein Managed-Kubernetes-Angebot reduziert den Aufwand für die Control Plane, ersetzt aber nicht den Betrieb. Sie bleiben verantwortlich für Workloads, Zugriffsrechte, Images, Konfigurationen, Observability und die Absicherung der Lieferkette. Entscheidend ist deshalb nicht nur, was die Plattform technisch kann, sondern welches Wissen im eigenen Team vorhanden ist und welche Aufgaben ein Technologiepartner dauerhaft übernimmt.

3. Container-Infrastruktur aufbauen heißt: Standards schaffen

Die größte Wirkung entsteht nicht durch den einzelnen Container, sondern durch verbindliche Standards. Wenn jedes Team eigene Base Images, Deployment-Dateien und Konfigurationsmuster verwendet, werden Wartung und Sicherheitsprüfungen mit jedem Service teurer.

Sinnvoll sind schlanke, versionierte Basisimages, die regelmäßig aktualisiert werden. Anwendungen sollten als nicht privilegierte Nutzer laufen, nur notwendige Komponenten enthalten und ihre Konfiguration über die Umgebung erhalten. Das macht Images kleiner, reduziert Angriffsflächen und verhindert, dass Zugangsdaten oder umgebungsspezifische Werte im Image landen.

Ebenso wichtig sind standardisierte Templates für neue Services. Dazu zählen eine einheitliche Projektstruktur, Health Checks, Logging im strukturierten Format, Metriken und ein definierter Weg für Konfigurationswerte. Ein neuer Microservice sollte nicht jedes Mal eine Architekturentscheidung auslösen. Er sollte auf einer geprüften Grundlage starten und sich nur dort unterscheiden, wo fachliche Anforderungen es verlangen.

4. CI/CD als kontrollierten Lieferprozess behandeln

Der Build einer Anwendung ist erst dann belastbar, wenn er automatisiert, nachvollziehbar und wiederholbar ist. Eine Pipeline sollte Code prüfen, Tests ausführen, ein unveränderliches Container Image erzeugen und dieses in einer zentralen Registry ablegen. Jede produktive Version muss auf einen eindeutigen Commit und ein eindeutig versioniertes Image zurückführbar sein.

Für die Auslieferung ist die Trennung von Build und Deployment entscheidend. Ein einmal gebautes Artefakt wird durch die Umgebungen bewegt, statt pro Umgebung neu erzeugt zu werden. Dadurch testen Sie exakt die Version, die später produktiv läuft. Freigaben können dort erfolgen, wo sie geschäftlich oder regulatorisch nötig sind, ohne den Prozess manuell und fehleranfällig zu machen.

Je nach Risiko eignen sich Rolling Updates, Blue-Green-Deployments oder Canary Releases. Ein Canary Release ist besonders sinnvoll, wenn reale Nutzungssignale schnell zeigen, ob eine Änderung Probleme verursacht. Für ein selten genutztes internes System kann der zusätzliche Aufwand dagegen unverhältnismäßig sein. Wichtig bleibt immer ein getesteter Rollback: Nicht das Deployment selbst, sondern die schnelle Rückkehr zu einer funktionierenden Version entscheidet im Ernstfall.

5. Sicherheit in die Plattform integrieren

Sicherheit ist kein letzter Prüfschritt vor dem Go-live. Sie beginnt in der Lieferkette und setzt sich über Netzwerk, Identitäten und Laufzeit fort. Container Images sollten automatisiert auf bekannte Schwachstellen geprüft werden. Kritische Funde brauchen einen klaren Prozess: Wer bewertet sie, bis wann wird aktualisiert und wann blockiert ein Befund das Release?

Secrets gehören weder in Quellcode noch in Konfigurationsdateien im Repository. Eine zentrale Secret-Verwaltung mit kurzen Zugriffswegen, Rotation und nachvollziehbaren Berechtigungen verhindert viele vermeidbare Risiken. In der Praxis scheitert das oft nicht an fehlender Technologie, sondern an zu breiten Rechten und unklaren Zuständigkeiten.

Auf Netzwerkebene gilt das Prinzip der minimalen Kommunikation. Ein Service sollte nur die Systeme erreichen, die er tatsächlich benötigt. Mandantentrennung, Verschlüsselung der Datenübertragung, getrennte Service Accounts und rollenbasierte Berechtigungen begrenzen den Schaden, falls ein Zugang kompromittiert wird. Bei personenbezogenen Daten oder KI-gestützten Prozessen müssen diese Maßnahmen mit Datenschutz, Aufbewahrungsfristen und fachlichen Berechtigungskonzepten zusammengedacht werden.

6. Observability vor dem ersten Incident etablieren

Wenn ein Service ausfällt, reichen Servermetriken nicht aus. Betriebsteams müssen erkennen, welcher Geschäftsprozess betroffen ist, wo eine Anfrage scheitert und ob die Ursache im eigenen Code, in einer Datenbank oder in einer externen Schnittstelle liegt. Dafür greifen Logs, Metriken und Traces ineinander.

Metriken zeigen Trends wie Antwortzeiten, Fehlerraten, Ressourcenauslastung oder Queue-Längen. Strukturierte Logs liefern Kontext zu einzelnen Ereignissen. Distributed Tracing verfolgt einen Request über mehrere Services hinweg. Gerade bei Microservice-Architekturen und SAP-Integrationen spart diese Kombination im Störungsfall Stunden an Analysezeit.

Definieren Sie Alarme nicht für jede technische Auffälligkeit, sondern für Zustände mit Handlungsbedarf. Ein hoher CPU-Wert kann harmlos sein, wenn die Antwortzeiten stabil bleiben. Eine steigende Fehlerrate im Checkout, bei einer Auftragsschnittstelle oder bei der Anmeldung ist dagegen ein klarer Geschäftsalarm. Runbooks mit konkreten Prüfschritten helfen, dass nicht nur einzelne Experten reagieren können.

7. Daten, Kosten und Skalierung realistisch planen

Container sind zustandsarm gedacht. Datenbanken, Dateien, Suchindizes und Nachrichtenwarteschlangen bleiben dennoch zentrale Bestandteile der Architektur. Für produktive Systeme sind Managed Services oft sinnvoller als selbst betriebene Datenbanken im Cluster: Backups, Hochverfügbarkeit, Patches und Wiederherstellung lassen sich verlässlicher organisieren. Das ist besonders relevant, wenn Datenverlust oder längere Ausfälle direkte Auswirkungen auf Kunden und operative Prozesse haben.

Skalierung bedeutet nicht nur, bei Last mehr Container zu starten. Datenbankverbindungen, externe APIs, Rate Limits und Hintergrundjobs können zum Engpass werden. Lasttests sollten deshalb reale Nutzungsmuster abbilden, etwa viele parallele Anfragen, große Imports oder saisonale Spitzen. Kapazitätsplanung wird belastbar, wenn sie mit Produktkennzahlen verbunden ist statt nur mit Infrastrukturmetriken.

Auch Kosten brauchen Transparenz. Ohne Ressourcenlimits und sinnvolle Requests reservieren Teams entweder zu viel Kapazität oder gefährden die Stabilität anderer Workloads. Tagging, getrennte Kostenstellen und regelmäßige Auswertung nach Service schaffen die Grundlage für Entscheidungen. Günstiger ist nicht automatisch besser: Ein etwas höherer Plattformpreis kann sich auszahlen, wenn Releases schneller erfolgen und Betriebsaufwand sinkt.

Von der Plattformidee zum belastbaren Betrieb

Der Aufbau sollte iterativ erfolgen. Starten Sie mit einer Referenzanwendung, einem klar abgegrenzten Produktbereich und wenigen wiederverwendbaren Standards. Daraus entstehen Templates, Betriebswissen und eine realistische Sicht auf Aufwand und Kosten. Erst dann lohnt es sich, die Plattform auf weitere Teams und Services auszuweiten.

entencode begleitet solche Vorhaben von der Zielarchitektur über die Umsetzung bis zum laufenden Cloud-Betrieb. Entscheidend ist dabei eine Plattform, die nicht nur technisch modern wirkt, sondern Releases, Integrationen und Wachstum im täglichen Geschäft zuverlässig trägt.

Die beste Container-Plattform ist nicht die mit den meisten Komponenten. Sie ist die, deren Regeln Teams verstehen, deren Betrieb Verantwortliche beherrschen und die dem digitalen Produkt Raum gibt, sich ohne technische Altlasten weiterzuentwickeln.