Secrets Not Included: Warum Kubernetes-Projekte scheitern – obwohl Kubernetes nicht schuld ist

Willkommen zu Secret. Secrets not included, verdammte Axt. Diese Woche wieder mit dem Ole, der nicht sprechen kann und dem Daniel, der sich einen abgrenzt darüber, dass er die Einleitung nie spricht.

Ich muss mich immer noch davon drücken, das zu sagen. Hm.

Es wird aber eine wunderbare Folge Secrets not included und wir wollten ein bisschen mit euch über Kubernetes-Projekte sprechen, die scheitern und obwohl es gar nicht an Kubernetes liegt. Ich finde, ein bisschen provokantes Thema, Daniel. Nach unserer letzten Folge, die chaotisch war, zu Security-Zertifizierungen, jetzt sagen wir Kubernetes ist voll super.

Ich als Fanboy, AWS-Fanboy würde das nie sagen. Ja, ECS, ja. Ach nee, EKS gibt es auch, genau.

Ach so, okay.

Also für mich ist ECS das bessere Kubernetes. Wir wollten provokanter sein.

Du würdest sagen, wie heißt es bei AWS nochmal? EKS-Zertifizierungen? Der ECS ist doch die Container-Plattform, die komplett selbstverwaltend ist und wo du dich auch nicht um gar nichts kümmerst, außer dass du da einen Container hinschmeißt. Oha! Und EKS ist ja das Managed Kubernetes von AWS. Jetzt können wir noch AKS nennen, das ist das managte Kubernetes in Azure. Und GKE ist es, glaube ich, bei Google Cloud, wenn ich mich richtig erinnere, als Managed-Produkt.

Ja, gut, habe ich noch nicht gehabt, aber ja, kann sein.

Ja, ich habe mit allen schon gespielt.

Ich muss ja noch Cloudfleet in den Raum werfen.

Plus OpenShift. So.

Hast du damit mal zu tun gehabt?

Nee, tut mir leid. Mit den Förmchen habe ich noch nicht gespielt. Was ist das? Ich kenne es gar nicht, tatsächlich, Daniel.

Also es ist halb gemanagt, Kubernetes, du hast also Managed Master, Du kannst den so konfigurieren mit Credentials, mit allem drum und dran, dass der automatisch bei Hetzner oder anderen Dienstleistern VPS-Server startet und ihn in den Cluster mit einbindet. automatisch. Das habe ich letztens in einem Setup, das ist sehr sexy. Für mich als AWS-Fanboy mag ich doch ein bisschen Kubernetes.

Okay.

Damit auch wirklich alle triggern jetzt.

Ich meine, wenn du ECS nutzt, was liegt da drunter?

Ja, aber ich muss mich nicht anziehen.

Also ich weiß es tatsächlich gar nicht, ob es ein Kubernetes ist, was drunter gebaut ist oder ob es was Eigenes ist.

Angeblich die kürzeste Folge ever.

Ähm... Okay. Immerhin hast du nicht gesagt, dass du Azure-Fanboy bist, dann hätten wir nämlich die Folge beenden müssen. Ja, dann wäre ich weg gewesen. Mit AWS-Fanboy kann ich leben, ne? Du weißt ja selber. Wie hieß es? Cloud-Tier?

Cloud-Fleet, also Sponsoring.

Ja, Cloud-Fleet. So, also wie kann ich mir das vorstellen? Ich habe da eine Plattform, ich logge mich ein und sage, hier, mach mal bei Hetzner mir die VPS hin und dann startet ihr das?

Also du loggst dich da ein, erstellst, sagen wir mal, in der Web-Oberfläche deinen ersten Cluster und hast dann alles, was du kennst, dein Managed.

Ja, ja, gut.

Also das ist halt einfach eine Masternode aus deinem Kubernetes. Nichts muss sich nur nicht drum kümmern, die kümmern sich darum, dass das funktioniert. Dann gibt es halt die Möglichkeit, da, sagen wir mal, Token von Hetzner oder anderen allen Cloud-Diensten, sagen wir mal, zu hinterlegen, sodass das Ding auf deinen, also das Cloud-Fleet Zugriff auf deinen Account hat und dann kann Cloud-Fleet, also das kannst du bei Hetzner automatisch auch über die CLI oder wie bei AWS auch, Einfach dann Nodes spawnen, die automatisch in einem Netzwerk laufen, also nicht mehr öffentlich verfügbar sind, sondern auch abgeschlossen sind nach außen hin.

Ja, gut.

Die laufen dann im Netzwerk und werden automatisch gestartet. Wenn du immer mehr Pots startest, die Ressourcen reservieren, die aber nicht vorhanden sind, weil du sagst, ich brauche zwei CPU dafür, dann geht der einfach hin und startet den nächsten, der auch darauf passt. Hast du dann irgendwas Großes und dann auch passend von der Größe her skaliert er. wenn du deployst. Also mich macht man damit glücklich als AWS.

Ja. Das klingt jetzt so nach dem, was ich eigentlich erwarten würde. Ist auch Ja, ja, und ich sage so, okay, das ist das bare Minimum, was ich beim Managed-Koog-Mannitis irgendwie erwarte, dass es Managed ist. Aber wo liegt, also die Masternode, Controlplane, sowas liegt dann halt nicht bei Hetzner oder deinem Anbieter oder... Okay.

Genau, das ist Cloudfleet. Die haben da die Hoheit drüber, das ist das, was die anbieten. Die haben einen Free Account mit einer Uptime, glaube ich, von 95 Prozent und dann natürlich auch Paid mit, also wenn du es professionell oder produktiv nutzen willst, hast du natürlich ein Paid mit 99,99 oder so waren, also genug. Und das ist dann halt managed.

Okay, aber an deinem Kubernetes scheitern ja meistens die Projekte auch nicht. Also Managed-Produkte ist jetzt ja nichts Neues. Ich finde, das ist ein cooles Produkt.

Mhm.

Ich würde es noch mehr feiern, wenn ich ehrlich bin, wenn die Masternode dann quasi auch bei dem Anbieter liegt oder bei einem der Anbieter, die ich auswähle, wenn ich ehrlich bin. ja, da kommt wieder so dieses Souveränitätsding bei mir durch, wo ich sage, okay, ich bin AWS-Fanboy für viele Dinge und, aber wenn ich es

