 Moin! Ja, dann fangen wir mal an. Ich stelle mich kurz vor. Ich bin Heiko, Senior IT-Konsultant. Hauptsächlich in der AWS Cloud unterwegs. Und da packe ich tatsächlich auch Fahrzeugereien. Und ja, ansonsten, man hat mich vielleicht heute schon gesehen, wenn ich mal Freizeit habe, neben der Arbeit, bin ich mit dem Longboard unterwegs. All right, ich bin Sedy. Ich habe vorhin auch schon ein Talk erhalten über Alerting. Und jetzt habe ich die große Ehre mit Heiko zusammen, einen kleinen, witzigen Talk zu halten über Kubernetes. Und da wir beide sehr viel Spaß mit Kubernetes haben und auch sehr negative Erfahrungen schon gemacht haben, haben wir uns gedacht, packen wir mal so ein paar Slides zusammen. Das Ganze wird präsentiert in drei Akten. Natürlich zuerst gut, dann the bad und dann erzählt Heiko ganz grausame Dinge. Gut, fangen wir an. The good. What the fuck ist eigentlich Kubernetes? Und warum ist es so geil? Warum reden da alle drüber? Und warum wollen es alle unbedingt benutzen? Also Kubernetes löst für uns so ein paar ganz nette Probleme, die wir so in der Cloud haben. Wir können nämlich unsere Container, wir machen ja mittlerweile alle so Docker-Container und keiner von uns kann mehr Anwendungen richtig verteilen über Paketmanager, deshalb machen wir Docker. Und irgendwo müssen die laufen. Das ist gar nicht so geil, wenn man das so von Hand machen muss. Deshalb haben wir gedacht, Kubernetes ist voll gut. Haben wir irgendwie standardisierte APIs, können unsere Infrastruktur, unsere Hardware damit voll automatisch managen. Richtig geil, können das scale. Und tatsächlich, wenn Applikationen sterben, kümmert sich Kubernetes sogar darum, dass sie von alleine wieder hoch kommen, wenn sie nicht komplett broken sind. Ja, das ist ja eigentlich voll gut, weil jetzt müssen wir auch keine gute Software mehr schreiben. Jetzt müssen wir einfach nur noch darauf achten, dass ihr abstürzt. Und naja, all so viel Gutes haben wir auch gar nicht mehr über Kubernetes zu erzählen. Ja, das war tatsächlich schon der gute Teil. Kommen wir zum schlechten. Kommen wir zu Teil 2, the bad. Ich fange mal ganz kurz an. Wenn wir von Kubernetes reden, dann reden wir ganz, ganz häufig von verteilten Systemen. Unser ganz lieblings Busword, wir verteilen Dinge. Tatsächlich funktioniert Kubernetes aber gar nicht so sehr verteilt, wie wir uns das manchmal wünschen. Meistens laufen die API-Server, nämlich genau auf drei Notes. Und die selben drei Notes werden benutzt für den ADC und den API-Server und für den Scheduler und für alles andere, was Management auf Traffic betrifft. Und nur die Anwendung selbst läuft distributed und somewhat defeats the purpose of a distributed system. Ja, dann Kubernetes ist natürlich auch ein schöner Complexity Amplifier. Wirf Kubernetes drauf, das Softwareprojekt wird direkt erst mal zehnmal so aufwendig. Und wie Swift on Security ist so schön gesagt, hatte one time I tried to explain Kubernetes to someone, then we both didn't understand it. Es ist wirklich ein relativ komplexes System mit vielen Points of failure, die dann auch die debugging teilweise schwerer machen. Aber es macht Operations ja so einfach. Genau, standardisierte APIs. Gut. Ein weiteres Problem von Kubernetes. Wer bekommt bei der Slide Anxiety? Ja, dachte ich. Man merkt, wer mit Kubernetes schon viel gearbeitet hat. Es gibt eine Million Choices, die man treffen muss. Es ist wirklich unschön. Und das große Problem ist, wenn man sich für jeweils eine dieser Tools oder Frameworks entschieden hat, es ist wirklich schwierig, das wieder rückgängig zu machen. Also wenn man mal angefangen hat mit linker D, dann zu Istio wechseln. Did you ever try that? Anzünden und neu machen, spart Zwischenschritte. Ja, der häufigste Schritt bei Kubernetes ist einfach clusterlöschen, neuerstellen. Und ja, noch ein weiteres Problem von Kubernetes. Jeder hat seine eigene Geschmacksrichtung. So ein Azure AKS ist halt nicht vergleichbar als Amazon an Kubernetes-Deployed. Und Google hat natürlich als mehr oder weniger Miterfinder von Kubernetes auch wieder seinen eigenen Flavor. Und dann gibt es noch lustige Leute wie Redhead, die dann OpenShift auf Basis von Kubernetes bauen. Und es gibt natürlich noch ganz verrückte Leute, die Plane Kubernetes auf Bermettel deployen. Alles nicht miteinander so wirklich kompatibel. Heiko, deine Lieblingsleit. Ja. Wer hat das nicht schon mal in einem Kubernetes-Cluster erlebt? Wir packen die Datenbank mit rein. Dann ist sie ja distributed und clusterized und wir haben keine Probleme mit der Datenbank. Am Arsch. Das bringt uns auch schon direkt zu unserem dritten Akt. Das kleine Problem. Datenbank-Server in Kubernetes packen. Denkt man sich natürlich, eigentlich super Idee, wenn der eine Server wie hier im Bild in Flammen aufgeht, wird einfach die Workload auf den nächsten Server geschoben. Ist halt nur blöd, wenn im Zweifelsfall auch die Volumes und so weiter auf dem Server lagen, der gerade brennt. Hat man halt im Zweifelsfall keine Daten mehr. Das ist ja auch ein Problem im PvC, im Chef-Cluster. Auch richtig schön. Macht doch das Debugging richtig schön einfach. Ja, und die laden sie so viel besser. Auch ein Horror für jeden, der schon mal mit Kubernetes gearbeitet hat. Es gibt tatsächlich Leute, die wollen unbedingt ihre Scheiß-Cluster mit einem UI-Managern. Ich weiß nicht, wer auf die Idee kommt, aber anscheinend genug Leute, dass es Ranshohe und OpenShift gibt, und jeder, der schon mal versucht hat, ein Kubernetes-Cluster zu debuggen, was mit einem dieser Tools eingerichtet wurde, mein Bylight. Auch sehr beliebt im UI-Konfigurieren. Aber wo sind die Config-Files? Keiner kehrt. Was ist mit unserem schönen Infrastructure as Code? Da sind Exists anymore. Im UI-Konfiguriert in der CLI Debugged. Wer so etwas schon mal machen durfte, weiß, was das für ein Spaß ist. Und ja, die nächste Stufe noch schlimmer, wo wir auch eben den vollständigen Cloud-Opload von Rechenzentren hatten. Manuelle Diploments per Hand, ohne die ICD, sind halt auch so was, was man wirklich nicht tun sollte. Ich habe es tatsächlich bei einem Kunden erlebt, wo dann freitags Nachmittags das neue Diploment in Produktion war. Die Helm-Charts und die ganzen Templates lagen beim Lead-Developer auf dem Laptop, nicht mal in einem Git. Und es wurde solange Cube-CTL-Apply minus F, minus minus Force gemacht, bis die Applikation am Ende wieder lief. Er saß, glaube ich, Sonntagsabend noch dran. Okay, das größte Problem, was wir mit solchen Horror-Stories haben, ist, dass dieser Talk aufgenommen wird und gestreamt wird. Und wir können nicht so viel erzählen, wie wir gerne wollten. Deshalb war es das jetzt schon. Wir sind sehr gut in der Zeit, aber wir können noch ein bisschen Q&A machen. Und ansonsten vielleicht gibt es auch noch Horror-Stories in den Sussatmin-Nightmares.