Kubernetes Feature Image

Autor-Facts

NameThomas Tischner
PositionSysadmin
13. Juli 2020

Wie Thomann den Umstieg auf Kubernetes meistert

Ein Umstieg auf Kubernetes. Als unser Systemadministrator Thomas von diesen Plänen hörte, war er sofort begeistert. "Kurz vor Weihnachten 2018 kamen die Entwickler mit dieser spontanen Idee zu mir", erzählt er. "Wir mussten mit Hochdruck Server beschaffen und einbauen – und Kubernetes darauf installieren." Das ging dann alles sehr zügig: "Wir haben im Team gearbeitet, alle Sysadmins haben gemeinsam angepackt und das im gewünschten Zeitrahmen hinbekommen." Schon kurz nach Weihnachten lief das System auf den neuen Servern.

Doch was ist Kubernetes? Es handelt sich um eine Open-Source-Plattform, die den Betrieb von Linux-Containern automatisiert. Dabei werden Gruppen von Hosts in Clustern zusammengefasst, die sich dann einfach und effizient verwalten lassen – weitgehend ohne manuelle Justierung. Kubernetes eignet sich besonders gut für alle Web-Anwendungen, die eine schnelle Skalierung benötigen.

Schnelle Reaktion

Für uns – als Musikhaus mit Europas größtem Versandlager – ist eine stabile Kubernetes-Distribution wichtig. Denn sie muss für die Produktion geeignet sein. Wir nutzen OpenShift, weil der Webshop auch bei vermehrten Suchanfragen schnell und reibungslos funktionieren muss. "Momentan ist Kubernetes bei der Mobile App von Thomann im Einsatz", berichtet Thomas. Dort suchen die KundInnen in Kategorien wie "E-Gitarre", "E-Bass" oder "Schlagzeug" nach Instrumenten. "Wenn die Mobile App träge ist, hinterlässt das bei den Nutzern keinen guten Eindruck", sagt er. "Das muss sehr schnell funktionieren." Selbst bei Lastspitzen wie an Weihnachten könne Kubernetes zügig Container nachskalieren. "Das wäre bei dem alten System – mit virtuellen und physikalischen Servern – nicht ohne Weiteres und bei weitem nicht so schnell möglich."

Thomas ist seit Anfang 2018 bei unserer Tochterfirma Bits & Beats. Davor war er Senior Systems Engineer bei einem Nürnberger Service-Provider, schon damals arbeitete er mit OpenShift. "Als ich bei Bits & Beats anfing, habe ich mir gleich ein paar ausgemusterte Server geschnappt – und gesagt: Lasst uns aus Spaß mit den alten Servern ein OpenShift-Cluster bauen", erzählt er. Den KollegInnen von der Systemadministration gab er dafür eine Kubernetes-Schulung. "Wir haben das Cluster mit OpenShift gebaut. So hat alles angefangen."

Thomas erklärt, wie er – Schritt für Schritt – ein Projekt auf Kubernetes migriert: "Ich schaue zunächst, auf welchen Servern das Projekt läuft. Dann gehe ich auf die Server und schaue mich um: Was ist das für ein Betriebssystem? Welche PHP-Version ist das? Und was laufen da für Komponenten?" Diese Komponenten müssen dann auf die neuen Server umgesetzt werden. Thomas erstellt ein Git Repository, mit dem sich die Versionen der System-Software zentral verwalten lassen. Dort packt er dann alles hinein, was für die spätere Bereitstellung der Software benötigt wird. Da sich die Konfiguration je nach Art der Anwendung stark ähnelt, kommt ein Template Git Repository zum Einsatz, aus dem man sich bedienen kann. "Die Applikation, die vorher auf dem Server lief, kann dann so ähnlich auch in Kubernetes laufen", sagt er. "Wenn die Migration fertig ist, wird der DNS-Eintrag umgebogen. Die URL zeigt dann auf das Kubernetes-Projekt – und nicht mehr auf den alten Server." Damit ist das Projekt live und von außen erreichbar.

Bestmögliche Stabilität als Ziel