Das ist DSGVO-konform. Die liegen, also die hosten in Deutschland und ich meine, irgendwo gelesen zu haben, dass die auch unter der Haube auch bei Hetzner und anderen hosten in Deutschland. Also DSGVO-konform.

Spannend. Das ist ja gerade der Punkt halt mit der Souveränität. Wenn ich jetzt sage, okay, mein Rechenzentrum ist in Frankfurt, aber es wird halt vom US-Unternehmen betrieben, dann bin ich halt immer noch nicht richtig souverän. Dann liegt es halt nur auf dem Server, der in Deutschland steht.

Das ist eine GmbH.

Das hilft mir aber nicht. Hm?

Das ist eine deutsche GmbH, glaube ich, sogar dahinter.

Ja, das heißt ja nicht, dass du nicht trotzdem unter den Cloud Act fällst. Das ist ja das Absurde.

Die haben ein Zertifikat, das hatten wir in der letzten Folge, dem glaube ich. Nee, Nee, also die sind DSGVO-konform genug für mich, dass ich mich dazu entschieden habe.

Zertifikat. Aber es ist mir auch DSGVO-Kon... Also, um das mal zu sagen, um jetzt auch den Hater auf mich zu ziehen.

Als AWS-Fillen-Bäumer auch was anderes auszuprobieren.

Ähm... Für viele unserer Kunden und auch für mich ist AWS oder Azure, das sind eher die Kunden, also es ist das DSG. VO-konform genug. Ja, da müssen wir uns gar nichts vormachen. Es gibt diese Souveränitätsbeschränkung, jetzt reichen wir wieder vom Thema ab. Anyway, es gibt diese Souveränitätsdiskussion, Wenn wir aber in die reale Wirtschaft reinschauen, müssen wir ehrlicherweise sagen, dass US-Hyperscaler bei vielen der Standard sind aus guten Gründen und die man auch nicht mal eben abgelöst bekommt.

Ich brauche so ein AWS-Fähnchen. Dafür würde ich sogar tanzen.

Ja, und das scheitert halt nicht am Produkt des Managed Kubernetes.

Nee, aber wir wollten eigentlich über Kubernetes reden.

Ja, vielleicht können wir aber erstens auch sponsern. Ich würde auch Credits nehmen. Oh, nee, das nicht. Also tanzen ist jetzt eine völlig andere Kategorie. Also, nee. Sorry, not sorry. Da bin ich. Ja, genau. Aber eigentlich scheitert der Kubernetes bei vielen Stellen schon, wo man ehrlich sagen muss, eigentlich brauchst du gar kein Kubernetes. Oder du hast gar nicht die Prozesse dafür. Oder gar nicht die passende Teamgröße auch um managed oder self-hosted das Ganze zu machen.

Self-hosted, also Respekt, wer das alleine die ganze Zeit macht, da geht viel Zeit für drauf. Also es ist nicht unmöglich, aber das kostet Zeit, also so ein Cluster am Laufen zu halten, zu aktualisieren, alle Notes und so.

Hier ist es halt Arbeit, kann man automatisieren. Also, wir haben tatsächlich Tests dafür laufen, das automatisiert selber zu betreiben. So, mehr möchte dazu nicht sagen.

Aha, gibt es da Betriebsgeheimnisse?

Aha. Na, es gibt einfach... was heißt Betriebsgeheimnis, ich verrate gerne alle Geheimnisse, ich habe da gar keinen Stress mit, aber das ist natürlich in der Qualität, in der ich das haben möchte, bekomme ich es noch nicht automatisiert.

Hm.

Das ist jetzt aber vielleicht ein ohne Problem. Ich habe so eine Allergie dagegen, nachts aufzustehen, wenn so ein Ding abstürzt. Das nimmt dir natürlich so ein Managed Service komplett ab, weil da steht jemand anderes für dich auf.

Ja, aber genau das ist das Problem.

Voll cool. außer du hast natürlich Probleme, dass du das allgemein nicht hinbekommst mit den Containern oder so oder mit GitOps oder deinen Prozessen, CI, CD's, Secret-Verwaltung. Ja.

Also so gerne, wie ich auch Kubernetes mache, zum Beispiel mein Problem ist, ich bin, oder ich lasse mich gerne, oder ich verzettel mich gerne. Du kannst ja so viel damit machen und eigentlich alles damit machen. Und das ist mein großes Problem.

Klasse, das ist Overengineering, ne? Ja, perfekt.

Ja klar, natürlich. Du kannst alles und tausend Sachen machen und Du kannst dich da komplett verlieren in dem Setup. Da musst du schon, wenn du alleine bist oder mit ein, zwei Entwicklern nur unterwegs bist und du hast Managed Kubernetes, wo du nicht nachts aufstehen musst, musst du dich trotzdem zusammenreißen, dass du das nicht übertreibst, dass du nicht zu viele Sachen da reinklatscht, dass du guckst, dass du den State da raushältst und du kannst so viele Sachen machen. Du liest immer ganz viele Sachen und dann willst du hier noch was ausprobieren, da noch was ausprobieren.

Mit State der Großhälzer ist das natürlich ein total interessanter Punkt. Was machst du mit der Datenbank?

Ja, die ist managed woanders. Das ist ja fies.

Wunderbar, ist auch meine Standardantwort. Ich kenne aber Menschen, die im Kubernetes ihre Datenbank betreiben. Und leider muss ich auch zugestehen, wenn man Typo3 in Kubernetes als Typo3-Cluster betreibt, also im Kubernetes-Cluster, ein geklasterter Typo3, hat man auch das Problem, dass Typo3 zum Teil stateful ist oder halt zumindest nervige Dateien geshared haben muss. Du kannst viel in Walkie, Redis oder so auslagern, alles voll geschenkt, aber du hast halt so einen nervigen File Cache, der auch noch leider total ätzend ist in hinsichtlich der Skalierbarkeit.

Mhm.

