 Hallo und herzlich willkommen am zweiten Tag der Gulasch Programmier-Nacht Nummer 21. Ihr befindet euch im Mediencenter, falls jetzt nicht über Kubernetes was hören wollt, seid ihr falsch, aber es seid prinzipiell richtig, weil wir haben zwei grandiose Vortragende für euch. Also bleibt einfach mal da und lasst euch überraschen. Das Thema ist, die Welter-Container-Archistierung ist abschreckend. Nein, sorry, Entschuldigung, das steht anders hier. Die Welter-Container-Archistierung ist für Einsteigerringenden oft zunächst abschreckend. Also wer sich vor Orchestrierung Docker, Kubernetes und anderem Zeug fürchtet, ist hier richtig. Wer schon mal was davon gehört hat, ist richtig. Wer das alles schon kennt und unterhalten werden will, ist auch richtig. Das heißt, begrüßt bitte mit mir mit einem ganz, ganz großen Applaus. Archangel und CD mit From Zero to Kubernetes. Hi, also wir hatten ja letztes Jahr schon hier gegenüber den Talk, wo wir so ein bisschen über Kubernetes geschittet haben. Und dieses Jahr haben wir uns gedacht, machen wir doch tatsächlich mal einen leicht seriösen Talk über das Thema. Deshalb freut euch auf ein halbes Gigabyte-Präsentation mit 74 Slides. Und Heiko fängt direkt mal an. Ja, ich bin Heiko, Senior Consultant für eine Firma, von der ihr wahrscheinlich noch nie gehört habt. Und meistens ist meine Aufgabe, irgendwie dafür zu sorgen, moderne Elektrofahrzeuge irgendwie in die Klau zu kriegen. Ansonsten, wenn ich Zeit habe, fotografiere ich gerne Events. Kann also sein, dass ihr mich morgen auch mit einer Kamera hier rumlaufen seht. Und ja, als Transportmittel, ich persönlich bevorzugehen, Borts im Gegensatz zu Autos. Ja, und ich bin CD. Ich bin auch Software-Engineer oder SRE eigentlich. Mach so genauso wie Heiko, was mit Fotografie. Allerdings mache ich hauptsächlich analog. Deshalb sieht man mich nicht so häufig mit der Kamera, weil das ganz schnell, ganz schön ins Geld geht. Und jetzt lasst uns auch direkt mal mit dem ersten Thema anfangen, der ich warum eigentlich Container beziehungsweise VMs und Container. Und ich glaube, dieses Leid haben viele, die sich mit Container befasst haben, schon mal gesehen. Auf der, von euch aus gesehen linken Seite genau, habt ihr, wie so virtuelle Maschinen aufgebaut sind. Also man hat halt seinen Server, da läuft eine Hyperweise-Software drauf, so meistens irgendein Linux. Und dann emuliert man ein komplettes Betriebssystem, also nochmal ein komplettes zweites Linux, um darauf dann eine einzelne Anwendung zu installieren. Und schlaue Leute haben sich irgendwann mal gedacht, das ist irgendwie nicht so richtig optimal, weil man muss ja jetzt zwei Linux-Betriebssysteme administrieren. Man muss einmal den Hypervisor aktuell halten, Security Patches einspielen und dann noch auf der Guest-VM. Und dann kam man mit dieser großartigen Idee, Container zu bauen. Man hat nur noch ein einzelnes Betriebssystem, nur noch ein Linux, wo dann die Container-Engine draufläuft. Und man startet die Anwendung, isoliert in einem Container. Für Container gibt es total viele, viele Lösungen. Also Docker haben die meisten von euch gehört, aber es gibt auch noch sowas wie LXC-Container. Deshalb, wir sprechen jetzt nicht nur von Docker, sondern von Container allgemein. Und man hat sich einfach gedacht, wenn man jetzt so eine Anwendung in diesen Container paketiert, dann ist das irgendwie einfacher und man kann so dieses Problem lösen von Works and My-Maschinen und dann schippt man einfach so die ganze Maschinen in Produktion. Und das hat eigentlich ganz viele Vorteile. Zum Beispiel, man kann das Works and My-Maschinen-Problem umgehen, man kann einfach die eigene Maschine in Produktion schippen und sagen, ja, funktioniert. Es ist auch ziemlich einfach zu skalieren, weil ich sagen kann, ich habe jetzt hier meine Containerdefinition und jetzt startet den Container nicht nur einmal, sondern tausendmal. Und weil das alles in diesen Containern ziemlich einfach zu bedienen ist, kann man das auch ganz gut automatisieren. Ja, aber es hat halt nicht nur alles Vorteile, es hat auch Nachteile. Es ist halt yet another Layer, den man patchen muss und sich kümmern muss. Und dieser Layer hat halt eine gewisse Learning Curve. Man ist tatsächlich gerade bei Containern sehr oft darauf angewiesen, dass man eine wirklich gute Doku hat. Ansonsten ist man mehr oder weniger verloren. Gerade wenn man irgendwie so ein Docker-Compose-File hat und nicht alle potenziellen Switches für die App dokumentiert sind, rätselt man sich zu Tode, wie man es dann richtig konfiguriert. Und es gibt halt auch ein paar wenige Tools dafür. Also ich hatte es ja gerade schon angesprochen mit virtuellen Maschinen. Wir haben jetzt hier nur noch mal so den quasi den direkten Vergleich zwischen VMs und Docker noch mal ein bisschen oder Container aufgezeigt. Wenn man jetzt so eine virtuelle Maschine verwalten will, dann kann man das natürlich so auf einer Host ganz gut machen, wenn man einfach lib wird benutzt. Ganz viele Leute wollen jetzt aber nicht nur einen Server verwalten, sondern so ein paar Hundert oder vielleicht sogar ein paar Tausend, je nachdem wie euer Setup aussieht. Und dann benutzt man auch ganz schnell mal sowas wie Proxmox oder VM-Ware, wo man halt die Möglichkeit hat, viele Maschinen zusammen zu klassen und dann eine virtuelle Maschine auch zwischen den ganzen verschiedenen Hardware-Maschinen hin und her zu schieben. Ähnlich sieht es auch mit Containern aus. Wir wollen ja nicht jeden Container einzeln managen. Da ist dann so der Klassiker Docker-Compose. Das managt aber eigentlich nur Container auf unserem einen Server und wie C.D. schon sagte, wir wollen ja nicht nur einen Server haben. Im Zweifelsfalle, wenn wir skalieren, wollen wir zehnhunderttausend Server haben und da ist dann so ein Docker-Compose nicht mehr ganz so geil. Dann brauchen wir tatsächlich irgendwas anderes. Da wäre jetzt Docker Swarm oder am besten Kubernetes das Mittel der Wahl. Genau und wie wir jetzt gerade schon Heiko das schon angeschnitten hat, das eigentliche Thema, warum wir eigentlich hier sind, ist ja irgendwie so Container-Orchestrierung und später dann auch Kubernetes. Aber wenn wir von Container-Orchestrierung sprechen, fangen wir doch mal langsam an. Wir wollen ja jetzt nicht irgendwie das der halbe Raum einfach rauskann, wenn wir direkt mit Kubernetes anfangen, sondern euch so langsam das Wasser immer ein bisschen heißer machen. Mit Docker-Compose ist das eigentlich schon ganz schön einfach, weil Docker-Compose ist ein Tool, wo man in einem YAML-Feil definieren kann, welche Docker-Container möchte ich denn gerne starten, in welches Netzwerk sollen die, welche Environment-Variablen sollen die Docker-Container bekommen. Und dafür ist Docker-Compose eigentlich schon ein ziemlich, ziemlich gutes Tool. Sieht dann ungefähr so aus, dass hier ist ein Beispiel von der GitLab-Docker-Compose-Feil. Wie ihr seht, sehr viel YAML, sehr viele Leute, die mit Docker und Kubernetes arbeiten, bezeichnen sich auch gerne mal als YAML-Engineers. Docker-Compose ist schon ziemlich cool. Es ist ziemlich einfach und man hat halt auch so diesen Vorteil von, ich kann meinen Production-Setup auf meinem Laptop sehr einfach testen, weil Docker-Compose macht es mir möglich, mehrere Environments auf derselben Maschine zu starten in verschiedenen Network-Namespaces. Ja, das hat halt nur den Nachteil. Single-House, Docker-Compose ist halt für Single-House. Aber es gibt natürlich bei jedem Cloud-Provider, den ihr euch vorstellen könnt, auch schöne fertige Lösungen, um eure Docker-Container da zu hosten, mit minimalem Overhead. Empfehlen würde ich jetzt direkt keinen, aber nur damit ihr auch mal gesehen habt, jeder Cloud-Provider, der auf sich hält, hat eigentlich so eine Lösung, wo ich einfach nur meinen Container irgendwo in die Wolke werfe und mich um nichts anderes kümmern muss. Wie gesagt, kann man so machen, ob man es machen will, weiß ich nicht. Und ja, was die Container-Orchestration sonst noch angeht, die Honorable Mansions, gibt da so ein Paar, Apache Mesos ist inzwischen tot, Service-Fabrik, ja, wenn man es mal angefangen hat, vielleicht, aber es ist eine echt harte Lernkurve, Docker Swarm, ja, kann man machen, ist okay, aber auch nicht wirklich toll. Wenn man sich alles selber bauen will, kann man es mit Pace-Maker machen, funktioniert, aber man baut halt lang und viel selber. Wenn man Geld drauf werfen will, nehme man HashiCrop Nomad, dann wirft man aber viel Geld drauf, das Problem. Und dann gibt es, was ich tatsächlich privat auch noch einsetze, das Trunner Scale, da kann man auch mehr oder weniger einfach Container spawnen, aber die Community ist einfach eine stellenweise toxische Pile of Shit, deswegen würde ich das auch nicht empfehlen, wenn ihr irgendwie Community Support haben wollt oder Fragen habt und euch nicht alles selber beibringen wollt. Deswegen, unser Mittel der Wahl ist und bleibt Kubernetes. Genau, ich glaube, wir beide betreiben Kubernetes-Cluster zu Hause und auch beruflich auch teilweise größere Cluster und ich habe mal Docker Swarm ausprobiert, war einfach nichts für mich, ich finde, mein Mittel der Wahl ist für Container eigentlich immer Kubernetes. Aber was ist denn jetzt Kubernetes eigentlich wirklich? Viele sagen so, ja, Kubernetes ist auch nur ein Tool, stimmen nicht so ganz, das alles ist nämlich irgendwie Kubernetes oder zumindest Kubernetes-related und wenn man sich jetzt mal durchliest, was Wikipedia zu dem Thema zu sagen hat, dann liest man da auch, dass Kubernetes eben nicht ein einzelnes Tool ist, sondern ein Set an Building Blocks, die man zusammenbauen kann, um sich ein Container-Orchestratur zu bauen. Man hat vor allem sehr viele standardisierte APIs, damit die einzelnen Komponenten effizient und standardisiert miteinander reden können. Und wenn man sich das jetzt noch mal anguckt, dann sieht man ja auch, dass man da sehr viele einzelne Gruppen hat und wenn man sich jetzt sein Kubernetes-Cluster bauen möchte, kann man sich auf diese Landscape verlassen, dass da die wichtigsten Tools alle draußen sind und dann guckt man, welches Tool finde ich denn so am besten in jeder Kategorie und dann kann man sich da schön die einzelnen Bausteine rausnehmen, die man braucht und sich sein Kubernetes-Cluster zusammenbauen. Aber so ein paar Komponenten in Kubernetes, die sind wirklich schon sehr essentiell wichtig und das hat Heiko noch mal in der Übersicht, was man in so wirklich essentiell braucht. Genau, wir brauchen erst mal unseren Kubernetes-Masternode. Da ist halt so der API-Server drauf, der uns diese Schnittstellen bereitstellt, dass wir verschiedene Dinge nutzen können. Der ETCD, der quasi so unsere Datenbank ist, wo sämtliche Konfigurationen und so weiter drinnen ist. Dann haben wir noch ein Scheduler, der guckt, dass unsere tatsächliche Applications-Workload auf den einzelnen Notes dann auch läuft und zwar auch den Notes, auf denen wir es gerne hätten und vielleicht auch von den Notes, wo wir gerade nicht wollen, dass unsere Applikation lotzie runtergezogen wird. Und je nachdem, wenn wir in der Cloud-Welt sind, haben wir auch noch ein Cloud-Controller-Manager, der an die API des Cloud-Providers geht und uns automatisiert Dinge bereitstellen kann, den Load Balance hat zum Beispiel konfigurieren kann oder wenn wir plötzlich mehr Storage brauchen über die Cloud-AP, uns einfach mit Storage provisioniert. Und ja, es gibt so ein paar verschiedene Distributionen und Flavors von Kubernetes, von so Micro-K8s über OpenShift. Inzwischen kann man sogar OpenShift auf der IBM Cloud laufen lassen. Vielen Dank, Leiber. Ich weiß immer noch nicht, wer das will, aber sogar SAP hat inzwischen sein eigenes Managed Kubernetes im Angebot. Und ja, es gibt eine Fülle von Distributionen, die man einsetzen kann, aber nicht unbedingt muss. Und vor allem haben diese Distributionen auch verschiedene Einsatzzwecke. Im Development möchte man halt vielleicht nicht unbedingt einen Riesencluster mit mehreren Server-Notes mit über 100 CPU-Kos, sondern es reicht vielleicht, das Ganze auf seinem lokalen Laptop laufen zu lassen. Dann nimmt man halt so ein Kind oder Micro-K8s. Dann, wenn man schon mal etwas mehr Richtung Produktiveinsatz geht, hat man K3S, was relativ wenig Ressourcen verbraucht, eher für Single-Note und Edge optimiert ist, aber man auch schon ganz gut seine Workloads draufpacken kann. Und es gibt halt so die Cluster, die sich dann Production-Grade quasi nennen, Cops, Q1, Cluster API, um da mal 3 zu nennen, die dann richtig Multinode sind mit High Availability und Soße und Schaft, dass man da wirklich dann schon ein Kubernetes Cluster hat, fast je nachdem, wo man die Proat relativ teuer ist, aber was halt auch ordentlich Workload wegschafft. Und wenn wir das dann noch ein bisschen weiterspinnen, es gibt halt auch Enterprise-Installationen, die dann dem Standard Kubernetes noch ein paar Features hinzufügen. Da würde ich halt dann so OpenShift zum Beispiel nennen oder halt das Kubernetes von SAP, die einem zusätzlich vielleicht noch nettes GUI bereitstellen, die einem Tools bereitstellen für das Tracing der Applikation. Wo hängt es denn eigentlich, wo braucht man Request wie lange und natürlich bietet jeder Cloud Service eigentlich auch so sein eigenes Kubernetes an. Auf AWS heißt es dann EKS, auf Azure heißt es AKRS. Bei Google nennen das einfach die Google Kubernetes Engine und es gibt halt auch, wenn man wirklich viel Geld hat und sein Production-Grade Setup nicht nur bei Red Hat bezahlen will, sondern auch noch bei IBM, wie wir eben schon erwähnt hatten, OpenShift und IBM Cloud, was dann so wirklich kompletter Intent Kubernetes as a Service ist. Das ist dann aber wirklich, wenn man sich um nichts mehr quasi selber kümmern möchte und einfach viel zu viel Geld hat. So, jetzt haben wir ja schon so ein bisschen darüber geredet, was den Kubernetes ist und jetzt kommen wir zu meinem Lieblingsteil. Wann wollen wir Kubernetes vielleicht einsetzen und wann eher nicht? Und wir haben dafür ein kleines Spiel vorbereitet. Hebt mal alle die Hand, wenn ihr der Aussage zustimmen würdet. Würdet ihr Kubernetes dafür einsetzen wollen, um Static Content zu serven, also sowas wie euren Hugo Block oder so? Natürlich nicht. Also dafür kann man Block Storage benutzen und ein CDN davor klemmen. Dafür braucht man wirklich keinen Kubernetes. Andere Frage, Datenbanken. Will ich hier irgendjemand freiwillig Datenbanken in Kubernetes betreiben? Jeder der jetzt ja antworten würde und die Hand hebt, wird nachher ausgepeutscht auf der Wiese. Oder soll sich unseren Vortritt vom letzten Jahr nochmal angucken? Genau, natürlich nicht. Also natürlich wollen wir keine Datenbanken in Kubernetes betreiben, dafür ist das Tool einfach nicht gebaut. Tatsächlich wurde Service Fabric exakt für diesen Use Case gebaut, um Stateful Workload und zwar im ganz speziellen SQL Datenbanken zu orchestrieren. Könnt ihr euch antun, aber euch platzt der Kopf. Es ist wirklich kein einfaches Tool, aber wenn ihr wirklich den Bedarf habt, Stateful Workload wie Datenbanken auf großer Scale zu betreiben, dann schaut euch Service Fabric an, es Open Source kann man benutzen. Andere Use Case, den ich auch schon mal in meinem beruflichen Umfeld gesehen habe, Leute, die auf die Idee kommen, lasst uns doch die 100 Tonnen Autopresse über einen Kubernetes Cluster steuern. Gute Idee, oder? Nein, überhaupt nicht. Benutzt dafür so was wie eine SPS-Anlage oder andere SCADA-Systeme. Wenn ich in der 100 Tonnen Presse mein Kopf reinstecken muss, dann möchte ich mein Leben davon nicht abhängig machen, ob das Cubelet gerade crasht. SCADA-Systeme haben extra so was wie eine SPS benutzt das auch und kommt nicht auf so Ideen wie eine Presse mit Kubernetes zu steuern. Aus dem Internet. Aus dem Internet am besten, genau. Und jetzt noch eine andere Frage. Wir haben ja gerade schon über Datenbanken geredet. Was haltet ihr von Stateful Workload im Allgemeinen? Gute Idee. Kommt ein bisschen drauf an. Absolut gar nicht, wenn es so was ist wie eine Datenbank. Wenn ihr euren State irgendwo in der Software speichert, wenn ihr euren State direkt von der Anwendung auf die Festplatte schreibt, ist Kubernetes vielleicht nicht die beste Lösung. Aber tatsächlich eine sehr gute Lösung, wenn ihr euren State in Block Storage schreibt. Wenn ihr so zum Beispiel Grafana Mimir benutzt als Time Series Datenbank, wo der komplette State in S3 Storage gespeichert wird. Super Sache funktioniert sehr, sehr gut. Dann wer würde gerne die Legacy Enterprise Java Applikation seiner Firma in ein Kubernetes Cluster packen? Muss ich sagen, kann man tatsächlich machen. Habe ich auch eins bei Kubernetes Cluster, wo sowas gemacht wird. Hat halt Vor- und Nachteile. Einer der Vorteile ist, man kann die Density und Load seiner Hardware deutlich erhöhen. Man isoliert seine einzelnen Java Applikation, hat keinen JVM Dependency Chaos. Und ja, der State ist halt eher hoffentlich irgendwo anders gespeichert und nicht in eurer Java Applikation. Ja, und auf der nicht so guten Seite kann man schon so machen. Aber ich hatte es auch schon erlebt, dass Firmen ihre Legacy Java Anwendung in Kubernetes gepackt haben, versucht haben, das in die Klau zu schippen und dann festgestellt haben, scheiße, das ist richtig teuer. Irgendwie skaliert das doch nicht so geil, wie wir uns das gedacht haben, weil surprise, man benutzt natürlich keiner der Kubernetes Features, sondern man benutzt Kubernetes dann so ein bisschen wie eine Vm. Hat halt zur Folge, dass man sein Production Grade Kubernetes Cluster in der Cloud betreibt mit drei Control Play Notes, drei Worker Notes, in drei verschiedenen Availability Zones. Man muss für den Netzwerk Ingress und Egress Traffic bezahlen. Aber am Ende hat man dann irgendwie zwei Docker Container in dem Kubernetes Cluster am Laufen. Kann man machen, muss man aber nicht. Die werden dann wild durch die Availability Zones geschiftet. Ist okay, aber gibt bessere Lösungen. Dann wer würde Kubernetes für Edge Computing einsetzen? Einfach so ein schönes Cluster nah beim Kunden. Gibt da drei, vier Leute? Nein. Ich würde sagen, maybe. Es hat halt Vorteile, dass du deinen Service in einem sehr standardisierten Weg nah beim Kunden deploysst, kurze Latenzen. Du hast zum Zweifelsfall auch einen schönen verteilten Sync. Und da du ja in deinem Kubernetes Cluster keinen State halten soll, eh keinen State halten soll, den State kannst du irgendwo zentral lagern und alle Edge Cluster pingen einfach nur noch, holen sich ihren State vom zentralen Management System und Compute findet halt nah beim Kunden statt. Nachteil ist kompliziert. Ist jetzt nicht so, dass man hingehen könnte und sagen könnte, so klick und fertig. Und ich habe meinen Distributed Kubernetes Cluster. Kann man machen, braucht aber ein bisschen mehr Planung. Und wenn man so klassische Multicluster Deployments hat, dann braucht das meistens auch ein bisschen Erfahrung mit Kubernetes, um das richtig zu tun. Und manchmal hat man ja auch den Case, dass dann die verschiedenen Edge Notes miteinander kommunizieren müssen. Und da wird es dann mit der Latency auch manchmal ein bisschen schwierig und eng. Und dann muss man ein bisschen auftassen, dass die Latency wirklich noch im Rahmen bleibt. Aber Fun Fact, so ein Video Streaming Provider zum Beispiel macht das und betreibt die Kubernetes Cluster, die euch dann eure Lieblingsserien liefern, relativ nah bei euch, damit der Stream möglichst gut flutscht. Dann wollt ihr Kubernetes für eure Stateless Microservices nutzen? Ja, schön. Ich sehe einige Händen gegen hoch und ja genau, das wollt ihr. Das ist tatsächlich eine der besten Ideen für euer Kubernetes Cluster. Das skaliert auch schön. Und das ist, ja, da wollt ihr euer Cluster mitfüllen. Wie sieht es aus mit diesem schönen, neuen modernen Serverless Computing? Wer würde seine Lambda Funktion oder ähnliches gerne auf ein Kubernetes Cluster werfen? Na, das sind schon wieder weniger. Habt ihr auch recht? Kann man machen? Es gibt dabei ein Aber. Man braucht nämlich normalerweise dafür separate Software. So wie ein Open Function as a Service, Open Fuzz oder ein K-Native. Sollte man dann noch zusätzlich deployen, dann könnt ihr aber auch eure Lambda Funktion auf eurem eigenen Kubernetes Cluster laufen lassen. Vom Raspberry Pi angefangen bis hin zu, wenn ihr hochskalieren müsst, auf Multihost Clustern, die dann auch so 30, 40 Millionen Request verarbeiten können. Jo, also wir haben euch jetzt so ein paar Use Cases gezeigt, wo es vielleicht nicht so sinnvoll ist, Kubernetes zu benutzen. Und als wir mit Function as a Service angefangen haben, sind auch schon ein paar Leute gegangen. Das war dann ein bisschen zu viel, zu viel des Guten. Ich habe dieses vor einiger Zeit mal dieses Zitat hier gefunden und ich finde, das passt eigentlich extrem gut zu Kubernetes. Defaulte zu Kubernetes als euer Infrastructure as a Service Provider, immer nur dann, wenn ihr keine bessere Lösung findet. Kubernetes ist nicht der Heilsbringer, für den viele Kubernetes halten. Es ist ein gutes Tool, aber benutzt es immer nur dann, wenn es nicht vielleicht doch noch ein besseres Tool gäbe. Deshalb evaluiert immer sehr, sehr vorsichtig und fragt euch diese Fragen sehr ernsthaft. Braucht ihr das Kubernetes Cluster wirklich? Ist es wirklich die richtige Lösung für euer Problem? Was überlegt euch ganz genau, was sind eure Functional Requirements und seid ihr auch ehrlich zu euch? Ich weiß, viele von euch sind so ein bisschen wie ich und sind so, ja, ich möchte aber gerne mit diesem schönen neuen Spielzeug spielen und dann schreibe ich meine Functional Requirements genauso, dass die zu Kubernetes passen. Aber wirklich braucht ihr das wirklich? Gibt es nicht vielleicht ein anderes Tool, vielleicht ein Container as a Service Tool, was den Job sehr viel besser erledigen könnte? Und eine Frage, die tatsächlich sehr häufig nicht gestellt wird, ist, habt ihr die Operational Capacity, um den Kubernetes Cluster zu betreiben? Ein Kubernetes Cluster zu betreiben ist nicht somit, ich klicke hier dreimal und bin fertig und muss mich nie mehr darum kümmern. Das kann ganz, ganz schnell nun Vollzeitjob werden, dass eine Person nichts mehr anderes tut, als dieses Kubernetes Cluster zu betreuen. Habt ihr die Kapazität dafür? Habt ihr das Geld dafür, eine Person dafür abzustellen, den Rest der Zeit nur noch sich um Kubernetes kümmern zu lassen? Deshalb guckt sehr, sehr vorsichtig, was ihr so als Angebote bekommt. Braucht ihr Infrastructure oder reicht vielleicht sogar ein Container as a Service Offering und vielleicht reicht sogar Funktion as a Service und so was wie AWS Lambda. Nachdem wir euch jetzt erklärt haben, wo man Kubernetes einsetzt, wo man es nicht einsetzt, wie fängt man überhaupt an? Wie baut man sich sein erstes Kubernetes Cluster? Für die ersten Schritte nehmt ihr einfach das kleinstmögliche, so ein Kind oder ein K3D, das läuft bei euch lokal sogar auf dem Laptop, braucht nicht viele Ressourcen und ist teilweise, wie man an den zwei Screenshots unten erkennt, mit einem Kommand in 14 bis 15 Sekunden aufgesetzt. Dann habt ihr auf eurem Laptop schon euer erstes Kubernetes Cluster und könnt lustig anfangen auf dem Laptop Container hin und her zu schieben. Wenn es ein bisschen größer werden soll, gibt es dann auch K3S und ich würde sagen gerade so ein Single oder Multinode K3S, wo man dann sein Nuss Storage und eventuell noch ein Raspberry Pi, wenn man unbedingt Multinode spielen will, wird wahrscheinlich für 99 Prozent eurer Personal Use Cases völlig ausreichen. Für das Home Lab würde ich dann tatsächlich, wie gesagt, K3S empfehlen, hat eine schöne Enzibelrolle, die man quasi auch nur einmal deployt und dann hat man seinen K3S Cluster. Nur denkt dran, wenn ihr es long-term nutzen wollt, macht ein System DeService noch der K3S überwacht und auch startet, wenn ihr mal die Maschine rebooten wollt oder wie es bei mir auch mal war. Wenn ihr auf einer Konferenz seid, es bei euch im Block gebrannt hat und die Feuer den Strom abschalten musste und man dann plötzlich merkt, warum komme ich nicht mehr an mein Smart Home dran. Die Maschine wurde extern rebooted und ich habe vergessen, den Service automatisiert zu starten. Und wenn ihr wirklich all the way gehen wollt, euch ein großes Cluster anlachen wollt, benutzt die Cluster API, kümmert euch um schönes deklaratives Management eurer Workloads lest die Doku. Ich weiß, Doku lesen ist nicht immer so viel Spaß, aber tut es, es hilft. Und wer hier hat irgendwie eine Maschine oder irgendwas bei Hetzner, der wie wir vermutet haben, es sind einige hier, die Hetzner Kunden sind. Guckt euch die Cluster API von Hetzner an. Die haben tatsächlich wirklich einige schöne Sachen da gemacht und die sind eigentlich relativ gut. Aber seid gewarnt, das wird nicht unbedingt einfach. Da kann man auch mal schön zwei, drei Wochenenden für verschwenden. Und guckt, dass euer Bankkonto gut gefüllt ist. So, jetzt habt ihr einen Cluster und wollt da Dinge drauf installieren. Und die Frage ist ja auch so ein bisschen, wie bringe ich Anwendungen in mein Kubernetes Cluster rein und wie kann ich das denn so auf längere Zeit auch verwalten. Der Klassiker ist, dass man einfach auf der CLI irgendwie Helm install macht, irgendwelche Helm Charts installiert, funktioniert sehr einfach Helm, ist glaube ich so ziemlich das beliebteste Tool. Helm ist so eine Kombination aus Package Manager wie APT oder Homebrew, vereint aber auch automatisch noch direkt im selben Schritt mit Konfiguration. Das heißt, man hat Value-Yaml-Files, wo man die Konfiguration für die Anwendung drin speichert. Und man kann dann Helm sagen, installiere bitte mein Next Cloud Setup mit dieser Value-Yaml. Dann hat man sowohl Package Management als auch Konfiguration direkt in einem Schritt. Customize und Tanker machen im Prinzip dasselbe, sind nur nicht so weit verbreitet. Und Cube CTL ist so der Klassiker, wirklich so die Basic CLI, um sein Kubernetes Cluster zu verwalten. Und das funktioniert auch wirklich sehr, sehr gut. Da ist die letzten Jahre sehr viel passiert, vor allem mit dem Versionssprung von Helm 2 auf Helm 3, wurde das alles sehr, sehr benutzbar. Das Problem ist, bitte macht das nicht on Production. Also wirklich nicht. Ich musste Cluster wieder reparieren, wo Leute einfach jahrelang einfach immer nur Cube CTL, Apply minus F und irgendwelche Yaml-Files gegen das Cluster geworfen. Es dauert Monate rauszufinden, was auf diesem Cluster läuft, wie es konfiguriert wurde, wer hat es gemacht, warum läuft in diese komische Konfigurationen. Es ist alles nicht so geil, deshalb, okay, hier nochmal die, die, warum nicht, Punkte. Und die Lösung dazu ist natürlich wie immer Git. Wir wollen nicht nur unseren Code in Git verwalten, sondern auch unsere Konfigurationen. Und jeder, der so schon mal Infrastructure as Code gesehen hat, weiß ja, auch Infrastructure as Code ist Code und auch Konfigurationen gehört in Git. Deshalb speichern wir alles in Git. Dieses Diagramm dürften auch die meisten schon mal gesehen haben. Man hat halt hier irgendwie seinen Development Flow, man schreibt Code in seiner IDE, man bildet es, man committed es nach Git, dann laufen automatisiert die Tests. Wenn alles gut aussieht, wird es nach Kubernetes Deployed oder wohin auch immer. In, speziell im Zusammenhang mit Kubernetes gibt es das Modell, das sich GitOps nennt. Und GitOps ist ein bisschen anders implementiert als die klassische CI CD. In der klassischen CI CD hat man sowohl Push als auch Pull-Konfigurationen. Genau, und bei Push braucht quasi eure Pipeline, braucht Zugriff auf das Kubernetes Cluster. Eure Pipeline wirft dann tatsächlich fast schon wie CubeCtL Appli Minus F in euer Cluster. Kann ich nicht empfehlen, weil unter anderem, das erkennt keinen Configuration Drift, wenn jemand was Manuelles geändert hat, wird es nicht erkannt, es wird einfach weggebügelt. Deswegen, das Mittel der Wahl ist eigentlich Pull. Genau, und zur Pull-Konfiguration, das ist das, was man typischerweise eben genau als GitOps bezeichnet. Man hat nen Service, der läuft im Kubernetes Cluster selbst. Also nen Docker Container, der im Cluster selbst läuft. Und der guckt einfach die ganze Zeit, was steht in meinem Git und was ist in Kubernetes aktuell am Laufen. Und holt sich die ganze Zeit davon nen Diff. Und wenn jetzt irgendjemand Sonntag, Mittag lustig ist und sagt, ah, ich lösche jetzt den Workload, dann sagt der GitOps Operator so, nein, du hast jetzt zwar mit CubeCtL das Deployment gelöscht, aber in Git steht was anderes. Und dann revertet der Operator instantan diesen Change wieder und rollt zurück zu dem, was in Git steht. Hat natürlich den Nachteil, dass jetzt das Kubernetes Cluster auch Zugang zu Git braucht. Kann man sich jetzt überlegen im Thread Modeling, welche Variante besser ist, hat das Cluster Zugriff zu Git oder hat Git Zugriff auf das Cluster. So ne Frage, die man sich dabei stellen muss. Einen Tool, was ich dafür sehr empfehle, es gibt natürlich extrem viele, ihr habt die Cloud Native Landscape vorhin gesehen, es gibt sehr viele Tools für alles. Aber das Tool, was ich empfehlen würde und auch persönlich benutze und auch in allen Firmen, für die ich das bisher gemacht habe, benutzt habe, ist eben Argo CD. Argo CD hat halt den Vorteil, dass es ein wirklich, wirklich hübsches UI hat. Ich weiß, klingt total bescheuert, aber ihr glaubt gar nicht, wie sehr sich das Management darüber freut, wenn sie irgendwas angucken können. Wenn sie einfach sich irgendwo anmelden können und dann sehen, ah, alles grün. Top Tier. Der Sports. Genau, Dashboards all the way. Sieht ungefähr so aus, dass hier ist jetzt ne Demo von der Argo CD Webseite, nicht von meinem Cluster. Ihr seht, es gibt einen Service, der ist gelb. Da ist also irgendeine Änderung erkannt worden und sobald man jetzt auf den Synchronize Button klickt, wird das wieder zurückgesungen zu dem, was in Git steht. Hier in dem Beispiel für den Single Purpose von dieser Präsentation hat man hier die Sync Policy auf Manual umgestellt, dass man wirklich manuell diesen Sync Button klicken muss. In dem Production Environment würde man diese Sync Policy eher auf Automatik setzen. Das ist automatisch reconciled. Genau, mach ich direkt weiter. Wenn ihr in eurem Cluster jetzt eure Konfiguration in Git speichert, Entschuldigung, für euer Cluster die Konfiguration in Git speichert, habt ihr sehr oft das Problem, dass ihr auch Passwörter konfigurieren müsst. Zum Beispiel habt ihr die Anwendung, die sich zu einer Postpress-Datenbank verbinden soll. Dafür braucht ihr einen Connection String, der jetzt nicht so unbedingt im Klartext in Git stehen sollte. Für Secret Management gibt es mehrere Solutions. Es gibt sowas wie Bitnami Seal Secrets, sind ein bisschen umständlich zu benutzen. Es gibt auch verschiedene Integration zu Cloud Providern wie zu Azure Key Vault oder AWS Key Vault. Secret Management, Secret Store. AWS Secret Store heißt das Ding. Kann man machen es aber auch wieder so ein bisschen aufwendiger zu konfigurieren. In den allermeisten Fällen benutzt man eins von diesen beiden Tools hier. Git Crypt ist ein bisschen älter, würde ich heute für ein neues Projekt nicht mehr verwenden. Funktioniert halt basiert auf GPG und encryptet immer die ganze Datei. Funktioniert super, kann man machen. Dann hat man halt kein Git-Diff mehr. Ihr verändert irgendwas an eurem Secret in eurem Helm-Values-Yaml, aber ihr könnt es nicht mehr diffen. Pull Request-Reviews sind ziemlich schwierig zu tun. Wie gesagt, funktioniert zwar würde ich aber nicht mehr empfehlen. Viel, viel besser ist Mozilla SOPS. Funktioniert sehr ähnlich zu der Ansible Key Vault. Man hat einen YAML-File und encryptet immer nur den Value. Der Key bleibt statisch und sichtbar. Und man kann auch in der SOPS-Konfiguration ansagen, welche Keys oder den Rack-X oder den JSON-Parf zu dem Value, was encryptet werden soll. Und dann hat man seinen komplettes Value YAML unencrypted und nur wirklich das eine Secret ist encryptet. Sieht ungefähr so aus. Man hat seinen YAML ganz normal, wie man das mit Kubernetes schon gewohnt ist. Und wirklich nur das Value ist encryptet. Vorteil von SOPS gegenüber GitCrypt ist auch es ist nicht ausschließlich PGP basiert, sondern man kann auch so moderne Kryptotechniken wie Age Keys benutzen. Sehr viel einfacher zu im Handling. Genau. Und ja, jetzt haben wir quasi unser Cluster. Unsere Applikationen laufen. Aber wie kommt eigentlich der Traffic zu den Applikationen? Der flattert ja nicht plötzlich da rein. Deswegen how to serve your application. Die einfachste, simpelste Variante ist einfach so ein Note Port. Das heißt, auf Kubernetes Note ist dann ein Port offen. Und das war es mir oder weniger. Etwas smarter ist es dann, Load Balanced zu verwenden. Und der Big Brain Move ist tatsächlich ein Ingress Controller oder ein vernünftigen. Der Gigabrain Move ist eigentlich, dass man gar keinen Traffic mehr braucht. Das ist dann tatsächlich auch das sicherste, weil wenn kein Traffic bei meiner Applikation ankommt, kann auch keiner irgendwelchen malicious Traffic an meine Applikation schicken. Aber wie gesagt, Easy Mode. Ihr habt so ein Note Port. Auf eurem Kubernetes Note wird plötzlich einfach nur ein Port geöffnet. Der Traffic schlägt auf diesen Port ein. Und das war es mir oder weniger. Hat den Nachteil, ihr habt nur eine relativ kleine Range an Ports und ihr dürft keine Reserve Ports benutzen. Also so eine statische Website einfach mal über Note Port freigeben ist nicht kein Port 80, kein Port 443. Deswegen, der Advanced Mode nutzt ein Load Balancer. Hat den Nachteil, jeder einzelne Load Balancer kostet Geld und zwar nicht nur für seine bloße Existenz, sondern auch für den Traffic, der reinkommt und rausgeht. Dann ist das Zertifikatsmanagement bei dem Cloud Provider vielleicht nicht das, was ihr haben wollt. Vielleicht wollt ihr einen Let's Encrypt Zertifikat nutzen und nicht irgendeine Third Party Firma auch noch für das Zertifikat Geld hinterherwerfen. Aber Cloud Provider sagt, Nö, wir haben hier diese Enterprise CA. Wenn ihr ein Zertifikat wollt, nehmt die Enterprise CA und gebt uns Geld dafür. Das braucht dann natürlich auch noch ein Cloud Provider, der Load Balancer Support hat. Ich bin mir gerade nicht sicher, aber inzwischen glaube ich, hat jeder Cloud Provider Load Balancer Support? Ja, auch Hetzner hat. Und die Hetzner Load Balancer sind mittlerweile tatsächlich sehr gut. Danke, Tobi. Kleiner Nachteil ist, TLS wird normalerweise am Load Balancer terminiert. Das heißt zwischen Load Balancer und eurer Applikation ist der Traffic unverschlüsselt. Kommt dann wieder auf euer Thread Modeling an. Aber das Ganze funktioniert auch tatsächlich nur für Domains und nicht für Pfade. Deswegen, wenn ihr Export Level gehen wollt und wirklich große Workloads habt, benutzt ein Ingress Controller. Ich würde empfehlen Ingress Engine X. Wenn ihr soweit seid, dass ihr das Engine X als Ingress Controller nicht mehr ausreicht und ihr Envoy benutzen müsst, dann seid ihr eh schon soweit, dass ihr ein Production Grade Kubernetes Cluster betreibt mit mehrere Millionen Requests per Second. Und dann habt das Kubernetes Game eigentlich auch schon durchgespielt. Vorteile von einem Ingress Controller sind, es gibt so ein bisschen Domain Auto Discovery. Zertifikate können automatisiert beantragt und auch direkt angewendet werden. Das heißt, wenn ihr eine neue Applikation mit einer neuen Domain oder Subdomain deployet, kann sich eurer Ingress Controller direkt auch selber ums Zertifikat kümmern. Das Ganze ist wirklich High Performance. Also so der Standard Ingress Engine X, selbst auf einem Raspberry Pi, glaube ich, 5-10.000 Requests per Second auf einem Pi 4. Und das Ganze funktioniert auch mit URL-Pfaden. Das ist wirklich so the way to go by größeren Clustern. Aber das ist halt auch, die erste Einrichtung ist nicht unbedingt trivial. Was ich noch dazu sagen möchte zu diesem Unterschied von Works on Paths and Works on URLs. Der Unterschied ist da einfach, ihr habt in eurem Kubernetes vielleicht verschiedene Anwendungen, verschiedene Microservices. Und wenn ihr jetzt einen Service Type Load Balance habt, der nur mit Domains klar kommt, dann ist jeder Microservice mit einer Subdomain angesprochen. Dann hat man subdomain1.example.com, während wenn man ein Ingress Controller benutzt, dann kann ich auch Regeln definieren, dass verschiedene URL-Pfade zu verschiedenen Anwendungen zu verschiedenen Microservices geroutet wird. Ist wirklich sehr praktisch, vor allem wenn man Anwendungen skaliert. Oder wenn man seine API als Micro Controller Microservices implementiert und jeder API-Pfaden einen eigenen Microservice bekommt. Ja, dann sind wir auch schon soweit. Vielen Dank euch allen fürs Zuhören. Und wenn ihr Fragen habt, bewerft uns mit Fragen. Wir haben noch 15 Minuten Zeit für Fragen. Erst mal den Applaus, den habt ihr euch verdient. Wir haben 15 Minuten, was subdomain derzeit Fragen, Hände hoch. Ich komme zu euch. Ich fange hier an. Hi, erstmal danke für den spannenden Talk. Ich habe noch eine Frage zu Load Balance an und dass man da nicht anhand von URL-Paths bestimmen kann, wo der Traffic hin soll, ist das bei den großen Cloud-Providern wirklich, also ist es da so, weil ich kenne das von HAA-Proxy zum Beispiel so, ich habe bei mir selber einen Einsatz, dass es überhaupt kein Problem ist, das so einsetzen. Ist es einfach eine Limitierung von den Cloud-Providern? Ja, darf ich. Also wenn wir auf dieses Slide gehen, ups, da sind wir schon. Also das Problem ist dabei, dass der Traffic an den Load Balancer kommt und der Load Balancer gibt das an den Kubernetes Service Objekt weiter und vom Service Objekt wird es dann an den Pod geroutet und der Service wiederum ist immer auf eine Subdomain. Ach so, okay, danke. Kein Problem. Auf welchem Networking Level oder welchem Level ist, wenn man die Gateway API verwendet? Die Gateway API, sagt ihr wie was? Nein, gerade nicht. Hab ich bisher noch nicht benutzt, sorry. Okay. Was hat sich bisher bei Kubernetes als Shared Storage am meisten bewährt? Minio für S3 Storage. Am besten ist tatsächlich, werft eure Sachen in irgendwas S3-kompatibles, speichert es da, ist so der eigentlich optimale, die optimale Storage-Class für das Meister. Devo, linke Publikumsite, wo war die Frage? Hände hoch. Hier vorne, ja? Ach, wieder falsch. Im Mittelgang, leider. Im Mittelgang, verbannt. So komme ich mir nix und nix auf meine Schritte. Ja, was ich bisher als Ingress-Controller benutzt habe, war halt eher auf Traffic. Warum kam das jetzt nicht? Das war eigentlich auch recht bequem. Es ist bequem, aber es macht Dinge nicht unbedingt nach der Standarddefinition nach. In Traffic ganz speziell. Traffic hat ein leicht anderes Konzept, wie Ingress funktioniert. Traffic wurde ursprünglich mal für Docker nativ entwickelt und man hat bei Traffic ja dieses Konzept von Routen und diese Routen sind einfach kein Standard in Kubernetes. In Kubernetes hat man sich geeinigt, dass man diese Ingress-Classes hat und Ingress-Objekte hat. Und wenn ich jetzt so ein Ingress-Objekt als Definitionen speichere in meinem LCD und dann irgendwann beschließe ich meinen Ingress-Engine X aus mir nicht mehr skalierbar genug, ich möchte zu Envoy wechseln, dann kann Envoy direkt nativ dieses Ingress-Objekt wiederlesen, weil es ein Standard Kubernetes-Objekt ist. Wenn ich jetzt aber anstelle dessen Traffic benutzen würde, dann hätte ich eine Custom-Resource mit dem Traffic-Pfad und dann ist die Migration zu einem anderen Ingress-Service nicht mehr ganz so einfach. Funktioniert auch wirklich gut, ich glaube Heiko, du benutztest sogar in deinem Kubernetes-Cluster auch. Wir haben ein Home-Cluster, da sitzt so ein Traffic davor, aber tatsächlich das Cluster, was bei mir bei Hetzna läuft, da ist ein Ingress-Engine X davor. Ich finde das schön, wenn die Fragen herrlich optimiert schon Fahrtwiese kommen. Ist das das Perling-Salesman-Problem angewendet auf Leihra? Danke nochmal für den Talk, hat mir ein paar Eindrucke gebracht. Ich stelle mir noch die Frage, ich habe ein Proxmox-Cluster mit mehreren Hostdörfern und ein Cef-Cluster drunter und es kamen die Anforderungen, wir wollen Kubernetes machen. Macht das Sinn, das als VMs in den Proxmox-Cluster zu machen oder ist es besser eigene Hardware zu nehmen? Was ist da so die Empfehlung? Und auch das Storage würde ich dann den Cef von dem Host einfach mit benutzen, statt in der VM nochmal eine Storage-Schlösung reinzubauen. Also tatsächlich, wenn du schon Cef als Storage hast, nimm es, es ist meiner Meinung nach eine gute Idee und tatsächlich auch die Kubernetes-Notes auf dem Proxmox aufzubauen, würde ich jetzt sagen, wenn du nicht wirklich heiß Performance Kubernetes brauchst, spricht eigentlich nichts dagegen. An der Stelle auch gesagt, es kommt ein bisschen auf die Performance Requirements an. Wenn du jetzt wirklich alles High Performance möglichst nah an der Hardware möchtest, dann klar an einem Bare Metal Kubernetes. Ansonsten die Proxmox VMs funktionieren sehr gut. Ich habe auch einen Intel NUC zu Hause mit Proxmox drauf, wo ich auch ein paar Kubernetes Worker-Notes drauf habe. Funktioniert. Und Cef als Storage-Provider sehr gut, kann ich auch empfehlen, habe ich für meine Persistent-Volumes im Home Lab auch. Bare Metal Kubernetes, das ist dann schon große Leidensfähigkeit, oder? Ja. Dann noch eine Frage zu Proxmox. Gibt es da für ein Case-Racer der KLS-Deployment irgendein Skript oder Terraform oder irgendwas in der Art? Bin ich mir gerade nicht sicher. Ich würde vermuten, dass es da zumindest In-Ansible was gibt, wo man einfach nur quasi seinen Proxmox-Host angibt und sein Playbook dagegen wirft und dann sollte eigentlich was entstehen. Aber ich persönlich habe tatsächlich mit Proxmox nicht so viel gearbeitet. Wie gesagt, mein Home Lab ist True-Nas-Scale und das wäre erst mal abschreckend genug, gerade weil die Community da schnell sehr toxisch wird und man vom Community-Support nur einen Kopf geworfen bekommt. Gehe auf unseren Discord-Server und durchsuche unseren Discord-Server nach der schon gestellten Frage. Vielleicht findest du die Antwort. Wir haben sie schon mal irgendwann beantwortet. Was ich dir für Proxmox empfehlen kann, ich muss die Slite nur noch mal finden, die war relativ vom Anfang leider. Tut mir leid. Ich hätte einfach die Präsentation neu starten sollen. Guck dir hier auf der CNCF-Landscape, L.CNCF.io. Hier gibt es eine Kategorie, die heißt Installer. Da findest du alle möglichen Kubernetes-Installer und die werden dir in ihrer Doku vermutlich sagen, ob sie zu Proxmox kompatibel sind. Vermutlich sowas wie K-Ops oder Q1. Nächste Frage. Ich kenne ja Entscheidungsdiagramme, vielleicht sehr bekannt, das brauche ich an dem Blockchain und so einen Pfeil. Nein. Die gesamte Präsentation war ja quasi ein Entscheidungsdiagramm. Habt ihr da Sourcen, wo sowas ein bisschen runtergebrochen ist und jetzt eine Stunde Video zu gucken oder ist das alles jetzt gewachsen über fünf bis zehn Jahre im Business? Viel ist tatsächlich leider Erfahrung. Ich versuche, danke für den Anreiz, ich versuche das mal in den Blog-Post zu fassen. Ich glaube, letzte Frage oder? Ja, ich habe noch eine Frage. Wie sieht es mit so fertigen Kubernetes-Lösungen aus, sowas wie VMWare Tansu oder Nutanix? Ist es schon so, was man machen möchte, wenn man wenig Kapazitäten hat oder ist das eher etwas, wovon man abraten würde? Ja, würde ich dazu raten. Also, VMWare kam ja auch in diesen VM-Markt rein und hat das mal in halbwegs sinnvoll, halbwegs benutzbar gebaut und so ähnlich zeichnet es sich gerade mit Kubernetes ab, dass VMWare Tansu tatsächlich auch sehr brauchbar wird. Haben wir jetzt persönlich in die Kategorie Enterprise Kubernetes klassifiziert, weil es dann auch schon ein bisschen kostspieliger ist jetzt nicht so, dass man irgendwo hingeht und sagt drei Mausklicks. Ich habe mein Tansu Cluster, sondern man braucht dann irgendwie eine VMWare Umgebung und braucht NSXT oder NSXV, glaube ich sogar, und dann als Netzwerk, als STN darunter und dann kann man Tansu drauf installieren. Aber dann funktioniert das auch sehr gut und man bekommt sehr, sehr guten Enterprise Support von VMWare dafür. Aber ein Punkt dazu. Es reduziert, es war den Operating Auffahren ein ganzes Stück, aber man hat immer noch Operating Auffahren, also auf null wird man ihn nicht kriegen. Das heißt, wenn man nicht die Kategories für Operation hat, hat man sie halt leider nicht. Weg kriegt man sie auf keinen Fall. Der Nachteil an so etwas wie einem Enterprise, also deshalb haben wir das so in Enterprise Kubernetes klassifiziert. Man lockt sich so ein bisschen in so ein Ökosystem rein. Also wenn man jetzt den Weg vor VMWare Tansu geht, dann ist man so in so einem VMWare Ökosystem. Man kann den Weg OpenShift gehen, dann ist man halt in diesem OpenShift Ökosystem. Endlich sieht es mit Ransher aus. Man kann Ransher Kubernetes benutzen, aber ist dann halt in diesem RKE Ransher Ökosystem so ein bisschen in so einem Vaultgarten gefangen. Wenn ich da vielleicht noch kurz anschließen darf, ich sage meinen Kunden dann immer, betrachte Kubernetes als ein zusätzliches Operating System. Wie viele Menschen hast du um Windows, Linux, OS2, whatever, AX, S360 zu managen? Bist du bereit, das auch für Kubernetes in die Hand zu nehmen? Und bitte, for whatever is holy to you, niemals Vanilla Kubernetes in Produktion. Bitte! Wir haben noch ein paar Minuten, die Jungs waren ein bisschen flotter. Jetzt habt ihr noch geschossen. Ja, natürlich ganz diagonal am anderen Ende. Danke. Busse! Powering Interview wäre mal durchgefallen beim Traveling Salesman Problem. Wir hatten es ja eben mit den Microservices. Ich habe meine Microservice Architektur gesehen. Das war ein VMWare ESX Cluster. Da liefen VMs drin, jeder Windows Server auf jedem ein Web-Logic und darin lief dann der Microservice. Was werden die maximal overblown, over-engineered Architektur, die ihr euch für Kubernetes vorstellen könntet? Das klingt extrem gut nach einem Use Case, der wirklich excellent mit Kubernetes abzufrüstigen wäre. Mein Beileid, dass du das mit Firemware sehen musst. Ja, aber man könnte doch so den Kubernetes Cluster in einem Linux-Subsystem unter Windows in einer... Fragen? Wir haben hier zwei Servic... Ja, danke. Ich komme. Ich hatte es schon, dass die Anforderungen kamen. Bau uns mal bitte eine Red Hat Enterprise LinuxVM auf einem Hyper-V und auf dieser LinuxVM auf dem Hyper-V möchten wir bitte Container-Orchesterierung haben für ein Stoner-Cube. Musste ich mich schon darum kümmern. Ich habe es dann doch noch geschafft, die Leute dazu zu überreden, dass wenigstens auf einem VMWare Cluster laufen zu lassen und nicht auf einem Hyper-V. Danke für den Talk. Ihr habt Docker Swarm erwähnt, aber eher so, dass es Mee ist. Was sind denn von eurer Seite die Schwächen oder wieso sollte man jetzt nicht eher Docker Swarm benutzen, wenn man, sag ich mal, 10 Microsofts nur hat? Von meiner Seite aus, ich gehe halt langsam wirklich weg von Docker, einfach weil sie sehr, sehr Enterprise sich schiften momentan und vieles nur noch für Enterprise-Kunden anbieten gegen Geld, wo sie früher free and open-source waren, mit so meinen Grund wegzugehen langsam von Docker. Wie sieht es bei dir aus, Cedi? Ja, ich überlege gerade, wie ich das am besten rüberbringe. Es ist nicht so, dass Docker Swarm scheiße ist. Es ist per se kein schlechtes Tool. Es tut den Job, den es tut sehr gut. Aber wenn ich jetzt dabei bin, mich in einen neuen Container-Orchesterator einzuarbeiten, dann muss ich ja auch so eine Entscheidung treffen, wie lange möchte ich das denn supporten. Und wenn ich so perspektivisch mir das mal in die Zukunft blicke, dann gibt es eine sehr kleine Community, die Docker Swarm benutzt und es gibt halt diese Community, die Kubernetes benutzt und dann sind die Ressourcen für Kubernetes vielleicht ein bisschen besser und es ist vielleicht perspektivisch gesehen auch ein bisschen besser, Leute zu finden, die Kubernetes können. Wenn ich irgendwie neue Leute einstellen muss, dann kann ich sagen Kubernetes bitte und dann kommen zehn Bewerber. Wenn ich das selber mit Docker Swarm mache, sieht es eng aus, dann kommen Leute, die schon mal Docker bzw. Docker-Compose benutzt haben und muss die dann noch on the job erst dafür trainieren, Docker Swarm zu benutzen. Und damit sind wir am Ende unserer Zeit vielen, vielen herzlichen Dank und noch mal einen großen Applaus für Heiko und Cedi.