Das Sysadmin-Team von Bits & Beats konnte schon mit dem Test-Cluster eine Menge Erfahrungen sammeln. Als dann kurz vor Weihnachten 2018 auch wir selbst – im Rahmen eines neuen Projekts – Docker-Container einsetzen wollten, waren alle gut vorbereitet. Die Arbeitsgruppe richtete zunächst physikalische Server in Nürnberg ein. Zudem mieteten wir Ressourcen für ein produktives Cluster in der Google Cloud in Frankfurt an – die virtuellen Maschinen lassen sich einfach per Knopfdruck starten. Für das produktive Cluster wählten wir die Zone Frankfurt 3 aus, die wiederum in die Verfügbarkeitszonen A, B und C unterteilt sind. In jede Verfügbarkeitszone platzierten wir je ein Master Server, ein Infra Server und eine Worker Node. Diese Verteilung soll bestmögliche Stabilität gewährleisten. "Rein theoretisch könnte bei Google eine komplette Verfügbarkeitszone – also ein Rechenzentrum – ausfallen", sagt Thomas. "Und trotzdem würde das Cluster weiterlaufen."

Die Verteilung auf physikalische Server (Nürnberg) und virtuelle Server (Google, Frankfurt) macht Sinn. "Alles, was stark an die Datenbanken von Thomann angebunden ist, läuft über die Nürnberger Server", sagt Thomas. "Die übrigen Projektseiten laufen in der Google Cloud." Auf den Nürnberger Servern kümmert sich Kubernetes um die Lastverteilung. Die Verteilung der Arbeitslast übernimmt ein sogenannter Scheduler. Bei einer Lastspitze – wenn also viele User gleichzeitig den Shop nutzen – kommt der Horizontal Pod Autoscaler – eine weitere Kubernetes-Komponente – zum Einsatz, und startet weitere Container.

Doch was genau sind eigentlich Container? Eine kompakte Beschreibung findet sich auf redhat.com. "Ein Linux-Container ist ein Satz aus einem oder mehreren Prozessen, die vom Rest des Systems isoliert sind." Alle Dateien, die zur Ausführung notwendig sind, werden über ein Image bereitgestellt. "Linux-Container sind von der Entwicklung über die Testphase bis hin zur Produktion stets portierbar und konsistent", heißt es auf redhat.com. "Sie sind deshalb viel schneller als Entwicklungs-Pipelines, bei denen herkömmliche Testumgebungen repliziert werden."

Diese Unkompliziertheit war Thomas zufolge einer der Hauptgründe, warum wir uns für Docker-Container und somit für Kubernetes entschieden haben: "Die nötigen Libraries und Dienste sind immer passend mit der Applikation verbundelt. Dadurch läuft das Ganze auch problemlos auf einem Notebook. Das kommt den Entwicklern zugute."

Vom Base Image bis zum Deployment

Thomas erklärt, wie er mit Containern arbeitet. "Die Container bauen aufeinander auf. Das heißt, man hat ein Base Image, zum Beispiel ein Alpine. Da kann man dann SSL-Zertifikate reinpacken, so dass dann alle späteren Applikationen die auch haben. Auf dieser Basis kann man dann zum Beispiel die PHP-Version 7.2 und 7.3 bauen. Und das wiederum nimmt dann die Applikation." Am Ende, beim CI /CD Run, werden jeweils eigene Docker-Images "vom Stapel gelassen". (Mehr zur Containerisierungstechnologie Docker gibt es in unserem nächsten Kubernetes-Blogpost.)

"Die gesamte Containerisierung und Bereitstellung der Applikation läuft automatisch ab", sagt Thomas. "Händisch wird nur das Debugging betrieben, also die Suche nach Fehlern. Die benötigten Kubernetes-Resourcen, die dem Cluster sagen, welchen Zustand wir haben möchten, kommen derweil aus einem Helm Chart." Das wiederum liegt im Git Repository. Als verteiltes Versionierungssystem erleichtert Git die Software-Entwicklung: mit ihm können Entwickler die eigenen Änderungen überwachen, rückgängig machen und anderen Entwicklern über Repositories zur Verfügung stellen. "Jeder hat im Normalfall seinen eigenen Git Fork, also eine Art Klon des Hauptprojekts", sagt Thomas. "Dadurch können alle sehr parallel arbeiten und über Pull Requests ihre Arbeit zusammenführen."

Bei einem neuen Projekt bekommen Entwickler den Unterordner eines bestehenden Git Repository oder ein neues Git Repository zugewiesen. "Da beginnen sie mit ihrem Code", erläutert Thomas. "Im Normalfall testen sie den Code zunächst lokal, auf ihrem Laptop. Wenn es dann in Richtung Produktion geht, wird er vom Continuous Delivery System in einen Container gebaut und schlussendlich ausgerollt." Unsere Firma nutzt dafür ein CI/CD-System namens Drone CI. "Der Drone-Server nimmt die Software, baut diese, lädt Libraries mit herunter, verpackt alles in das eigentliche Docker-Image und pusht es in eine Registry", erläutert Thomas. "Ganz am Ende kommt der Deployment-Step, das heißt, das Projekt wird in Kubernetes ausgerollt."