Also du kannst jetzt nicht sagen, na ja, scheiß drauf, auf jedem Note wird das halt geschrieben. Das Verzeichnen ist halt schreibbar, dann ist das halt nicht 100% Read Only. Macht er aber nicht, weil er dann feststellt, ah, die Datei fehlt, die ich erwarten würde, schreibt die zwar neu, vergibt aber einen neuen Hash und dann hast du halt für jede Note, ständig wird der Cache neu geschrieben. Total Banane.

Ja.

So, aber das sind jetzt ja echte Probleme, die aus der Applikationsebene kommen. Dafür gibt es auch in Kubernetes Lösungen. Man kann auch entsprechend Sachen sharen oder über File-System Lösungen machen, alles nicht sexy. Funktioniert aber sehr erfolgreich. Ich glaube, wir sind mit die Ersten gewesen, die Typo3-Cluster in Kubernetes betrieben haben, wo es Millionen Zugriffe im Monat oder auch zum Teil bei guten Werbekampagnen am Tag gab. Das war nicht so das Thema.

Mm. Mm.

Aber da lernt man halt auch, wenn man sowas mal gemacht hat, Wo brauchst du denn wirklich Kubernetes und wo kannst du eigentlich noch den ganzen Shit mit Docker Swarm abarbeiten, ohne dass du Kubernetes mit allem Overhead brauchst? Weil wir hatten nämlich am Anfang einfach einen Docker Swarm da laufen, bis der dann aufgegeben hat und man nicht mehr deployen sollte, weil das Ops Team Angst hatte, dass alles zusammenbricht. Und wir dann innerhalb von vier Wochen auf Kubernetes migrieren mussten.

Oh, ihr habt echt mit Anlauf alle Probleme mitgenommen.

wo es dann auch interessante Architekturprobleme gab.

Mhm.

Ja, natürlich. Also wir hatten natürlich dann so etwas wie die Datenbank fürs CMS, das ist nur die Startseite und Content-Seiten und so und dann hing da noch ein Shop dran und so. Also komplex. Wir hatten dann halt so Probleme wie, dass jemand auf die Idee gekommen ist, wir benutzen Datenbanken mit Public IPs, also sprich unser Traffic läuft aus dem Cluster raus, einmal rum zur Datenbank über das öffentliche Internet.

Das ist cool. Das guckt mir nichts an.

Ist cool. Ist halt total scheiße, weil halt so der rausgehende Traffic irgendwie limitiert ist. Und auch irgendwie die Datenbank dann zeitweise nicht erreichbar war und halt voll abgeschmiert ist das ganze System, weil halt die Datenbank nicht erreichbar war. Die Datenbank hat aber gesagt, nö, ist alles in Ordnung. Also eigentlich eitel ich hier nur rum. Ja, weil das nicht das Problem war, logischerweise. Das war halt das Architekturproblem, sobald die Datenbank intern verfügbar war über das private IP-Netz, alles total easy. Aber natürlich gibt es auch kleine und feine Unterschiede zwischen Docker Swarm und Kubernetes, die dir dann bei so Hau-Ruck-Aktionen voll auf die Füße fallen.

Was mehr? Also erzähl mehr, ich bin neugierig. Was ist noch passiert?

Was möchtest du mehr wissen?

Alles. Also generell, also was wir gerade hatten, war State. Also wenn du es einfach haben willst, hältst du den State aus Kubernetes raus. Egal ob es Redis, also Datenbanken ist, Redis vielleicht noch, da ist es egal, wenn der gekehlt wird.

Ja, Redis kannst du doch gut, also Redis, wenn du das rein fürs Caching benutzt, ist das ja nicht stateful. So, also kein Thema, also kannst du drinnen haben. Datenbanken geht auch. Das haben wir woanders gemacht, in einem anderen Projekt, ein bisschen ein kleineres Setup, wo das dann auch noch OpenShift hatte und so Sachen, also noch mehr Herausforderungen, was Sicherheitsarchitektur angeht. Und, ähm, Du kannst halt entsprechende Volume für Cache-Dateien auch sharen, das geht. Dann hast du eventuell Bandbreitenprobleme, Da musst du halt mit Hardware, mit Power arbeiten, damit das halt kein Problem gibt.

Nope.

Da gibt es keine elegante Lösung für. Du kannst natürlich dir auch irgendwelche Sync-Prozesse bauen, die dann diese Cache-Dateien hin und her synken. Da gibt es auch, ich glaube, Flyway oder ähnliches als File-System. Nimmt dir auch Sachen ab, das kannst du auch machen. Oder du sagst halt einfach, ja komm, diese Cache-Dateien, das ist jetzt auch nicht so viel Stuff. Wir haben eh viel RAM. Da war RAM noch billiger als heute. Ja, genau, wir schmeißen diese gecacheden, das mounten wir quasi in den RAM und sind glücklich damit. Dann ist es schnell, dann haben wir kein Problem, fuck it. Also scheiß auf, was da passiert. Im Hintergrund ist es schnell, es zieht die Zeit nicht runter und natürlich kannst du und solltest du auch immer so Sachen machen wie vernünftiges Caching als Full-Page-Cache vor das System setzen.

Also redest von dem Warnisch zum Beispiel.

Ja. Bein schwer auch das Produkt meiner Wahl. Es gibt aber Alternativen, die nicht so schön funktionieren oder die auch schön funktionieren. Also mittlerweile in kleinen Setups bin ich auch ein sehr großer Freund von Caddy fürs Caching geworden.

Mit Caddy? Okay.

Ja, das macht das nämlich auch hervorragend.

Habe ich noch nicht im Einsatz. Okay. Finde ich interessant.

Ja, also wenn du jetzt halt Ja, genau.

Also Reverse Proxy davor, oder?

So, damit lädtest du natürlich schön, dass wenn dein dahinterliegendes System, egal ob Shop oder CMS, ist ja völlig Latte, aber wenn das halt mal gerade neu lädt, kannst du halt sehr viele Seiten und Sachen einfach gern für den Moment ausliefern.

Oder...

Ich glaube, beim Shop ist tatsächlich panisch einfach geiler in jedem Fall. Wenn ich so drüber nachdenke, weil du flexibler bist, das hat mehr Möglichkeiten für so reine Content-Sachen, kannst du aber das halt wunderbar auch mit der Kette abbilden.

Ja, ja.

