Skalierung:<\/strong> Wir wollten untersuchen, wie Kubernetes mehrere InstanzenDabei ging es nicht darum, eine vollst\u00e4ndig hochverf\u00fcgbare Produktionsplattform zu bauen.<\/p>\n\n\n\n
Terraform: Infrastruktur als Code<\/h3>\n\n\n\n Mit Terraform erstellen wir den Hetzner-Server und die zugeh\u00f6rige Firewall. Beim Start richtet Cloud-Init den Deploy-Benutzer ein und installiert k3s. Dadurch kann ein neuer Server automatisch vorbereitet werden.<\/p>\n\n\n\n
Wir mussten unterscheiden, wof\u00fcr Terraform und Kubernetes zust\u00e4ndig sind: Terraform stellt die Maschine bereit. Kubernetes verwaltet anschlie\u00dfend die Anwendung, ihre Pods und Services.<\/p>\n\n\n\n
Dabei mussten wir besonders auf den Terraform-State achten. Der State enth\u00e4lt Informationen dar\u00fcber, welche Cloud-Ressourcen zu einer Konfiguration geh\u00f6ren. Wir verwenden deshalb einen Remote-State in GitLab. W\u00e4hrend der Entwicklung wurde uns klar, dass getrennte Terraform-Verzeichnisse allein nicht ausreichen, wenn sie versehentlich denselben State verwenden. Ein falsch gesetzter State-Name kann dazu f\u00fchren, dass Terraform Ressourcen einer anderen Infrastruktur zuordnet.<\/p>\n\n\n\n
Passw\u00f6rter, API-Tokens und private Schl\u00fcssel d\u00fcrfen weder im Repository noch im State landen. Sensible Werte werden \u00fcber Umgebungsvariablen und GitLab-CI\/CD-Variablen bereitgestellt. F\u00fcr den initialen SSH-Zugriff verwenden wir lokal einen SSH-Agent.<\/p>\n\n\n\n
Deployment: Von Docker Compose zu Kubernetes<\/h3>\n\n\n\n Unser erster Deployment-Ansatz basierte auf Docker Compose. Terraform erstellte einen Server. Die Pipeline hat die Compose- und Nginx-Konfiguration per SSH auf den Server \u00fcbertragen. Dort hat Docker Compose die Images aus der GitLab Registry geladen und sie gestartet. Dieser Ansatz hat uns geholfen, den Ablauf zu verstehen: Server erstellen, Images bereitstellen, Umgebungsvariablen setzen und die Anwendung erreichbar machen.<\/p>\n\n\n\n
Im Laufe des Projekts wurde uns klar, dass Docker Compose f\u00fcr unser eigentliches Lernziel nicht ausreicht. Wir wollten Pods, Services und automatische Skalierung kennenlernen. Deshalb wechselten wir zu k3s, einer schlanken Kubernetes-Distribution.<\/p>\n\n\n\n
Zun\u00e4chst probierten wir Kubernetes lokal mit Docker Desktop aus. So konnten wir schrittweise verstehen, wie Pods und Services funktionieren, bevor wir den vollst\u00e4ndigen Aufbau auf dem Hetzner-Server einrichteten. Anschlie\u00dfend wurden Backend, Frontend, MongoDB, Redis und das NGINX-Gateway als Kubernetes-Ressourcen definiert.<\/p>\n\n\n\n
Anfangs verwendeten wir SSH-Skripte, um Dateien auf den Server zu kopieren und dort Kubernetes-Befehle auszuf\u00fchren. Sp\u00e4ter ersetzten wir dieses Verfahren durch den GitLab Kubernetes Agent. Der Agent l\u00e4uft im Cluster und verbindet sich mit GitLab. Die Pipeline kann dadurch \u00fcber den Kubernetes-Kontext des Agents auf den Cluster zugreifen und die Manifeste mit kubectl<\/code>\u00a0anwenden.<\/p>\n\n\n\nDiese Kommunikation war anfangs schwer nachzuvollziehen, weil die Pipeline nicht einfach per SSH auf dem Server arbeitet. Der Ablauf besteht aus mehreren Teilen: GitLab CI baut die Images, die Container Registry speichert sie, der Agent verbindet GitLab mit Kubernetes und Kubernetes startet die neue Version der Anwendung.<\/p>\n\n\n\n
Die beiden Deployment-Ans\u00e4tze<\/h4>\n\n\n\nDocker Compose<\/th> Kubernetes\/k3s<\/th><\/tr><\/thead> Einfache Orchestrierung auf einem Server<\/td> Verwaltung der Anwendung in einem Cluster<\/td><\/tr> Container werden direkt gestartet<\/td> Anwendung l\u00e4uft in Pods<\/td><\/tr> Weniger automatische Skalierung<\/td> HPA kann Pods automatisch skalieren<\/td><\/tr> Gut f\u00fcr den ersten Deployment-Schritt<\/td> N\u00e4her an einem realit\u00e4tsnahen Cloud-Deployment<\/td><\/tr> Bereitstellung zun\u00e4chst per SSH <\/td> Bereitstellung \u00fcber den GitLab Kubernetes Agent<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nSkalierung und Redis<\/h3>\n\n\n\n F\u00fcr die Skalierung verwenden wir den Horizontal Pod Autoscaler von Kubernetes. Der HPA \u00fcberwacht die CPU-Auslastung und passt die Anzahl der Pods an. F\u00fcr das Backend sind zwei bis f\u00fcnf Pods vorgesehen, f\u00fcr das Gateway zwei bis vier.<\/p>\n\n\n\n
Die Skalierung hat erfolgreich funktioniert. Unter Last startete Kubernetes automatisch zus\u00e4tzliche Backend- und Gateway-Pods. Damit konnten wir die horizontale Skalierung praktisch nachstellen.<\/p>\n\n\n\n
Redis war wichtig, damit der Chat auch mit mehreren Backend-Pods funktioniert. Eine WebSocket-Verbindung ist immer an einen bestimmten Backend-Pod gebunden. Wenn ein Benutzer mit Pod A und ein anderer mit Pod B verbunden ist, kennen die beiden Pods ihre jeweiligen Verbindungen nicht automatisch. Ohne Redis k\u00f6nnte eine Nachricht deshalb nur lokal beim jeweiligen Pod ankommen.<\/p>\n\n\n\n
\u00dcber Redis Pub\/Sub werden Nachrichten, Direktnachrichten, L\u00f6schereignisse und \u00c4nderungen des Online-Status zwischen den Pods verteilt. Jede Backend-Instanz besitzt einen Redis-Listener und leitet empfangene Ereignisse an ihre lokal verbundenen WebSockets weiter. Dadurch funktioniert der Chat auch dann, wenn Benutzer auf unterschiedlichen Pods landen.<\/p>\n\n\n\n
Auch mit nur einem Backend-Pod laufen Chat-Ereignisse in unserer Anwendung \u00fcber Redis. Bei mehreren Pods muss man beachten, dass Nachrichten alle Backend-Instanzen erreichen, weil jeder Pod nur seine eigenen WebSocket-Verbindungen kennt.<\/p>\n\n\n\n
Lasttests und Grenzen<\/h3>\n\n\n\n Mit k6 haben wir die Anwendung unter steigender Last getestet. Neben normalen Lasttests f\u00fchrten wir auch extreme Tests mit 300 und 600 virtuellen Benutzern durch. Diese Tests sollten keine realistische Dauerlast darstellen, sondern bewusst zeigen, wo die Grenzen der Anwendung und der Infrastruktur liegen.<\/p>\n\n\n\n
Dabei stellten wir fest, dass das Gateway die erste Engstelle war. Bereits bevor das Backend vollst\u00e4ndig ausgelastet war, traten am NGINX-Gateway h\u00f6here Antwortzeiten und teilweise Verbindungsfehler auf. Durch zus\u00e4tzliche Gateway-Pods konnte die Stabilit\u00e4t verbessert werden.<\/p>\n\n\n\n
Au\u00dferdem wurde uns klar, dass Pod-Skalierung allein keine unbegrenzte Skalierung bedeutet. Alle Pods liefen weiterhin auf demselben Hetzner-Server und teilten sich dessen CPU- und Speicherressourcen. Der einzelne Node setzte daher ein Limit.<\/p>\n\n\n\n
Um \u00fcber die Kapazit\u00e4t unseres einzelnen Hetzner-Servers hinaus zu skalieren, h\u00e4tten wir weitere Nodes ben\u00f6tigt. Diese h\u00e4tten wir auch manuell einrichten k\u00f6nnen. F\u00fcr das automatische Hinzuf\u00fcgen weiterer Server w\u00e4re zus\u00e4tzlich eine passende Autoscaling-L\u00f6sung n\u00f6tig gewesen. Das haben wir in diesem Projekt nicht umgesetzt. Trotzdem konnten wir die Pod-Skalierung erfolgreich testen und eine automatische Skalierung innerhalb der vorhandenen Infrastruktur demonstrieren.<\/p>\n\n\n\n
Ergebnisse der Lasttests<\/h4>\n\n\n\n\n
\n
Test<\/th> Last<\/th> Beobachtung<\/th><\/tr><\/thead> Normaler Lasttest<\/td> 100 VUs<\/td> 49.691 Requests, 0 % Fehler, P95-Latenz von 290 ms. Der HPA reagierte bereits auf diese Last und startete zus\u00e4tzliche Pods.<\/td><\/tr> Stresstest<\/td> 300 VUs<\/td> Die Latenz stieg deutlich an. Das Gateway war stark ausgelastet, konnte die meisten Anfragen aber noch verarbeiten.<\/td><\/tr> Grenztest<\/td> 600 VUs<\/td> Die Latenz erh\u00f6hte sich extrem. Das Gateway erreichte seine Belastungsgrenze und konnte viele Anfragen nicht mehr verarbeiten.<\/td><\/tr><\/tbody><\/table><\/figure>\n<\/div>\n<\/div>\n\n\n\nHerausforderungen<\/h3>\n\n\n\n Die gr\u00f6\u00dfte Herausforderung war das Zusammenspiel der verschiedenen Werkzeuge. Zun\u00e4chst war nicht klar, wie GitLab CI\/CD den Kubernetes-Cluster erreicht. er erste Ansatz verwendete SSH-Skripte und sp\u00e4ter wechselten wir zum GitLab-Kubernetes-Agenten. Dieser Wechsel erforderte ein neues Verst\u00e4ndnis davon, wie Pipeline, Container Registry und Cluster miteinander verbunden sind.<\/p>\n\n\n\n
Der Wechsel von Docker Compose zu K3s hat l\u00e4nger gedauert als gedacht. Wir mussten uns zun\u00e4chst mit Pods, Services, Deployments und Kubernetes-internen Namen vertraut machen. Erst danach konnten wir Backend, Frontend, MongoDB, Redis und NGINX gemeinsam im Cluster betreiben.<\/p>\n\n\n\n
Bei der CI-Konfiguration f\u00fchrten Protected Variables zu einem weiteren Problem. Unser Feature-Branch war zun\u00e4chst nicht gesch\u00fctzt, daher erhielt die Pipeline den gesch\u00fctzten SSH-Key nicht. Zus\u00e4tzlich war nicht abgestimmt, obSSH_PRIVATE_KEY<\/code> als Text- oder File-Variable angelegt wird. Bei einer File-Variable muss das Skript den Pfad zu einer tempor\u00e4ren Datei verarbeiten, nicht den Key direkt.<\/p>\n\n\n\nAuch die Tests und die Infrastruktur erforderten Fehlersuche. Ein Hintergrundprozess f\u00fcr den Redis-Listener lie\u00df pytest<\/code> in GitLab h\u00e4ngen und musste in den Tests kontrolliert werden. Nach dem Ersetzen eines Servers mussten wir au\u00dferdem SSH-Warnungen wegen eines ge\u00e4nderten Host-Keys pr\u00fcfen. Als wir versehentlich den falschen Terraform-State verwendeten, wurde der Compose-Server zerst\u00f6rt. Deswegen sollte vor terraform apply<\/code> gepr\u00fcft werden, welchen State Terraform verwendet und welche \u00c4nderungen der Plan anzeigt.<\/p>\n\n\n\nF\u00fcr die Lasttests war der GitLab Runner kein zuverl\u00e4ssiger Ausgangspunkt, da er den \u00f6ffentlichen NodePort nicht immer erreichen konnte. Wir f\u00fchrten k6 daher lokal aus.<\/p>\n\n\n\n
Was wir gelernt haben<\/h3>\n\n\n\n Wir haben gelernt, Infrastructure as Code mit Terraform selbst zu programmieren, anzuwenden und mit einem automatisierten Deployment zu verbinden. Nach dem Docker-Compose-Setup richteten wir die Anwendung auch mit K3s, Services und mehreren Pods ein.<\/p>\n\n\n\n
Au\u00dferdem wurde deutlich, dass Skalierung mehr bedeutet als nur die Anzahl der Replicas zu erh\u00f6hen. Redis ist notwendig, damit mehrere Backend-Pods bei WebSocket-Kommunikation zusammenarbeiten. Mit k6 konnten wir Last gezielt steigern, w\u00e4hrend wir Pods, Ressourcenauslastung, Antwortzeiten und Fehlerraten beobachteten. So wurde sichtbar, wann der HPA skaliert, dass das Gateway die erste Engstelle bildet und dass ein einzelner Server die weitere Skalierung begrenzt.<\/p>\n\n\n\n
Unser wichtigstes \u00fcbergreifendes Learning ist daher, dass ein Deployment aus mehreren \u00fcberpr\u00fcfbaren Schritten besteht: Infrastruktur erstellen, Images bauen, Anwendung deployen, Kommunikation zwischen Instanzen sicherstellen und das Verhalten unter Last messen. Erst das Zusammenspiel dieser Schritte zeigt, ob die Anwendung in der Cloud tats\u00e4chlich funktioniert.<\/p>\n\n\n\n
Projektteam<\/h3>\n\n\n\n\nHenry Spechtenhauser – @hs128<\/li>\n\n\n\n Georgi Bozhilski – @gb040<\/li>\n\n\n\n Martin Herdt – @mh370<\/li>\n\n\n\n Asim Jugo – @aj049<\/li>\n<\/ul>\n\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Ausgangspunkt und Tech-Stack Unsere Chat-Anwendung entstand urspr\u00fcnglich als lokales Projekt. F\u00fcr das Cloud-Computing-Projekt wollten wir deshalb nicht die Anwendung neu entwickeln, sondern herausfinden, wie sie sich in der Cloud betreiben l\u00e4sst. Die Anwendung besteht aus einem React-Frontend mit Vite und einem FastAPI-Backend. WebSockets erm\u00f6glichen die Echtzeitkommunikation. MongoDB speichert die Nachrichten, Redis verteilt Ereignisse zwischen mehreren […]<\/p>\n","protected":false},"author":1339,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false,"_ppma_block_editor_authors":""},"categories":[120,659,650,22,21,2,662],"tags":[],"ppma_author":[1272],"class_list":["post-29471","post","type-post","status-publish","format-standard","hentry","category-cloud-technologies","category-devops","category-scalable-systems","category-student-projects","category-system-architecture","category-system-engineering","category-web-performance"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/09\/techstack.webp\")
<\/a><\/figure>\n\n\n\n