Container und Orchestrierung: Was Du wirklich brauchst

Stell Dir vor: Du hast eine kleine Webagentur. Dein KI-Chatbot laeuft zuverlaessig auf einem Debian-Server mit Apache und PHP. Eines Morgens liest Du einen Fachartikel, der behauptet, ohne Docker und Kubernetes sei man nicht mehr zeitgemaess. Du verbringst zwei Wochen damit, alles in Container zu packen. Danach funktioniert der Chatbot genauso wie vorher, aber Du hast jetzt 47 Konfigurationsdateien mehr und einen Server, der doppelt so viel Arbeitsspeicher braucht. Was ist passiert?

Du bist in eine Falle getappt, die viele kleine Unternehmen kennen. Technologie um der Technologie willen. Container sind ein grossartiges Werkzeug, aber sie loesen Probleme, die Du vielleicht gar nicht hast. Dieses Kapitel hilft Dir, das ehrlich einzuschaetzen.

Was Container eigentlich tun

Bevor der Begriff "Container" faellt, ein Bild: Stell Dir vor, Du ziehst in eine neue Wohnung. Statt alle Moebel einzeln zu transportieren und am neuen Ort wieder zusammenzubauen, packst Du jeden Raum komplett in eine Kiste. Kueche mit Herd, Geschirr und Gewuerzen. Badezimmer mit Spiegel, Handtuechern und Zahnbuerste. Jede Kiste funktioniert sofort, sobald Du sie oeffnest.

Genau das macht ein Container in der Softwarewelt. Er packt ein Programm zusammen mit allem, was es zum Laufen braucht: der richtigen Programmiersprachen-Version, allen Bibliotheken, den Einstellungen. Docker ist das bekannteste Werkzeug, um solche Container zu bauen und zu starten. Der Vorteil liegt auf der Hand: Was auf Deinem Entwicklungsrechner funktioniert, funktioniert auch auf dem Server. Keine boesen Ueberraschungen mehr, weil auf dem Server eine andere Version installiert ist.

Das klingt zunaechst nach einer Loesung fuer alles. Aber jede Loesung bringt eigene Herausforderungen mit. Die entscheidende Frage ist nicht "Sind Container gut?", sondern "Loesen Container ein Problem, das ich tatsaechlich habe?"

Wo Container einen echten Unterschied machen

Es gibt Situationen, in denen Container nicht nur praktisch, sondern fast unverzichtbar sind. Stell Dir eine kleine Agentur vor, die drei verschiedene KI-Projekte gleichzeitig betreut. Projekt A braucht Python 3.9 mit einer aelteren Version von TensorFlow. Projekt B laeuft nur mit Python 3.11 und PyTorch. Projekt C experimentiert mit einem brandneuen Framework, das ganz eigene Anforderungen hat.

Ohne Container wuerdest Du versuchen, alle drei Umgebungen auf demselben Server zu installieren. Das fuehrt fast unweigerlich zu Konflikten: Bibliothek X braucht Version 2.1, aber Bibliothek Y verlangt Version 1.8. Mit Containern hat jedes Projekt seine eigene, abgeschottete Umgebung. Sie koennen sich nicht gegenseitig in die Quere kommen.

Genauso wertvoll sind Container, wenn mehrere Menschen an einem Projekt arbeiten. Statt einer langen Anleitung "Installiere erst dies, dann das, aendere diese Einstellung" genuegt ein einziger Befehl, und jedes Teammitglied hat eine identische Arbeitsumgebung. Neue Kolleginnen und Kollegen koennen am ersten Tag produktiv sein, statt zwei Tage mit der Einrichtung zu kaempfen.

Warum Dein Server vielleicht keine Container braucht

Jetzt der Gegenpol, und der ist fuer kleine Unternehmen oft wichtiger. Stell Dir einen Handwerksbetrieb vor, der eine KI-gestuetzte Terminplanung auf seiner Webseite anbietet. Die PHP-Anwendung laeuft auf einem einfachen Server, ruft eine KI-Schnittstelle auf und zeigt das Ergebnis an. Der Server laeuft seit zwei Jahren stabil. Es gibt eine Anwendung, eine Datenbank, fertig.

Hier wuerde Docker nichts verbessern. Die Anwendung hat keine Versionskonflikte, weil es nur eine gibt. Es gibt kein Entwicklerteam, das identische Umgebungen braucht, weil eine Person die Wartung uebernimmt. Die Bereitstellung ist ein simples Kopieren von Dateien. Stattdessen wuerde Docker zusaetzliche Komplexitaet einfuehren: ein weiteres System, das verstanden, gewartet und aktualisiert werden muss.