oder NGX geht auch als Reverse-Proxy, ne? Den mag ich jetzt an der Stelle nicht so hundertprozentig, weil der immer irgendwie einfach keine richtig geile Erfahrung mitgemacht hat, aber hat sich, aber ich weiß, es geht, wir haben das auch gemacht, das ist halt, manchmal nehme ich halt Dinge, weil sie sich für mich besser anfühlen, ne? So, und weil die Ergebnisse für sich sprechen, ja? Wenn die Geschwindigkeit in der Auslieferung gleich ist, was soll ich mir Gedanken darüber machen?

Wenn du schnell bist, die letzten 5% optimieren, kannst du viel Lebenszeit mit verschwenden.

Ja, so.

Das Das ist in Ordnung.

Ja, was will ich, also Time to First Byte bei 8 Millisekunden, ne, damit. Wenn es schlecht ist, 15 Millisekunden. Also, sorry, da gibt es Systeme, die ich kenne, die haben mehr Probleme. Ja, so. Also, ähm,

Und wenn, dann hat man andere bei den Zeiten. Ja, aber wir waren ja dabei, das Date, also sagen wir mal, entweder das Date rauszuhalten oder halt, wenn das, vernünftig umzusetzen.

Das sind genau.

Und also ich bin auch nicht, dass ich sage, so ne, State überhaupt nicht da rein. Das ist für mich einfach so die nächste Stufe, weil dann musst du schon wirklich Ahnung haben von Datenbank, dann fängst du an vielleicht sogar mit Master Slaves und Replikation und allem. Dann bist du schon wieder auf der nächsten Stufe, wo du wieder mehr Know-how einfach von dem ganzen Thema haben musst und wieder so eine Baustelle mehr hast, gerade wenn du alleine bist.

Genau, dann hast du auch das Thema HA-Proxy wahrscheinlich und solche Sachen noch davor und auch beim Amaradis oder Wall-Key halt das Ganze geklustert zu machen, da gibt es ja auch zwei Varianten für mit Sentinel oder als Cluster. Und ja, dann musst du tiefere Ahnung haben. Aber genau das ist halt die Herausforderung, in die viele Teams dann ja halt reinlaufen einfach, wenn sie sagen, ah, wir gehen jetzt auf Kubernetes und wir wollen jetzt mit Clustern arbeiten, dass du halt sehr viel, sehr tiefes Wissen brauchst.

Extrem tief. Also es war wie...

Und zum Teil gehen die Probleme dann auch runter auf die fucking CPU-Architektur.

Mhm.

wir haben auch einen Fehler gehabt, ich bekomme ihn gerade nicht mehr aus dem Kopf so ganz zusammen, aber wo wir dann halt am Tagesende festgestellt haben, weil das Problem auch nirgendwo so richtig reproduzierbar war und nur ein Produktivsystem aufgetreten ist. Total ätzend. Was wir dabei gelernt haben ist aber, wir hatten dann Staging und Testsystem, also sogar noch zwei Systeme davor, dass im Produktivsystem tatsächlich in den Nodes eine andere CPU lief, ein anderer CPU-Typ. Und da es irgendwelche Probleme gab, ich bekomme es leider nicht mehr ganz zusammen, aber es war crazy shit. Wir haben das auch gefixt bekommen und das ist gar kein Thema, wenn man weiß, wo es herkommt, dann kann man immer...

Hat uns nur fünf Personentage gekostet, zwei Entwickler, Rande vom Burnout, aber wir haben es geschafft.

Es war mehr.

Ja, aber genau das ist ja das.

Aber also, weil ja auch Reproduzierbarkeit war halt wirklich scheiße. Ja, wenn du nur auf dem Produktivsystem das reproduzieren kannst und dann halt erstmal tief reingraben musst, noch mit anderen Teams sprechen musst, um dann rauszufinden, ah, da ist dann halt doch so ein Mikro-Unterschied irgendwo in diesem ganzen Shit drin.

Wenn der sich dann auch noch auswirkt, außer dann

Genau, so. Das ist aber auch wieder kein Kubernetes-Problem. Das sind natürlich Architekturentscheidungen, die da vorgetroffen werden, wo man sagt, ja, okay, irgendwie das Staging-System, wir sparen jetzt doch mal eine Mark 50 in der Stunde.

Aber solche Sachen hast du immer. Ja. Ja.

So, und es ist ja auch verrückt, also du musst ja auch erst mal auf diese Traffic-Größen kommen, dass du solche Probleme hast, mit denen du dich beschäftigen musst. Die meisten, und das ist halt das Krasse, setzen Kubernetes ein, wo sie es einfach nicht brauchen. Die bauen für die eine Million Besucher, die mal eben kurz nach der Fernsehwerbung kommen. Sie haben aber fünf. So, wir haben an vielen Stellen, muss man halt sagen, Kubernetes ist total nett, aber für Kubernetes brauchst du viel Wissen, viel Erfahrung, tiefes Wissen und gute Prozesse. davor, also vor diesem ganzen Ding mit ICD, mit Secrets, mit GitOps, mit Security Policies, im Plattform Engineering und hast eine riesige Komplexität da am Tagesende stehen und musst die ja bedient bekommen mit Leuten und mit Wissen. Deswegen sage ich auch, ey, wenn wir das irgendwie hier automatisiert machen mit dem Kubernetes, dann muss das aber auch echt gut laufen. Deswegen machen wir auch erstmal Tests, deswegen mit Raspberry Pis erstmal so ein Cluster gebaut und mal schauen, wie zuverlässig bekommen wir das Ding hin, bevor wir irgendwo anders das hinschmeißen. Das Wissen ist gar nicht so das Problem. Man muss sich halt bewusst sein, das Ding ist komplex.

Ich finde das auch zum Beispiel, also genau, da wollte ich gerade sagen, also wir reden jetzt so ein bisschen von den Unmanaged-Sachen, beziehungsweise was ich auch immer wieder mal, also so groß wie du hatte ich es noch nie im Einsatz, aber was ich bis jetzt immer hatte, ist so, dann betreibst du es eine Zeit lang und die Config ändert sich.

Egal ob managed oder unmanaged. Ja, weil, also

Du musst ja alleine schon, wenn du alleine bist, immer wieder hinterherarbeiten, sagen, guck mal jetzt,

Mhm.