Verteilung auf mehrere Netzknoten

"In Produktion lassen wir die Container mehrfach laufen", sagt Thomas. "Kubernetes kümmert sich darum, dass die Container auch möglichst weit entfernt voneinander laufen. Wenn beispielsweise eine Applikation auf zwei Container skaliert ist, laufen diese beiden Container nicht auf EINER physikalischen Node, sondern immer auf verschiedenen." Beim Ausfall einer dieser Nodes funktioniert das Ganze also immer noch. Bei Wartungsarbeiten räumen die Sysadmins die Node übrigens leer: "Das nennt sich Draining. Sobald die Node leer ist, können wir sie beliebig verwenden."

Wie bereits erwähnt, läuft das Thomann-Kubernetes an zwei Orten: in Nürnberg und in Frankfurt. Die Unterschiede bei den Servern wirken sich in der Cloud auf die laufenden Kosten aus. "In der Google Cloud nutzen wir virtuelle Maschinen, für die man minutengenau zahlen muss", sagt Thomas. "Bei der Skalierung dieser VMs gehen wir ziemlich nah an die benötigte Ressourcengrenze heran." In Nürnberg hingegen hat Thomann starke physikalische Server stehen, "damit wir genügend Luft haben", wie Thomas es formuliert. Für Lastspitzen ist man also gewappnet.

Kubernetes selbst und alles drumherum wird natürlich ebenfalls ständig weiterentwickelt. "Ein neuer Trend ist serverless", berichtet Thomas und erklärt das Prinzip: "Anwendungen, die ich nur eine begrenzte Zeit benötige, kann ich perfekt auf einer Serverless-Plattform umsetzen. Da liegt die Anwendung dann bereit. Sobald ein Request eintrifft, agiert das System dynamisch, startet den Container, führt die Anwendung aus und stoppt den Container dann sofort wieder." Eine solche Serverless-Plattform lässt sich in Kubernetes beispielsweise mit Knative erzeugen.
Außerdem gibt es mittlerweile eine Menge unterschiedlicher Operatoren, die zum Beispiel in der Lage sind, vollautomatisch ein XtraDB-Cluster in Kubernetes bereitzustellen. Solch ein Operator ist ein Programm, das ebenfalls in Kubernetes läuft. Es kennt sich mit den Anwendungen sehr gut aus, konfiguriert diese vollautomatisch und erweitert so die Fähigkeiten des Clusters. "Dem Ganzen sind praktisch keine Grenzen gesetzt", freut sich Thomas.

Fazit

Als größte Stärke von Kubernetes sieht Thomas die Flexibilität. Zum Beispiel die Möglichkeit, das System auch lokal auf dem Notebook laufen zu lassen – oder im Notfall in eine andere Public Cloud zu deployen. "Weitere Vorteile sind die bessere Skalierbarkeit und die schlankeren Server", sagt Thomas. "Die Versionsverwaltung per Git Repository macht das Ganze außerdem sehr transparent."

Bei Thomann sei die Migration von der alten Server-Struktur nach Kubernetes übrigens noch längst nicht abgeschlossen, sagt Thomas: "Das ist alles noch Work in Progress." Und für das komplette Thomann-Team eine spannende Herausforderung und Chance.

thomann.io v2

thomann.io v2

Frisch aus dem Kühlregal: Hier ist das neue Frontend!
Thomann Dev Camp 2k19

Thomann Dev Camp 2k19

Dieses Jahr meldet sich das Dev Camp unter dem Motto “gemeinsam abgehoben sein”
Das Thomann Dev Camp

Das Thomann Dev Camp

Wir wissen, was das Dev Team letzten Sommer gemacht hat. Ein Einblick.
Das Slack-Battle

Das Slack-Battle

Der Umzug des Thomann-Teams von Skype auf Slack hat einige Neuerungen mit sich gebracht. Für alle,...
Praktikum bei Thomann in Berlin 2.0 – Web-Tests

Praktikum bei Thomann in Berlin 2.0 – Web-Tests

Das umfangreiche Testing-Framework von m.thomann.de ermöglicht es, Änderungen an der Website...
Vektorgrafiken im modernen Web

Vektorgrafiken im modernen Web

Im Zuge unserer Erneuerungen für die mobile Thomann-Seite räumen wir vieles auf, gehen aber auch — für...