Dazu kommt ein oft unterschaetzter Punkt: Wenn Deine KI-Anwendung direkt auf die Grafikkarte zugreift, um lokale Modelle auszufuehren, ist der direkte Hardwarezugriff ohne Container schneller und einfacher einzurichten. Die Weiterleitung der Grafikkarte in einen Container funktioniert, fuegt aber eine zusaetzliche Schicht hinzu, die Fehlerquellen und Leistungseinbussen mit sich bringt.

Das Kubernetes-Versprechen und seine Kosten

Wenn Container die Umzugskisten sind, dann ist Kubernetes der Umzugsservice, der automatisch entscheidet, welche Kiste in welchen Raum kommt, defekte Kisten ersetzt und bei Bedarf neue Raeume anbaut. Offiziell heisst das "Orchestrierung": die automatische Verwaltung vieler Container.

Fuer grosse Unternehmen mit hunderten Anwendungen und Millionen Nutzern ist Kubernetes ein Segen. Faellt ein Container aus, startet automatisch ein neuer. Kommen mehr Anfragen, werden zusaetzliche Container hochgefahren. Das System verwaltet sich weitgehend selbst.

Fuer ein kleines Unternehmen mit drei Servern sieht die Rechnung anders aus. Kubernetes selbst bringt dutzende neue Konzepte mit: Pods, Services, Ingress, ConfigMaps, Secrets, Helm-Charts. Jedes davon muss verstanden, konfiguriert und gewartet werden. Die Konfigurationsdateien allein koennen komplexer werden als die eigentliche Anwendung. Dazu kommt: Kubernetes braucht selbst erhebliche Rechenleistung. Auf einem kleinen Server kann es passieren, dass die Verwaltungssoftware mehr Ressourcen verbraucht als die Anwendung, die sie verwalten soll.

Ein Linux-Server mit systemd, dem eingebauten Dienst-Manager, kann fuer viele KI-Anwendungen dasselbe leisten: Dienste automatisch neu starten, Abhaengigkeiten verwalten, Protokolle fuehren. Ohne den Umweg ueber Container und Orchestrierung.

Sicherheit und Betrieb ehrlich verglichen

Ein haeufiges Argument fuer Container lautet: Sie sind sicherer, weil Anwendungen voneinander isoliert sind. Das stimmt grundsaetzlich. Aber diese Isolation ist nicht perfekt. Es gibt dokumentierte Faelle, in denen Angreifer aus einem Container ausbrechen und das gesamte System uebernehmen konnten. Container-Abbilder koennen Sicherheitsluecken enthalten, die niemand bemerkt, weil sie nicht aktiv geprueft werden. Und Kubernetes selbst wird zur Angriffsflaeche, die zusaetzlich abgesichert werden muss.

Bei einer nativen Installation auf einem gehaerteten Linux-Server ist die Angriffsflaeche kleiner und ueberschaubarer. Du aktualisierst ein System statt vieler Schichten. Das bedeutet nicht, dass native Installationen automatisch sicherer sind. Aber der Sicherheitsaufwand ist besser kalkulierbar.

Aehnlich verhaelt es sich mit der Datensicherung. Bei einer nativen Installation sicherst Du Dateien und Datenbanken. Bei einer Container-Umgebung kommen Container-Abbilder, dauerhafte Speicherbereiche und Konfigurationszustaende hinzu. Jede dieser Ebenen braucht eine eigene Sicherungsstrategie. Fuer ein kleines Team bedeutet das mehr Arbeit und mehr Stellen, an denen etwas schiefgehen kann.

Der kluge Mittelweg fuer kleine Unternehmen

Die beste Loesung ist oft ein Sowohl-als-auch, kein Entweder-oder. Viele erfahrene Entwickler nutzen Container dort, wo sie den groessten Vorteil bringen, und verzichten dort darauf, wo sie nur Komplexitaet hinzufuegen.

Ein bewaehrtes Vorgehen sieht so aus: Die Grundlage bildet eine solide, nativ installierte Infrastruktur. Apache, PHP, MariaDB laufen direkt auf dem Server. Sie sind erprobt, gut dokumentiert und brauchen wenig Aufmerksamkeit. Wenn Du dann ein neues KI-Framework testen moechtest, packst Du es in einen Container. So kannst Du experimentieren, ohne die stabile Umgebung zu gefaehrden. Und nur wenn sich herausstellt, dass ein Dienst tatsaechlich von Containern profitiert, etwa weil er regelmaessig in verschiedenen Versionen laufen muss, bleibt er dauerhaft containerisiert.

Das Entscheidende ist die Reihenfolge: Zuerst das Problem identifizieren, dann pruefen, ob Container es loesen. Nicht umgekehrt. Technik, die im Hintergrund zuverlaessig arbeitet und keine Aufmerksamkeit verlangt, ist gute Technik. Sobald die Werkzeuge mehr Pflege brauchen als die eigentliche Anwendung, stimmt das Verhaeltnis nicht mehr.