willst irgendwie Config Appline oder mit einem Helm-Chart arbeitest du oder so und dann kommt eine Fehlermeldung, ach guck mal, dieser Parameter passt nicht mehr. Dann googelst du, ah, guck mal, Version hat sich geändert, das muss ich jetzt alles umbauen. Okay, dann fängst du an, Kies hin und her zu schubsen, während das System gerade aber am Abrauchen ist, weil du bist ja nur darauf aufmerksam geworden, weil irgendein Alerting gerade angegangen ist.

Naja, gut, du brauchst immer zwei Cluster, ne? Also du darfst nicht nur mit einem Cluster arbeiten, du brauchst genauso einen Testcluster, wie sonst du ein Testsystem brauchst.

Ja, aber das Problem ist ja, du baust das einmal, alles schick. Also das einmal aufbauen und aufsetzen, da bist du recht schnell. Gerade mit KI hast du ja super schnell Sachen generiert. Und dann steht ein Cluster da und läuft. Aber du musst ja regelmäßig Zeit reinbuttern, sag ich mal, um Config-Up aktuell zu halten, wenn sich Sachen ändern. Da war doch jetzt auch das, hier was rausfliegt hier, der Nginx-Kanal.

Ja, der NGX ist ja schon lange raus.

Oder ist schon lange raus, so geil bin ich.

Als Ingress, ja, so, also NGX Ingress ist, glaube ich, Anfang des Jahres rausgeflogen, wenn ich es richtig im Kopf habe von der Timeline.

Ja, vollkommen. Ja.

Also, es war ja auch angekündigt. Also, das ist jetzt nicht so die richtige Überraschung. Das aber es ist halt eine wirkliche Disziplin, wo du jeden Tag dran arbeiten musst, ja, das ist halt nicht hinstellen und glücklich sein, auch bei Managed Kubernetes nicht, aber auch diese ganzen Sachen, die Probleme, die ich jetzt derzeit habe, ne, das waren auch zum Teil Managed Kubernetes, ja, also, das ist gar nicht mal so, dass es jetzt ein Unmanaged Service wäre, der OpenShift war Unmanaged, aber da waren auch ganz andere Themen noch, genau, so, also, das, das ist halt so dieser Punkt, ähm,

Bleiben noch genug Probleme für dich übrig, auch wenn der managet ist. Was ist denn die Ursache? Ja.

Ursache. Immer Menschen. Aber schau mal, es ist doch so, entweder du hast ein Team, das einfach nicht das notwendige Wissen hat. Das kannst du relativ gut lösen, indem mehr Wissen aufgebaut wird oder du andere Leute dazu holst oder, oder, oder. Deine Prozesse müssen sauber sein, deine Applikationen müssen das auch ganz halt unterstützen. Du brauchst GitOps, du brauchst Standards, also echte sichere Standards, du brauchst Security Policies, du brauchst echtes Plattform Engineering. Was habe ich denn vergessen? Also das Einführen der erste Tag in Kubernetes ist nicht das Problem.

Ja, und das ist glaube ich auch die Falle. Du bist sehr schnell da, hast schnell was aufgesetzt, siehst was Schönes, skalieren Sachen, Lämmchen blinken gefühlt und alles ist hübsch.

Ja, skalieren, nächstes Thema, horizontal oder vertikal skalieren oder beides gleichzeitig.

Ja. Ja.

So, ja, und vertikal skalieren macht ganz andere Probleme als horizontal skalieren, weil horizontal horizontal ist halt einfach mehr Ressourcen, wenn ich es gerade richtig im Kopf habe. Vertikal heißt, wir bauen immer weiter daneben. Daneben bauen kann aber halt zum Beispiel deine TCP-Connection-Budgets aufbrauchen und solche Sachen.

Hm. Hm.

aufbauen. Wenn jetzt deine Datenbank halt nicht hochskaliert, während deine Applikation hochskaliert, hast du vielleicht nachher einfach keine freien Verbindungen mehr zur Datenbank.

Aber du hast Glück, Container, die warten darauf. Oh ja.

Ja, und dann hast du Round Robin aktiviert als Verteilungstaktik und dann landet halt auf einmal die Hälfte des Traffics auf Nodes, die gar nicht ready sind, weil du vergessen hast, da eine vernünftige Readiness-Probe und Liveness-Probe reinzubauen, weil du halt vorher zum Beispiel auf normalen Docker-Setups oder Docker-Compose, Docker-Swarm, etc., was dann nie sauber gearbeitet hast und das einfach nicht eingebaut hast.

Kennst du auch von einem Freund die Geschichte, ne? Ja. Ja. Ja.

Vielleicht. Natürlich. Also wir haben solche Fehler niemals gemacht. Wir haben natürlich perfekt angefangen und immer das perfekt implementiert gehabt und sind nie in solche Themen gegangen. Das sind ja nur Geschichten, die ich mal gehört habe, in dunklen Ecken des Internets. Ja, das ist kein Lernen durch Schmerzen, weil... Ja, so. Also, Daniel, du weißt, ich mache niemals Fehler.

Ja, ich auch nicht. Doch, selbst da im Traum. Ja.

während ich schlafe. Was? Du kennst meine Träume doch gar nicht. Also ich träume nachts nicht von Kubernetes-Clustern, das kann ich dir verraten. Zumindest sofern ich mich daran erinnere nicht. Träumst du von Kubernetes-Clustern?

Also mich haben schon mal ein paar Sachen echt in den Schlaf verfolgt. Genau solche Sachen, wo du so davor sitzt und sagst, boah, ich verstehe nicht, warum es nicht funktioniert. Ich kriege es nicht reproduziert und es tritt die ganze Zeit auf und du kommst nicht hinterher. Und das ist einfach so Sachen, habe ich so ein paar Mal mitgenommen. Also unfreiwillig, hat auch nicht Spaß gemacht, das waren keine schönen Träume.

Ich sage mal ein

Aber das sind so die Momente und das ist ja auch das, wo du sagst, also wo ich sage, ich habe damit angefangen, habe schnell Erfolge gehabt, habe dann einen eigenen Cluster da betrieben, habe mich voll toll gefunden und dann kommen so mit der Zeit die Probleme. Du musst dir Konfig hinterher, Flicken und dann hast du da noch ein bisschen Zeit verschwendet, wo du eigentlich was anderes bauen wolltest. Dann hast du Probleme, genauso wie du sagst, was mir auch nie passiert ist, diese Readiness-Probes und solche Sachen, dass das einfach nicht funktioniert hat, Sachen nicht ausgerollt sind oder nicht ausgerollt wurden. Dann stehst du da und sagst, mein Gott, ich habe das doch deployed. Ach nee, doch nicht. ich meine, das mit der CPU, so tief bin ich nie drin gewesen. Ich weiß nicht, ob zum Glück oder leider. Aber genauso wie, dann hast du, also genau das gleiche, den State im Kubernetes. Dann versuchst du irgendwann mal eine Datenbank da zu replicieren und dann bist du mit Master Slaves unterwegs, dann hast du da irgendwie eine Volumes, die du mountest, querlustig und Sachen abschießt und die kommen nicht zurück. Du hast, also es war alles ein Testsystem, aber dann Recoveren sich die Volumes nicht, die Daten sind weg, du hast kein Backup, super, wegschmeißen, von vorne anfangen. Ja.

ist? Wenn du ja eigentlich mit Pipelines deployst, aber auch lokal auf den Kontext Zugriff hast, aus Versehen deployst in den Produktiv-Cluster und alles nicht mehr funktioniert und kein Mensch weiß warum, dann sind deine Volumes nämlich auch magisch nicht mehr verknüpft zum Beispiel.

Scheiße.

Ja, dann ist quasi, du siehst nicht warum, aber auf einmal ist dieser Cluster quasi nicht mehr funktionell. Also Kinders, wichtig ist Learning. Ihr solltet niemals, nie nicht, wirklich niemals von lokal in den Kontext für eure Cluster kommen, die da irgendwo hinstehen und Container da hinschieben können.

Ich bin gerade überlegen, also dein Freund, dem das passiert ist.

Das ist tatsächlich nicht mir persönlich passiert.

Also für den Freund aus Minecraft.

Ich bin die... Aber ich habe es miterlebt.

Also der eine Freund in Minecraft, der macht echt viel, also wenn ich so überlege. Und der muss auch einiges wissen. Mhm.

Also Unfälle passieren halt. Das ist ja nicht, dass jemand eine böse Absicht hat und sagt, oh ja, ich bin jetzt in dem Kontext und ich deploy jetzt mal hier eben, weil ich das testen muss, diese Container. Das sollte in einen ganz anderen Kontext gehen. Das sollte in den lokalen Kontext gehen eigentlich. So, nicht aufgepasst. Schade Marmelade. So, und dann funktionieren natürlich Dinge auf einmal nicht und dann hast du halt dieses Thema mit, da ist auf einmal der Cluster weg. Oder vielmehr die Nodes funktionieren nicht mehr, weil da eine Container-Version ist, die keine Volume, oder die Nodes haben keine Volume-Verknüpfung mehr, der Pod und so weiter. Alles ist auf einmal komisch. So, das, das, das, Ja, so, dann hast du auch ein Ops-Team oder ein Plattform-Team da auf einmal sitzen, das halt auch sagt, scheiße, wir wissen jetzt gar nicht, was geht denn hier ab.

Mhm.

So. Und dann hast du natürlich auf einmal echt alle Alarmglocken an. Deswegen sage ich, schaut mal. wer denn da eigentlich so wohin schreiben darf und minimiert mal, dass irgendjemand in diese Produktiv- und Staging-Cluster überhaupt reinschreiben kann von außen, außer eure CICD, also außer die GitOps-Prozesse. Ja, weil, ja.

Mhm. Ja, ist halt sehr verführerisch. Also zumindest habe ich das so am Anfang, sage ich mal, von der Containerisierung für mich gemerkt. Dieser Übergang war extrem schwer. Man war es gewohnt per SSH aufs Produktivsystem, aufs Testsystem. Du konntest da in die Logs gucken. Du konntest Commands ausführen, die dann irgendwie eine Migration angestoßen haben. Du konntest Cronejobs sehen. Und auf einmal, also bei AWS hat es sogar echt wehgetan am Anfang, dieses, ich deploye etwas und ich komme da irgendwie nicht mehr dran. Also per default erstmal nicht.

naja, du kommst ja schon dran, ne? Also wenn man ehrlich ist, es gibt Wege,

Du musst rückwärts wieder Wege machen, also du musst Wege finden, Und das fand ich auch ganz gut, dass das erstmal so war, dass ich nicht drangekommen bin und dass es schmerzhaft war. Dass du sagen musst, okay, wie komme ich jetzt an die Logs? Wo sind die Logs? Wie kann ich jetzt Commands ausführen und, und, und. Und bei Kubernetes ist es ja eigentlich auch so, dass das Setup so sein sollte, dass du da nicht drankommst. Und ich kann verstehen, dass daher auch dieses kommt mit, ab und zu möchte ich mich doch mal so in den Pott reinschalten und gucken, was da ist, ein bisschen debuggen. Also ist sehr verlockend, ne?

Ja, also ich halte es immer für gut und notwendig, wenn es so einen Breaking-Glass-Prozess gibt, dass man noch wo rankommt im Notfall.

Mmh. Mmh.

wenn Dinge schieflaufen, aber du musst ja natürlich genau um diese Log Aggregation und so weiter, musst du dir vorher Gedanken machen. Das ist halt ein geplanter Prozess. Du kannst nicht einfach den Container da reinschmeißen und sagen, so, jetzt läuft er da und du wirst in Probleme laufen, wenn du das machst. Und dann wirst du den Reflex haben und sagst, Ich möchte jetzt aber da mal eben drauf und schauen, was da los ist. Und genau da fängt halt das Problem an, weil dann ist die Planung und die Prozesse vorher nicht gelaufen. Du musst dir halt Gedanken machen, machen, wie bekomme ich denn diese Informationen, die ich brauche, aus diesen Logs und wie kann ich denn auch diese Menge an Logs von diesen ganzen Services, die da laufen, dann lesen und nachvollziehen und wie verfolge ich das denn eigentlich, wenn wir denn jetzt das Thema haben, dass der Nutzer auch noch auf unterschiedlichen Pods landet.

Mhm. Mhm.

Ja, und dann reden wir halt noch nicht davon, dass irgendwie ein Istio oder so mitläuft und du auch noch mtls hast und sidecar container und so weiter und so fort ja das kommt dann ja auch noch alles oben drauf dann hast du dann zwei container mit der applikation import laufen aber dann laufen da noch drei sidecar container kurz rum was für secrets was für mtls was für keine ahnung was noch der auf die idee kommt was brauchst und dann hast du eine ganz andere komplexität als wenn du das in einem docker compose setup passt als wenn du das auf einer normalen vps laufen hast und

Vielen Dank.

Und du hast halt sehr, sehr viele, sehr komplexe Themen, mit denen du auf einmal als Team oder als Einzelkämpfer, als Einzelkämpfer ja fast unmöglich, aber als Team konfrontiert bist, die du handhaben musst. Und wo du auf einmal feststellst, okay, deine Containerisierung und deine Plattformstrategie, das passt alles nicht so richtig zu dem, was du da gerade machen möchtest. Du rennst auf einmal gegen so einen Berg, gegen so eine Steilküste, stehst du, das Wasser wird immer höher, Und musst du das auf einmal managen. Und das ist halt etwas und stellst halt fest, okay, du brauchst eigentlich gerade sehr viele, sehr gute Leute mit sehr viel Wissen, die durch die Gegend rennen und das ganze Ding mit dir zusammen machen.

Und spätestens nach dem ersten Inzident, wenn der Shop offline ist, der Puls bei 180 ist, der PO, alle fünf Minuten anruft und fragt, ob man schon was sehen kann, wird man dazu übergehen, das dann zu optimieren?

Ja, den PO kann man ja ruhig stellen, einfach das Telefon aus der Wand reißen.

Ein Vorteil von Remote-Arbeit.

Teams abschalten.

Das dauert, bis der die 50 Kilometer überwunden hat.

Ja, genau. So, also, ähm, aber, ja, natürlich, sobald du den ersten Inzident hast und alle darstellen und sagen, was denn jetzt passiert, ähm, denkst du auf einmal auch noch ganz andere Dinge nach. Das sind ja ganz viele Learnings aus ganz viel Erfahrung, aus ganz viel dumme Fehler machen, aus ganz viel in den ganzen Teams, die daran beteiligt waren, wusste es niemand besser.

Mhm. Mhm.

Und dann kommst du in neue Teams und musst das immer wieder predigen, beibringen, weiter multiplizieren. Das Wissen, die Systeme entwickeln sich weiter. Es gibt andere Möglichkeiten. Es gibt neue Stolpersteine, neue Möglichkeiten, sich das Knie aufzuschlagen. Das ist ja nicht so, dass die Systeme stehen bleiben und so bleiben, wie sie sind, sondern jeden Tag kommen neue Security-Sachen, jeden Tag kommen... oder jede Woche kommen Änderungen, jeden Monat gibt es Sachen, die eingespielt werden, die Sachen verändern. Also das heißt, du begibst dich damit definitiv auf einen kontinuierlichen Weg der Weiterentwicklung mit vielen blutigen Knien.

Ja, hört sich gut an. Definitiv.

So, also es macht Spaß, also ich liebe diese geklasterten Systeme, ich liebe die Möglichkeiten von Kubernetes. Ich mag das, wenn Systeme einfach skalieren und schnell sind und funktionieren, aber da gehört verdammt viel Wissen und Erfahrung dazu, auch um zu sagen, man macht jetzt nicht dieses pure Over-Engineering. Ja, mal zu wissen, wo man einfach sagen muss, so ein Docker Compose auf einem normalen VPS mit ein bisschen fancy Readiness Probe, Lifeness Probe und vernünftigen Restart Policies und vielleicht starten wir auch mal mehr als eins oder so, wenn wir ganz crazy unterwegs sein wollen. Ist manchmal geiler und stabiler, als sich zu sagen, wir stellen einen Cluster ein.

Ja, diese Fähigkeit nicht zu übertreiben.

Aber die Lebenserfahrung brauchst du ja auch, ne?

Also zumindest, wenn es um Produktivsysteme geht. Also bei meinen Spielprojekten habe ich immer übertrieben. Ja, ja. Ja.

Ja, dafür sind ja Spielprojekte auch da. Ehrlicherweise, man braucht ja Projekte auch zum Lernen. Und es gibt ja wenig Projekte, in denen du wachsen und lernen kannst. Ja, die werden ja leider wieder immer weniger. Wir hatten eine Zeit, da sind die mehr geworden. Da konnte man sich auch in Projekten mit so etwas entwickeln und Ideen ausprobieren, auch mit entsprechenden Teams. Und da hat man das auch als entsprechende Möglichkeiten gesehen. Aber gerade sind die sehr ragesät. So. Na, und ich glaube, gerade ist es ganz gut, wenn man halt diesen wilden Mix mal mitgemacht hat, ein AKS, ein GKE, äh, wer heißt der gleich, ECS und so weiter, EKS und noch OpenShift. So, also, und Docker Swarm und so weiter und so fort. Ja, dann hast du halt ein Wissen, Wissen, wo viele Leute nicht rankommen oder nicht haben.

Ja.

wo man halt auch gut sagen kann, es ist halt einfach eine dumme Idee, was man hier gerade macht. Ohne das auch wirklich, und das kommt dann ja, wenn ich sowas sage, manche Menschen nehmen mir das ja so extrem übel, wenn ich sage, nee, das ist alles dumm, was hier jetzt gerade passiert und dumme Ideen. Aber das ist einfach gelernt aus Schmerzen, liebe Freunde der Nacht. das ist jetzt nicht, weil ich sage, ich kann das alles so viel besser und ich habe nie diese Fehler gemacht. Nein, ich war an dieser Stelle, ich habe diese Fehler gemacht oder ich habe vorher erkannt, dass es eine dumme Idee ist und habe diesen Fehler nicht gemacht, weil ich die Dokumentation gelesen habe und dann vielleicht zwei, drei Tage darüber nachgedacht habe, ob das wirklich jetzt der richtige Weg ist und zu dem Entschluss gekommen bin, nee, das ist eine dumme Idee.

angemacht.

Und daraus kommt das dann, dass ich dann halt manchmal sage, nee, Freunde, nee, bitte nicht. Wir gehen einen anderen Weg.

Ja, definitiv. Also Kubernetes löst nicht alle Probleme und wenn du in deinem Team... Genau, genau.

Nein, aber es bringt dir ein Bannschneuer Probleme mit, wenn du die haben möchtest.

Das bringt einige mit.

Wenn du halt nicht das Team hast, nicht die Erfahrung hast, dann bringt es dir halt Probleme mit.

Gleich hier.

Die zeigen aber halt meistens einfach sind das Symptome dafür, dass du einfach noch nicht bereit bist, das zu machen, weil dein ganzer Stack davor noch nicht bereit ist. Und weil dein Team auch nicht bereit ist.

Das ist halt ein Thema von Geschwindigkeit. Also wenn nur ein Teil deiner Prozesse beschleunigt wird, die anderen aber langsam bleiben, gewinnst du nichts, dann bewegst du nur schneller Artefakte von A nach B, aber der Rest passiert nicht oder umgekehrt. Du kommst gar nicht hinterher mit dem Artefakte bauen und deine Applikation langweilt sich, weil da nichts vornherum kommt. Und das ist...

Naja gut, aber also Kubernetes ist jetzt ja keine Beschleunigung für Sachen. Also mehr Komplexität macht die Dinge in der Regel nicht schneller. Du kannst damit, also du brauchst ja auch eine gewisse Kategorie an echten Herausforderungen. wovor ein Kubernetes Sinn macht. Wenn du halt nicht diesen krassen Traffic hast und dann bei einem Hyperscaler bist, sondern einfach nur eh deine festen Ressourcen hast und nicht dynamischen Traffic, ja, dann ist es auch völlig egal.

Mhm. Mhm.

Ja, auch wenn du eh sagst, okay, das ist so vorhersagbar, in welchem Rahmen sich mein Traffic bewegt. Wenn ich deine VPS kaufe in der richtigen Größe, dann bist du wahrscheinlich meistens billiger, als wenn du Skalierung mit Kubernetes machst. bei der Kubernetes wird immer mehr Ressourcen nach oben drauf packen. Also, bis sich ein Kubernetes lohnt, musst du schon sehr starke Wellenbewegungen haben. Also, wenn du sagst, okay, ich merke die Mittagspause in Deutschland um 12 jeden Tag, also jeden Arbeitstag, und ab 18 Uhr merke ich das auch immer, dann geht es ganz krass nach oben und dazwischen brauche ich einfach viel weniger Ressourcen. Ich sage jetzt mal, normal, also von von Mitternacht bis 12 Uhr brauchst du zwei bis drei Pots, um Schlag 12 musst du hoch auf fünf bis sechs und dann um 14 Uhr wieder runter und dann ab 18 Uhr wieder hoch bis Mitternacht, dann hast du vielleicht dieses Thema. Und dann hast du noch Fernsehwerbung, dann möchtest du nochmal höher gehen.

Friday. Okay.

Oder dann hast du ein sonniges Wochenende, Und dann ist dein Traffic auf einmal zehnmal so hoch, wie wenn es regnet. Das erste Frühlingswochenende macht dir sonst die Server platt. Dann reden wir über Kubernetes. Oder du hast halt, es wird etwas bekannt gegeben und auf einmal greifen eine Million Leute drauf zu auf deine Seite und sonst sind es fünf. Das sind so Szenarien, wo Kubernetes Sinn macht. Und dann in der Kombination, wenn du dann eh Hardware da stehen hast, dann macht das vielleicht auch Sinn, zu sagen, okay, wir haben hier ganz viele kleine Systeme auch im Kubernetes-Cluster stehen, da schwankt auch der Traffic immer so ein bisschen, für die lohnt sich das nicht, aber für die, die Hyperscaling machen müssen, da brauche ich ja auch die Hardware und dann ist sie wenigstens nicht ungenutzt, ne, das sind auch Nutzungsszenarien.

oder wenn du größere oder mehr Teams hast und zum Beispiel da die Arbeitsweise anpassen willst und sagen, also wenn du mehr so in DevOps-Richtung gehen willst, dass die Leute selber Sachen deployen können, Preview-Umgebungen deployen können.

Ja, das kannst du aber auch in Dockers Form, ne?

Ja, aber du bist, also in größeren Unternehmen ist das leichter umzusetzen, als wenn jeder da irgendwie so seine VPS sich holt und daher irgendwo Sachen hin deployt und wegräumt und

Genau, also du brauchst halt realistische Anwendungsszenarien für das ganze Ding.

weil du das dann zentralisieren kannst. Aber dann reden wir mal wieder darüber, dass du da dediziert Leute hast, die den Kubernetes-Cluster betreuen oder den Managed-Cluster betreuen und sich darum kümmern, dass das Ding funktioniert.

Ja, so. Weil halt automatisiert immer noch nicht so richtig funktioniert. Gib mir mal noch ein paar Monate. Ja, komm, was soll das denn? Bisschen größer und wahnsinnig muss man nicht mal was sagen.

Finde ich gut. Ich war der Erste, der dich kennt. Shotgun. Ich mochte dich schon, bevor du reich warst. Statistisch steigt die Wahrscheinlichkeit.

Falls ich denn reich werde von solchen verrückten Ideen. Bisher hat er ja keine meiner verrückten Ideen zu Reichtum geführt. Ja, vielleicht ist die Idee ausreichend verrückt. Ach so.

Verrückt machen wir im nächsten Thema, äh, in der nächsten Woche nochmal. Ne, wir sagen am Ende immer so, ja, das Thema machen wir in der nächsten Woche, dann weiter. Wir haben gerade kein Thema für die nächste Woche. Ne. Waren los.

Ja, haben wir da jetzt eins?

Ja. Irgendwas. Verrückt und Security.

Okay, dann sehen wir uns nächste Woche mit einem Thema, was wir noch rausfinden, was auch mit verrückten Menschen zu tun hat. Richtig? Perfekt. Verrückt und Security. Ach so, okay. Verrückt und Security. Gut, dann sehen wir uns nächste Woche mit Verrückt und Security bei Secrets Not Included. Macht's gut und bis dahin. Ciao, ciao.

Bis dann.