Einfach Komplex – Der Software- und IT-Podcast· Folge 72

Kubernetes mit Mario Fahlandt von Kubermatic #72

Dienstag, 3. Dezember 2024 · 1 h 18

MP3

Shownotes

Das Open-Source-Tool Kubernetes hat die Orchestrierung von Containern revolutioniert. Zu Gast ist Mario Fahlandt, Customer Delivery Architect bei Kubermatic und aktiver Contributor im Kubernetes-Projekt. Mario bringt seine langjährige Erfahrung und tiefes Verständnis für Kubernetes mit und gibt uns wertvolle Einblicke in die Welt der Container-Orchestrierung.
Kubernetes ist eine Open-Source-Plattform zur Automatisierung von Bereitstellung, Skalierung und Betrieb von Container-Anwendungen. Initial entwickelt von Google, wurde es 2014 der Open-Source-Community übergeben und hat sich seitdem zu einem der wichtigsten Werkzeuge im Bereich Cloud-Native-Computing entwickelt. Es ermöglicht Unternehmen, Anwendungen flexibel und effizient über eine Vielzahl von Umgebungen hinweg zu betreiben – sei es in der Cloud, On-Premises oder in hybriden Architekturen.
In der heutigen Softwareentwicklung ist es entscheidend, Anwendungen flexibel und skalierbar zu gestalten. Genau hier setzt Kubernetes an: Es sorgt dafür, dass Container-Anwendungen zuverlässig laufen und sich bei Bedarf automatisch skalieren lassen. Außerdem reduziert Kubernetes den manuellen Aufwand bei der Verwaltung von Containern, was es besonders für komplexe und dynamische IT-Umgebungen unverzichtbar macht. Dank Features wie Self-Healing, automatischem Rollback und Load-Balancing ist es inzwischen das De-facto-Standard-Tool für moderne IT-Infrastrukturen.

SHOWNOTES

Was macht Kubermatic?
Kubermatic ist ein führender Anbieter von Kubernetes-basierter Automatisierungssoftware, die Unternehmen hilft, ihre Container-Infrastrukturen effizient zu verwalten. Kubermatic bietet Lösungen, um Kubernetes über Multi-Cloud- und On-Premise-Umgebungen hinweg zu orchestrieren, was die Verwaltung von großen, verteilten Systemen erheblich vereinfacht.
Kubernetes Website: kubernetes.io
Kubermatic Website: de.kubermatic.com
Mario auf LInkedIn: linkedin.com/in/mfahlandt
Mario auf X: twitter.com/mfahlandt
Mario auf Bluesky: bsky.app/profile/did:plc:5ebvf4dmedjr2hgxehbvy…

Einfach Komplex ist ein Podcast von Heisenware. Alle Infos und Kontakte findest du im Linktree:
⁠⁠⁠⁠⁠linktr.ee/heisenware⁠⁠⁠ (linktr.ee/heisenware)

Mario, Dr. Burkhard Heisen⁠ (linkedin.com/in/burkhard-heisen) und ⁠Gerrit Meyer⁠ (linkedin.com/in/gerrit-meyer) sprechen heute über:
() Intro Mario & Kubermatic
() Überblick – Warum Kubernetes?
() Komponenten & Architektur eines Clusters
() Abläufe und Traffic im Cluster
() Datenhaltung / Storage im Cluster
() Recap Technik
() Anwendungsfälle
() Wann Kubernetes verwenden?
() Community & Contributors
() Helm & Helm Charts
() Mit Kubernetes starten

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Moin und herzlich Willkommen zu einfach komplex. Ich bin's, der Gerrit der Burkhard ist auch da, mein Burkhard. Moin Moin. Und wir haben uns wieder Verstärkung geholt zum Thema Cubanetis weil das ist ganz schön komplex und genauso relevant und deswegen haben wir den Mario von Cubamatic da. Mario Moin ja. Moin, schön hier zu sein.

Ja, schön, dass du da bist, Mario. Wer bist du denn eigentlich und was machst du und was macht dich dann zum covernities Experten? Ich bin Mario, bin seit mehreren Jahren in diesem ganzen Cloud native Umfeld unterwegs. Also das hat irgendwann mal angefangen mit irgendwelchen End skripten um dann irgendwelche Server aufzusetzen, ist dann dazu übergegangen, dass dann irgendwann mal Docker gekommen ist und dann irgendwie ein Adobe s.

Hier die die die ersten. Auch Lambda Lambda Sachen dann damals gebaut und dann gab es dann irgendwann bin ich mal in so ein Startup reingekommen und die wollten dann die hatten Credits bekommen von Google und Google hat dann GKI gelauncht, also in irgendwie 1.0 damals also die Google Communities Engine und dann habe ich mir gedacht Boah unsere ganzen Microservices eh die da auf irgendwelchen VM s rumgammeln, dann schieben wir das ganze mal irgendwie in die.

In dieses neue Ding, was da Covonitis heißt, das hat ziemlich gut funktioniert. Da hab ich dann Meetup gestartet in München und das ging dann eben so weiter und mittlerweile bin ich einen. Contribute zu Cubonatis bin auch da. An der org bin da der Tech Lead für das Cubonatis Contrip ex coms, also die die das Subproject von der Special Interest Group und mache auch so ein bisschen Cost Reporting für das Cubonatis Projekt und genau wie du schon gesagt hast, arbeite ich eben für Cubonatic und ich glaube mehr als cubonatic kann man glaube ich schon fast nicht mit Cubonatis machen.

Es so OK. Danke mal für die für die Vorstellung. Ich könnte jetzt schon wieder ehrlich gesagt 5 nachfragen stellen, das speichern wir jetzt mal. Aber trotzdem lass doch noch mal reingehen, ganz kurz, warum ist denn jetzt also was macht denn jetzt kubanatik genau und wie wie es da der Zusammenhang zu zu kubanet ist. Kannst du das noch mal ganz kurz zusammenfassend für uns. Also wir sind im Endeffekt sind wir ne produktfirma, Wir haben unseren Sitz im schönen Hamburg, wobei man aber sagen muss, dass der Großteil der Welt der Leute irgendwie quer verteilt über die Welt sitzen, also.

Ich sitze zum Beispiel im letzten Haus vor der tschechischen Grenze im Norden von Bayern, also quasi ganz, ganz am Rand. Das Gute ist, ich habe wenigstens Glasfaser, das Macht die Sache einfacher, und cubomatic ist im Endeffekt eine Firma, Wir haben ein Produkt, das ist ein Multi Cluster Multi Environment cubonitis Manager, also wenn du quasi cubonitis Cluster erzeugen möchtest in den verschiedenen Umgebungen wie in der Cloud, Onpram of Edge in Edge Umgebung. Dann kannst du es eben mit unserer einer von unseren Produkten eben machen und das Gute da dran ist, wir lassen Cobonatis und Cobonatis laufen um das Ganze schon mal einfacher zu machen.

Wie das funktioniert würde jetzt glaub ich n bisschen zu weit führen, ansonsten sind wir auch der Top contribute zum cobonatis Projekt in Europa, also das was wirklich so Leute die dann aktiv contributen. Da sind wir, wenn man nach Defsets geht, von der CNCF eben auf Platz 1. Wenn man nur Europa betrachtet. Ja, also das ist so, so der Hintergrund, wir haben noch ne Virtualisierung, die also die n bisschen auf Cubonatis läuft, wir haben noch nen developer Portal was auf cubonatis like APIS basiert, also wie ihr schon seht alles so n bisschen alles alles cubonatis also.

Quasi von von ganz unten bis ganz oben bauen wir den ganzen Stack auf Corbinitis auf, wollen. Wir vielleicht mal so starten, dass du uns corbinitis einmal kurz einordnest. Ich glaub, dann ist das alles n bisschen einfacher zu verstehen und vielleicht sogar so, dass Menschen wie ich das halbwegs verstehen können.

Ja oder vielleicht sogar Leute, die noch nie von Corbinitis gehört haben. Und ich hab dabei ne Idee, das weiß der Mario nicht. Wir hatten ja aber schon mal ne Folge über Docker und Container und so weiter sogar 2 glaub ich. Und vielleicht, wenn du es nicht magst, Mario, dann sagst du, bäh, kein Bock auf das Bild, aber wir haben ja, ich habe mal so gesagt, Naja, diese Docker Container und das ist ja auch das Bild von also das Logo von Docker selber, da kann man sich irgendwie so ein Schiff vorstellen, da sind halt die Container drauf warum Container weil es quasi standardisierte Entitäten sind, in denen beliebige Software gut standardisiert laufen kann. Es hat dann immer jeder Container sorgt quasi für die richtige Umgebung der richtigen

Anwendung und das Wort Microservice noch mal kurz ins Bild gesetzt. Eine ganze Anwendung wäre dann quasi nicht ein Container, sondern mehrere Container. Ich sag mal was 1015 oder irgendsowas ja, die zusammen dann ja, jeder Container macht einen kleinen Teilaspekt, da läuft quasi im Prinzip schon eine kleine Anwendung drin, die haben dann aber irgendwelche standardisierten Konnektivitäten miteinander und dann haben wir die ausführbare Hardware und da könnte man sagen, ich sag mal so ganz locker ist so der Frachter ja das Schiff quasi, auf dem die Container sind und das schicke ist von. Von Docca ja, dass du das Schiff austauschen kannst. Ja, also die Container sind halt standardisiert und die passen halt auf verschiedene Schiffe

raus, also auf verschiedene Hardware und wenn ich es jetzt ganz grob verstehe und jetzt bist du gleich dran, dann ist quasi das kubanetis Level ist quasi so während wenn wenn wir über Docca sprechen so und ein Schiff nachdenken, dann ist kubanetis irgendwie der globale Welthandel aller Schiffe und aller Container und so weiter und so auf dem Abstraktionslevel, oder? Hast du Bock, auf das Bild einzusteigen? Ich weiß es nicht, das.

Witzige, das Witzige ist, das Bild wird eigentlich relativ oft hergenommen, weil es halt ein bisschen greifbarer ist für die meisten und die wenigsten wissen, dass Kubanetes tatsächlich aus dem Griechischen stammt und Steuermann heißt. Also dann bist du eben mit dem ja mit dem Containerschiff gar nicht mal so weit weg. Du musst dir das Ganze eben so vorstellen, du hattest ja schon gesagt.

Ihr habt eben diese ganzen Dockercontainer und die meisten haben halt irgendwie vielleicht auch schon mal in ihrer Umgebung nen Dockercompost gemacht. Ne, dass das halt du du hast die einzelnen Container, damit diese Container irgendwie. Ne, sag mal jetzt mal du du baust n Auto und in dem einen Containerschiff ist irgendwie motorkomponenten drin in dem anderen Containerschiff in dem anderen Container sind Türen mit drin und du brauchst im Endeffekt um das Auto zu bauen brauchst du Sachen aus allen Containern im Endeffekt klar das kannst du im kleinen Rahmen kannst du das machen irgendwie wenn ich nen Docker compose auf einer VM aufbaue dann funktioniert das auch ganz gut, aber sobald das eben in die

Größe geht und skalieren soll. Dann reicht dir das eben nicht mehr und Cubonetis kümmert sich so n bisschen wie beim Containerschiff eben drumherum, dass eben das von A nach B erstmal kommt. Aber um vielleicht das so n bisschen wegzubringen von dem Containerschiff Cubonetis kümmert sich auch da drum, dass jetzt gehen wir vielleicht mal irgendwie an so n an so n Container Office ne, also so n Schiffscontainer Office hin, dass du ne steckdosenleiste hast, dass da in jedem Container Strom drin liegt, dass da irgendwie. Türen mit drin sind, dass da jeder mit nicht jeder mit jedem reden kann.

Aber damit da zumindestens irgendwie theoretisch jemand durch die Tür gehen kann und von A nach B reden kann und eben, dass sich da drum gekümmert wird, dass wenn ich zum Beispiel irgendwie ne Brücke hab zwischen 2 containertürmen, weil die Containertürme auf der einen Seite vielleicht sind, eben auf der einen Note und die Containertürme auf der anderen Seite sind eben auf der anderen Note, also es ist so n bisschen, auch weil wir ja auch. An die Größe denken und an die Skalierbarkeit denken, weil Incubonatis Klasse funktioniert nicht mit einer mit einer VM. Also also du kannst es mit laufen lassen, aber das ist nicht Sinn und Zweck der ganzen Sache, sondern Cubonatis ist dafür da, dass ich eben mehrere

Server miteinander laufen lasse und das Gute an Cubonatis ist, dass es eben einfach so einen standardisierten Baukasten im Endeffekt mit sich bringt, die dir einfach ganz viele Sachen in Orchestrierung auch abnimmt, also was zum Beispiel auch sagt so. Zum Beispiel, wenn wir jetzt irgendwie auf das Auto, auf das Autobau Ding wieder zurückgehen.

Ich brauch vielleicht 4 Container, wo Türen drin liegen, weil ich halt 4 Türen an meinem Auto brauch, dann kann aber das ist ja viermal die gleiche zweimal 2, also 2 linke Türen, 2 rechte Türen und das heißt aber ich muss quasi die gleichzeitig laufen lassen und vielleicht, das kommt so in die Richtung hin, was dann auch kombiniertes eben übernehmen kann.

Ich finde diese Bilder, die er gemacht hat und gerade aufgemacht hat und ein Bild vermixt habt gut, aber ich würde mich trotzdem freuen, wenn wir es noch mal ruhig auch ohne einen Vergleich oder eine Metapher oder ein Bild erklären können. Ja, also was ist es, es ist Orchestrierung von Containern, habe ich jetzt verstanden, es ist die Möglichkeit verschiedene auf verschiedenen Servern vielleicht die gleiche Anwendung laufen zu lassen oder Teile dieser Anwendung und trotzdem dafür zu sorgen.

Dass immer das Richtige ausgeliefert wird oder vielleicht noch mal ganz kurz zusammenfassen, also Kubanitis welches Problem hab ich eigentlich als Firma, damit ich kubanitis einführe? Also das Problem, dass du als Firma hast ist, du hast Software, die du in deiner Umgebung laufen lassen möchtest, die eben in der Regel basierend auf Microservices ist. Das heißt ich hab sehr sehr viele verschiedene Software Pakete, die gleichzeitig laufen müssen. Die müssen unterschiedlich skaliert sein, und das heißt, ich muss von dem einen brauche ich 5 Instanzen, von dem anderen brauche ich 3 Instanzen, von dem vierten brauche ich vielleicht nur eine Instanz, und das habe ich alles in Containern und Cubonetis baut dir die die

Plattform, wo das ganze drauf läuft und kümmert sich eben auch darum, dass ich eben Sachen in dieser Plattform skalieren kann und dass ich das Ganze eben über mehrere Server automatisiert ausrollen kann und cubonetis kann dir auch dabei helfen, eben die. Installation oder die Vorbereitung dieser Nodes mit zu übernehmen, das sind dann eben Teilkomponenten in Cobonatis, die dann eben sagen, hey, ich brauch ne neue Node, dann wird ne neue Node hinzugefügt und da werden bestimmte Sachen schon rein installiert, dass quasi Node einfach nur als Arbeitstier unten drunter gelegt wird und dann kümmert sich Cobonatis da drum, welche Workload kommt, wohin basierend auf der den Requirements den sie hat.

Also ich brauch. 0,2 CPU und 500 Megabyte RAM und dann schaut eben Cubonetes auf welcher Note habe ich jetzt noch 0,2 CPU und 500 Megabyte RAM um eben meine Applikation dann dahin zu packen und dann übernimmt das das für dich. Da muss man sich auf der Zunge zergehen lassen. Das sind so leichtgewichtige Aussagen wie, ich habe verschiedene Skalierungsanforderungen von hier brauche ich irgendwie 3 Instanzen von dem 5 Instanzen, ich bring noch mal kurz ein bisschen Licht rein, was das heißt, das heißt? Und du korrigierst mich, Mario, ich bin. Deswegen haben wir dich hier als Gast. Bin auf jeden Fall kein kybernetis Experte. Ich sollte vielleicht irgendwann mal werden, aber ich fange ja gerade an zu üben, aber

Instanzen mehrere Instanzen, also es ist ja oft webtechnologie oder eigentlich auch schließlich webtechnologie. Gut, wenn wir auf der Edge sind und nicht aber so, und jetzt sagen wir mal du hast eine Anfrage gegen einen Server also Gerrit sitzt vor seinem Browser und ich sitze vor meinem Browser und wir wählen quasi die gleiche Domain an die gleiche URL, das heißt noch nicht. Für denjenigen, der die Anwendung zur Verfügung stellt, dass unsere Anfrage des Browsers, also Gerrit und meine, von der gleichen Stück Hardware und noch nicht mal der gleichen Anwendung irgendwie beantwortet wird. Das meint glaube ich Skalierung.

Also es kann halt sein, dass Kybernetis quasi wegen Lastausgleich und so weiter den Gerrit auf eine sogenannte VM oder auf eine Note, Ich glaube das ist das richtige Wort, auf eine Note Lite weiterleitet, die die gleiche Anwendung ausführt. Wie meine Anfrage. Aber ich bin auch in einer anderen Note. Ja, das heißt, ich habe quasi Spiegel mehrere Instanzen von gespiegelten Anwendungen.

Ja, und wenn wir in der Rest API Welt sind, dann haben wir auch schon mal gelernt in einem Podcast, dass diese ganzen Anfragen, dass ich quasi alles mit der Anfrage mitschicke, um auch eine Antwort zu bekommen, das heißt, das enabled quasi erstmal, dass ich überhaupt mehrere Instanzen haben kann.

Ja, die verschiedene Fragen zu verschiedenen Momenten beantworten und Requests und Replics quasi da rausgehen. Genau. Und was du auch noch bedenken musst, und das ist ja das Spannende daran, vor allen Dingen, wenn du auf Webapplikationsbasis bist, du machst ja nicht nur eine Anfrage, du willst ja quasi ne, also Webseite, du loggst dich irgendwo ein, das heißt du hast dich ja irgendwo authentifiziert und dann heißt es ja trotzdem, dass du mit deiner Anfrage am Ende wieder auf der gleichen Maschine ankommen musst. Wenn die zweite Anfrage gestellt ist, weil auf der anderen Maschine bist du ja gar nicht authentifiziert im Zweifel. Und genau das ist eben auch die Schwierigkeit da drin, dass eben Cobonatis beim Networking dann

eben auch so weit hergehen kann und sagen kann, Hey, die Anfrage von dem geht auf die Note wieder, weil ich eben eine Sticky Session zum Beispiel habe, damit ich genau weiß, wo war der vorher, damit ich mich nicht jedes Mal wieder neu einloggen kann, wenn ich kein zentrales Management habe für zum Beispiel Sessions und genau so was kann eben cobonatis auch mithelfen und es kümmert sich eben auch um das Network Routing, dass das eben passiert. Was passiert in meinem Cluster damit? Die Anfrage, die dann irgendwo reinkommt, also ne in dem Fall im kubonitis Bereich ist das halt meistens ein Ingress oder ein No Balancer und dann, dass dass die von da aus Losläuft und dann durch dieses Netzwerkkonstrukt in dem Kubonitis Cluster dann da

ankommt, wo eben deine Applikation in dem Kubonitis Cluster liegt und die Antwort dann auch wieder zurückgespielt wird. Jetzt habt ihr beide, glaube ich das Wort oder vor allem Du, Mario Cluster und Notes benutzt. Was sind so die Begriffe, die wir kennen müssen? Also Notes habe ich jetzt verstanden, sind eigentlich Server. Ne Sammelsurium aus Komponenten ist quasi der Cluster. Also alles alles.

Am Ende ist. Der Kubiniert ist Cluster so und der besteht aus verschiedenen Maschinen. Diese Maschinen sind Notes und es gibt 2 verschiedene Typen von Notes. Es gibt einmal das ist sozusagen das Gehirn. Des Clusters, das ist die sogenannte Control plane in der Control plane. Das sind eben, da liegen die wichtigen Komponenten von meinem Cluster, also man kann sich das so ein bisschen, und jetzt muss man das die Neuartige, die neue Terminierung benutzen, also quasi so ein bisschen remain und also remain Notes.

Und halt wie abhängig abhängig Nodes davon. Also worker im Endeffekt also Main und Worker gibt es da im Endeffekt. Du bist auf den neuen Begriffen für Master Slave, ich nenn das mal g. Ja, weil ich das nicht so schlimm finde, weil das ja n technisch stehender Begriff in der langen Vergangenheit ist.

Aber ja genau, es kann sein, dass unsere Zuhörer das Master Slave schon mal gehört haben, aber bei bei Main und Worker noch n bisschen verwirrt sind, ja. Main und worker OK. Genau, also Master ist im Endeffekt dann eben die Controlplane und da gibt es dann auch wieder verschiedene Möglichkeiten um das ganze Hoch verfügbar zu machen. Also hoch verfügbar.

Also theoretisch kann ich n coponetis Clusters starten mit einer controlplane Note, aber damit das ganze Halt hoch verfügbar ist, nehm ich normalerweise 3. Damit ich halt, wenn eine, wenn eine ausfällt, dass trotzdem das ganze noch funktioniert. Auf dieser Control plane also auf diesen 3 Nodes, wenn wir, wenn wir quasi in einem Hochverfügbarkeitsumfeld sind, hab ich eben die verschiedenen Komponenten die den componitis Cluster managen, das heißt zum einen hab ich den API Server der API Server, also.

Kommuniert ist hat eben auch ein API Server und da werden die ganzen Anfragen abgehandelt und das ist auch die Schnittstelle zur Verwaltung des Clusters. Läuft eben über den API Server, was das Ganze natürlich ganz sympathisch macht, weil dieses API Thema kennen halt viele Entwickler schon aus ihrer aus ihrer Vergangenheit, dann haben wir in diesem Control Plank Komponenten noch den Skatuler der Skatuler ist im Endeffekt das, der schaut nach, das kann man sich so ein bisschen vorstellen wie der. Das ist der, der am am am Morgen in der Arbeit sagt du, du gehst jetzt auf die Baustelle, du gehst jetzt auf die andere Baustelle und der im Prinzip entscheidet, wo werden meine Arbeitslasten in Zukunft hin

verteilt, also wo ist noch Platz, wo kann ich sozusagen meine mein Container, der irgendwo hin muss noch hin packen und der kümmert sich so ein bisschen darum, dass er eben oft nachschaut, so was für Ressourcen braucht dieses eine Komponente und wo gibt es eben noch Ressourcen. Und dann gibt es eben als als nächste Komponente noch den Controller Manager. Der Controller Manager ist im Endeffekt der, der dafür da ist um zu überprüfen ob alles so ist wie es sein soll, also der kümmert sich im Endeffekt einfach erstmal um die Überwachung und die Aufrechterhaltung des gewünschten Zustandes, den ich wie ich gerne meinen Cluster hätte, also wo ich zum Beispiel sage ich. Wie viele Kopien von dieser

einen Applikation sollen laufen oder wo sollen die also wo ist irgendwas kaputt gegangen, der dann eben sagt OK ist jetzt irgendwas kaputt gegangen, dann versuch ich das wieder zu neu neu neu einzutüten und dem Skelett zu Skelchuler zu sagen so hey ich brauch mal wieder n neuen ne neue Komponente die dann gestartet wird. Dann, und das ist nicht also das ist der Standard, aber da gibt es auch Alternativen.

Wir haben eine Key Value Datenbank, weil irgendwo müssen wir unser Zeug auch irgendwie speichern, wo irgendwie der Zustand des Clusters drin steht und standardmäßig ist das Etcd, also das Ding heißt Etcd, das war früher mal ein eigenes Projekt, also ein eigenes Open Source Projekt ist mittlerweile Teil von Cubonetis geworden, ich glaube seit letztes Jahr August ist es wieder Teil von Cubonetis.

Und das ist einfach ein Key bei Justo. Einfach die Datenbank, die in Kubanetis genommen wird. Genau, genau. Weil irgendwo müssen wir ja irgendwo, müssen wir ja die Sachen, die Sachen abarbeiten. Aber das ist wohlgemerkt nur die Datenbank, die den die für die Betreiben des Kubanetis Clusters notwendig ist.

Die hat noch nichts mit der Datenbank mit den Daten der User zu tun, die da kommt jetzt gleich noch, da liegt nämlich der Hase im Pfeffer, glaube ich jedenfalls in meiner Vorstellung immer, das finde ich total kompliziert. Aber wir wollen das einmal noch mal wiederholen. So schön, wie das Gerrit immer macht.

Du hast jetzt gesagt, es gibt die Control plane, das ist quasi die erstmal das Haupteingangstor der Master oder Main in einem neuen Wort und die besteht aus wenn ich richtig gezählt habe 3 Komponenten. 44 API Server Sketuler Controller Manager, etcd und dann noch so ein paar Kleinzeug, was da noch so mit Rumgammelt aber das ist glaube ich nicht so relevant.

Okay so ein HPI HPI Server, der nimmt die Requests entgegen und verteilt die dann hinten irgendwie durch die Gegend und. Dann haben wir den ist soll Geber, der hieß. Der, der ist, soll Geber ist der Controller Manager, der einfach nachschaut wie wie schaut es aus, ist alles in Ordnung und. Dann haben wir noch den Skeluler glaub ich.

Der sagt hier du hast noch was frei, du kannst das da machen und so weiter und dann haben wir quasi die Datenbank die die quasi diese Konfiguration hält, genau quasi was was ich quasi mit dem Curanitis Cluster so vorhabe. Meine meine Präferenzen sind an Skalierung und so weiter ich als softwarebereitsteller sag ich mal ja.

Genau. OK goddit OK. Und das, das ist jetzt nur die die controlpling Komponente. Genau. Das hab ich verstanden. Ja, genau. Lass doch noch weitermachen. Das ist ja eigentlich ganz cool. Ja, also so n technischen Überblick, was es eigentlich alles für Komponenten gibt. Ja, auf jeden Fall. Genau. Und dann geht es auf die Worker, also die Workernotes.

Die Workernotes ist im Endeffekt das, wo dann euer eure Container drauf liegen, also das was ihr quasi auf euer, also man könnte wenn wir jetzt wieder zu dem zu dem Schiff zurückgehen, das war jetzt quasi so die Schiffssteuerung ne das die die Brücke und so weiter und sofort und jetzt sind wir auf der Liegefläche wo die. Wo die Container eben drauf stehen. Und das sind eben die Workernotes, davon gibt es beliebig viele, sage ich jetzt mal. Also nicht ganz, sondern das kubaniertes Projekt selber sagt, wir testen 5000.

Also du kannst quasi 5000 garantieren wir dir, dass du die, dass du die testen, dass das läuft in dem Cluster, es gibt andere Hersteller die Supported mehr hin, also die sagen wir haben das getestet und wir kriegen mehr hin. Ich glaub vielleicht ganz witzig zu hören. Letzte Woche hat Google gesagt oder auf der Cube Con vor 2 Wochen hat Google gesagt und angekündigt wir kriegen 65000 Nodes hin, also ein Cluster mit 65000 Workernotes, das ist halt dann noch mal ne andere Dimension.

Kann man das irgendwie übersetzen für also in in ne softwareanwendung? Also also 5000 Nodes sind also 1000000 youtube User mit. Abfrühstücken als Beispiel oder irgendwas wo man so n bisschen was Greifbares hat, kann man es irgendwie machen oder wenn es Quatsch ist, dann dann nicht, ja. Boah, Relation ist Relation ist da echt schwierig, weil das Problem ist.

Und das ist ja auch das das Spannende an dieser ganzen Geschichte ist. Wir definieren zwar die Notanzahl, aber wir definieren nicht die Notgröße. Das bedeutet, du hast ja dann immer noch eine und also du. Es ist ja nicht definiert, wie viele CP US hat dann eine Note und wieviel Memory hat dann eine Note aber um vielleicht mal da eine Relation reinzubringen, das ist glaube ich, dass es glaube ich ganz hilfreich ist das Standard pod Limit und da kommt schon wieder ein neues neuer Begriff, also ein Pod ist sozusagen die kleinste Einheit in einem cubanetis Klasse, das ist da da drin läuft euer Container, das ist ein Pod.

Also eine eine Instanz von Eurem Container ist ein Pod und es gibt ein pod Limit in Kubanetes pro Note von jetzt muss ich nicht lügen 125 das heißt du kannst zu 125 Pots pro Note draufpacken. Das witzige an der ganzen Sache ist, das ist erstmal unerheblich wie groß die Note ist. Also selbst wenn ich da irgendwie eine Note hinstelle mit 60 CP us die dann mehrere Kerne hat.

Dann kann ich halt theoretisch erstmal nur 125 Pots drauf laufen lassen. Es gibt zwar Endpunkte, wo man das verändern kann, also da kann ich dann sagen, woah du kannst mehr, aber es gibt auch ein ich schon der seit 5 Jahren offen ist wo drüber diskutiert wird ob man das Podlimit anheben soll und alle sagen Oh nee lass mal lieber und ich habe auch schon Leute getroffen die das irgendwie angehoben haben und sich dann gewundert haben warum der Sketuler auf einmal 3 Minuten gebraucht hat um einen neuen Pots irgendwie auf eine Note drauf zu kriegen, weil. Es gibt n Grund, warum dieses Limit da ist und für. Unsere Zuhörer kurz, der Pott ist nicht der Suppenpott, wo die Container drin gerührt werden,

sondern er wird mit DE geschrieben. PUDE ja. Genau. Ja das man manchmal nachgugeln will, dass man da nicht falsch, dass man dann doppel.de tippt oder irgendwas. Aber ja, also so n 65000 Know Cluster ist schon eher riesig, also da da gehst du wirklich in in in wirklich. Riesig groß an Mario, der der pod ne lass uns doch mal kurz beim Pod bleiben. Ja du hast ja gesagt die die Minimalgröße vom Pod ist ein Container die Minimalgröße aber da kann ich ja auch wieder jetzt mehrere Containerinstanzen drin ausführen beim Pod, richtig? Nicht wirklich du.

Ein Pod ist ein Container das einzige was du dazu packen kannst, sind Sidecast. Das macht es aber jetzt quasi schon wieder komplizierter. Also dann lass das lieber erstmal weg. Genau, weil du kannst dann eben kleine Sachen noch daneben laufen lassen, aber ein ein Pod ist ein Container und wenn ich eben jetzt zum Beispiel wenn wir jetzt zurück zu deiner Applikation gehen, wenn du sagst, ich will jetzt 2 mal die Applikation irgendwo ausgeführt haben, dann sind das 2 Pods ist. Wie n Stellplatz für einen Container in der physischen Welt ist genau kannst immer genau einen einen Container reinstellen und der kann genau der gleiche sein wie irgendwo anders.

Also ne Kopie. Oder? Der kann auch einzigartig sein. Das. Genau. Verstanden? OK, bin ich auch noch dabei. Gibt es noch? Gibt es noch weitere Komponenten, die man so kennen muss? Wir gehen ja jetzt quasi auf die Workanotes. Wir hatten ja eben gesagt, es gibt eben diese Workanotes und diese Workanotes da da das witzige ist, was wir noch gar nicht geklärt haben, ist, wie läuft denn jetzt eigentlich mein.

Mein Container, weil irgendwas muss ja auf diesem, auf dieser Node drauf sein, dass mein Container läuft, weil wenn ihr einen Container bei euch auf euren Rechner laufen lasst, dann habt ihr wahrscheinlich meistens Docker. Docker gibt es in Cubonetis nicht mehr, Docker gab es mal in Cubonetis, das war so Version 1 22 rum noch genau das ist jetzt auch schon wieder irgendwie 4 Jahre her und dann?

Wir haben jetzt hauptsächlich Container, die als Runtime, also quasi das ist die Runtime, die benutzt wird, um Container laufen zu lassen. Es gibt noch andere Runtimes, also es gibt zum Beispiel Potman oder CIIOCCRIO, das sind eben alternative Möglichkeiten, um einfach Container laufen zu lassen. Das Gute ist die Docker Manifeste, die die die Leute geschrieben haben für ihre Container, das sind die gleichen.

Also da ändert sich nichts dran. Ich habe einfach einen fertigen Container, das ist einfach nur eine andere Runtime, weil bei Docker war eben das Problem, Docker war einfach zu groß, also Docker ne, ich brauche ja keinen, ich brauche keine GUI, ich brauche eigentlich ja nur die reine Container Runtime, weil um alles andere kümmert sich cubonetes und deswegen ist man eben den weggegangen zu sagen, OK ich nehme eine Runtime die wirklich dafür da ist um einfach nur die Container zum Laufen zu kriegen auf diesen Notes und.

Und dann muss ich irgendwie mit dieses, dann muss ich irgendwie dafür sorgen, dass der, dass der Master mit dem mit diesen Workanotes reden kann und dafür oder beziehungsweise dass in in dem in dem Cluster das ganze Miteinander miteinander gesprochen werden kann, und dafür ist eben noch n Cube Proxy, der auf jedem von diesen Notes mitläuft, und das ist eben der Netzwerk Proxy, der dafür da ist.

Dass der Netzwerkverkehr zu den Pots weitergeleitet wird, das ist die Komponente, in die auch in dem in den Workanotes mitläuft. Und dann hab ich eben, wir hatten ja in dem in der Control plane, hatten wir ja den Controller Manager und der braucht natürlich irgendwie, ich sag mal so, das ist so der der Große, der alles im im oben drüber blant. Und dann brauchst du ja irgendwie nen kleinen Vorarbeiter, der das dann auf jeder Baustelle macht. Also auf jeden von den Workernotes und das ist die das Qplett und das Qplett ist n Agent der auf jeder Note eben mitläuft und dafür sagt dann hey, wir haben jetzt gerade die Handfrage bekommen, wir müssen jetzt irgendwie diese Applikation bei uns starten mit

dem das ist der das. Also das ist das und das Container Image hier Note mach mal. Also es ist sozusagen der Vorarbeiter der dann auf den Workernotes dafür sorgt. Wenn dann die Anfrage kommt, ich soll jetzt da einen neuen, eine Neue einen Container starten, dass das dann da drin passiert. Das heißt, ich jetzt sag jetzt auch noch mal was technisches, aber wir hatten mal eine Folge.

Im Prinzip habe ich eine ganze Horde von Reverse proxies, ich habe auf meiner Control plane einen eingangs Ingress, also den, den den ersten Großen, den ganzen Verkehr entgegennimmt, der schleift dann nach innen, wie man so schön sagt Abstreamen weiter auf die. Auf die Workers und jeder Worker hat dieses Qplet, was ich mir jetzt technisch auch vorstellen kann, wieso ne Art Reverse Proxy oder Irgendsowas oder n Ingress wär dann noch mal weiter verteilt oder ist das?

Reden wir jetzt gerade vom Traffic oder reden wir jetzt von dem? Du musst jetzt hier Note sketul. Ah OK verstanden. Ich war jetzt beim Traffic in meinem Kopf, war beim Traffic in meinem Kopf, du hast aber von dem noch von dem Kontrollebene gesprochen, richtig, das ist wahrscheinlich sehr stark getrennt, ne?

Genau. Also das eine ist erstmal wie also? All diese Komponenten arbeiten natürlich alle zusammen. Also wenn wir jetzt, wenn wir jetzt sagen, wir wollen jetzt irgendwie erstmal dafür, dafür sorgen, dass wir einen erstmal brauchen, wir einen Pod, bevor wir Traffic haben, brauchen wir jetzt erstmal einen Pod, vielleicht gehen wir, da machen wir das als erstes mal.

Wir hatten ja diese API, die auf dem auf der Control plane läuft und ich habe quasi einen Key und dann. Authentifiziere ich mich an meiner an dieser API und dafür gibt es, gibt es etwas und das witzige ist, niemand weiß wie man es ausspricht, weil jeder spricht es anders aus. Ich nenn es Cube Cuttle wird geschrieben KUBECTL das ist im Endeffekt ne Command Line Interface um eben mit eurem Cluster zu interagieren. Und sie haben auf der Cube Con haben Sie ein Trivia Game gemacht.

Was sagen die Leute zu diesem, zu diesem Ding und jeder hat irgendwas anderes gesagt, das ist sehr witzig, also selbst die Leute die cubonitis Maintain sagen alle irgendwie, das heißt anders und im Endeffekt geht man damit her und sagt ich rede mit der Cubonitis API weil eben der Cubonitis Cluster ist eben ja auch API gesteuert und sage hey ich hätte jetzt gerne einen neuen Pot der da läuft. Da gibt es verschiedene Möglichkeiten, wie ich das machen kann.

Wir sagen jetzt einfach mal, ich will einfach nur einen neuen Pod starten und dann rede ich mit der cubinities API und sage, starte mir den neuen Pod, wenn ich gesagt habe, starte mir den neuen Pod, dann geht er her und dann kommt das eben, dann geht der Sketular auf der Control Play in her und sagt Hey wir haben jetzt bekommen, ich will der ich will, dass der Pod keine Ahnung busy Box 1 soll gestartet werden busy Box 1 braucht 0,1.

Cpu und 500 Geek Memory und dann geht der Sketular her und dann entscheidet sich zum Beispiel Workanote 1 hat noch genug Platz, dann sagt Workanote 1 Okay qplet auf der Workanote hier, das ist die Information, die da gestartet werden soll mit dem Container und Start mir bitte diesen diesen Container und dann geht quasi das Qplet her und sagt okay wir haben jetzt diesen Container bekommen. Hey Container Run Time, zieht dir mal das Image und Start, das auf meiner Note so und jetzt haben wir das erste laufende Ding.

Ne jetzt haben wir den laufenden Pod auf unserer Note, das Witzige ist, da kommt noch niemand drauf. Da kommt kann sich jemand mit verbinden. Meinst du da kommt man mit drauf? OK, da ist der ist komplett, der läuft, der läuft jetzt einfach nur, da ist keine Verbindung nach außen, der ist der ist in dem Kubonetes internen Netzwerk, aber da kommst du auch nicht so wirklich rein. Also du kommst da schon rein, aber nicht auf normale Art und Weise, das heißt das Ding läuft jetzt einfach und ist nicht erreichbar.

So und jetzt müssen wir das den Zugang dazu schaffen und dann kommen eben die weiteren Komponenten und deswegen ist eben warum Kubonetes einen. Eine Organisierungssoftware ist das ist. Es kümmert sich eben um diese anderen Sachen mit so, das heißt, ich gehe jetzt im Endeffekt her und sage okay, jetzt habe ich meinen Pod, der läuft jetzt brauche ich irgendwie die Möglichkeit um da drauf zu kommen, das heißt, jetzt gebe ich eben her und erstelle einen Service, dass dieser Pod auch von über das interne couponated Netzwerk erreichbar ist.

Das heißt, ich sage, es gibt jetzt einen Service, der heißt. Login und dieser Service pointet dann eben auf den Pod, den wir gerade eben erstellt haben. So, und das heißt, der Service hat jetzt auf. Über den Service kann ich jetzt eben darauf zugreifen und dadurch, dass ich jetzt einen Service habe, kann ich eben mehrere Pods dahinter hängen, weil ein Service kann mehrere Pods ansteuern und nicht nur einen, sondern eben mehrere Kopien davon und der kann eben dann die die Orchestrierung damit übernehmen und dann um nach außen von außen rein zu kommen und.

Habe ich dann eben einen, einen Ingress zum Beispiel und der Ingress, das ist auch wieder ein Service, der in dem Cluster mit definiert wird und läuft über diese cubonatis API, das ist eben das Schöne, es ist alles. Im Endeffekt sind das jammel Dateien, also vielleicht um das mal auch noch dazu zu sagen, also alles in Cubonatis Cluster wird über Jammel definiert.

Ich hab keine Ahnung, was yamel ausgeschrieben ist es. Ist jetzt in NASA. Jetzt in NASA Gakap Language ja, aber ich bin mir nicht sicher, ob das das wirklich n Name davon ist da. Empfehle ich dann noch mal ne Podcast Folge für uns? Ich weiß nicht mehr welche Nummer wir haben drüber gequatscht. Aber Yamel gequatscht. Ich weiß aber auch nicht, glaub es gibt mehrere mehrere Bedeutungen von Yamel.

OK, gut, also mit yamel konfiguriere ich auch mein ganzes Cluster. Genau, und da konfiguriere ich eben dann auch den Ingress und dann habe ich eben nen Endpoint nach außen, wo ich dann sagen kann, OK, das da ist die IP Adresse. Auf die ich oder meinen DNS Eintrag auf den ich zugreifen kann. Und dann komme ich dann da drauf und dann wird eben über den Cube Proxy geschaut. Wo muss der Netzwerktraffic hin damit ich am Ende bei dem Pod ankomme?

Okay. Das ist viel. Das ist total viel, weil das ja auch diese ganze, die ganze Netzwerk Abstraktion und so weiter beinhaltet. Und jetzt bin ich spitz, finde ich, weil ich. Wir nutzen ja nicht kubanitis, das hatte ich schon verraten, indem ich mich geoutet hab, dass ich keine Ahnung von dem Thema hab. Also beziehungsweise nur sehr rudimentär. Wir nutzen aber schon auch verteilte Microservices und so weiter aber mit mit Docker Technologie quasi und ich weiß zum Beispiel, dass ja, dass das nicht so einfach ist, jedenfalls in meiner kleinen Welt diese ganzen DNS Sachen, ja Domain Name, Service, das sind ja so Sachen die. Die musst du ja, das sind ja wieder dritte Anbieter. Du musst ja, wenn du IP Adressen

zuordnest zu bestimmten Domainnamen und so weiter haben wir auch eine Folge, wer das jetzt nicht weiß, der kann auch noch mal hören, aber im Prinzip ist ja, dass das Telefonbuch des Internets, sage ich mal ja, also du willst irgendwie unter, ich sag mal was Test Punkt heißen wir Punkt Cloud willst doch bestimmt irgendwo hinkommen und so weiter und jetzt habe ich dieses ganze Kybernetis gehört mit diesen ganzen Notes und I PS und so weiter managt und ich kann mir nicht vorstellen, aber managt kybernetis dann auch irgendwie die DNS Sachen für mich den Namen oder sowas und. Das muss ich ja schon noch von Hand irgendwie noch mal irgendwo eintragen und irgendwelche IP Adressen zuordnen oder nicht oder wie oder?

Das das Witzige ist ja, das musst du. Aber du kannst deine deine Lob, Balancing und dein ganzes, dein ganzes Management halt in einem kombiniertes Cluster laufen lassen und dann sind wir nämlich irgendwann bei diesem Punkt, wo du dann eben wo es dann auch für viele dann auch irgendwie komplizierter ist, wo du halt nicht mehr nur ein Cluster hast.

Ne, also hast halt dann tatsächlich dann eben dass du. Du hast n Service Cluster in deinem Service Cluster läuft dein Lopalancer, dein Lopalancer, der sich dann den Traffic nicht mehr nur innerhalb des Clusters weiterleitet, sondern der dann deine Last über die verschiedenen Cluster weiterleitet, also beispielsweise ne Gerrit ist jetzt in USA und Burkhard Du bist in du bist in Deutschland und ihr ruft beide die gleiche Webseite auf, aber ihr kommt dann vielleicht nicht mal auf dem gleichen auf.

Ne in dem gleichen Kubanitis Cluster auf unterschiedlichen Pods raus, sondern ihr kommt dann eben auf verschiedenen Kubanitis Clustern raus, obwohl ihr beide die gleiche Adresse eingegeben habt, obwohl das das Lobalancing sozusagen zentral gemacht wurde in einem Cluster, der Halt rein für Lobalancing da ist. OK und?

Genau. Also das ist das Schöne da dran, diese ganze Cloud native Welt. Also ne, dieses Couponatis gehört ja auch der CNCF als Open, als Open Source Projekt im Endeffekt dieses ganze E Ekosystem was da dahinter ist ist riesig, also ich glaub wir sind bei über 200 Projekten mittlerweile und da ist halt auch n No Balancer mit dabei, da ist auch irgendwie n. So Traffic Überwachung mit dabei, was alles gar nichts mehr mit Kuboniertes zu tun hat, aber halt inkuboniertes Clustern funktioniert und inkluboniertes Clustern läuft. Es ist ja ein riesen technisches Thema. Wir haben es ist, es ist also ich hab mich grad so n bisschen davon verabschiedet das voll zu durchdringen heute, aber ich ich hab auf jeden Fall den den den

guten Überblick bekommen und würd es gern noch mal n bisschen wiederholen und noch mal gerne, dass du sagst wenn da was falsch ist und dann müssen wir dann noch mal drüber sprechen. Für wen macht das Sinn, so n Cluster einzuführen? Für welche Aufgaben, ab welcher, ab welcher Skalierung et cetera?

Ne, weil ich glaub das ist auch noch mal spannend herauszufinden, ja ist das wo ist das ja auch gut geeignet, wo bringt das Mehrwert und wo ist es wo, wo ist es vielleicht mehr Overhead als es am Ende als es am Ende Mehrwert bringt so ne. Gerrit aber da würde ich mal gerne noch einmal, bevor du gesagt ist, super, super Plan zusammenfassend und so weiter und bevor du dann in die in die wieder in die etwas größere Abstraktionsebene gehst, hätte ich noch eine detaillierte technische Frage, die brennt mir unter den Fingerlegen, die muss noch los. Schieß los.

Soll ich jetzt gleich oder was okay gleich mal pass auf das schwierigste was ich finde und jetzt sprechen wir über den wirklichen Traffic und über die Nutzer, also über den Gerrit und mich und wir haben zum Beispiel eine Webanwendung und so weiter und du sagst ja selber so ein kybernetis Cluster, ich weiß vielleicht noch gar nicht so ganz genau wo wo ich immer landen werde, auf welcher Note, also auf welchem Server.

Mein größtes Problem ist, wie wird das geregelt mit den echten Daten? Also wenn der Gerrit jetzt irgendwas abruft, so der braucht ja irgendwie jede Webanwendung. Das Wichtigste sind ja die verdammten Daten ja also ich hab. Vielleicht eine riesige Datenbank, die relativ zügig zu erreichen sein muss.

Und die ist ja irgendwie voll die zentrale Komponente, denn wenn ich, wenn ich jetzt irgendwie, wenn ich jetzt irgendwie skalieren will, dann muss ja jeder microservice, jede Anwendung, die irgendwas mit Daten zu tun hat, und ich würde sagen, jede Anwendung, die irgendwie also sehr viele Anwendungen brauchen, irgendwie irgendwo mal eine Daten, Datum, daten, so ja, also das ist ja kein Seitenproblem, das ist ja dann standardfall, ja dann müssen die ja quasi alle Zugriff auf die gleiche Datenbank haben, oder?

Alle irgendwie ne Kopie von der Datenbank haben aber die Richtige. Ja da muss ja mindestens das stehen für Gerrit. Ja und wenn der Gerrit dann irgendwie auf einmal umzieht mit seinem Note, weil weil das Gerrit oder sich überlegt hat, ich bin jetzt mal woanders, ja weil wir haben ja zu viel Last auf dem Knoten und dann müssen ja die Daten von Gerrit auch umziehen und so weiter und sofort, also da, da hab ich noch einen Knoten im Gehirn wie das Cubanit ist irgendwie auch noch irgendwie magicly irgendwie alles regelt, ja kannst du da so ein paar Worte zu sagen, Mario?

Das Witzige ist, jetzt begeben wir uns in ein Gebiet, das seit. Ich würde jetzt mal sagen im Jahrzehnt, weil Cubonetis ist dieses Jahr 10 Jahre alt geworden. Die Geister scheidet nämlich haben persistente Daten etwas in einem cubonetis Cluster verloren oder nicht, und das ist tatsächlich mittlerweile eine fast philosophische Frage, wo man da reingekommen ist, weil, wie du schon sagst, wir haben halt das Problem, dass wir mittlerweile halt.

Cross Cluster Skalierungen machen und selbst wenn es nur in einem Cluster ist, wie kriegen wir die ganzen? Wie kriegen wir die ganzen Daten persistent zueinander? Also per se ist die Idee an Cubonetis erstmal, dass deine Workload, also deine Container nicht stateful sind, also die keinen eigenen State haben. Es gibt zwar die Möglichkeit eines stateful Sets, also das ist quasi wir haben auf der einen Seite gibt es deployments, Deployments sind einfach stateless, du hast nichts dran, dann gibt es ein stateful Set, da hängen im Endeffekt. Persistente Daten mit dran.

Ich kann die da auch als Volumes mit rein mounten. Also ein Volume ist im Endeffekt da, wo deine Daten mit drin liegen. Das Problem an der ganzen Sache ist aber genau das was du schon sagst. Wie verhält sich Storage zum Beispiel redright many also schreiben, dass mehrere gleichzeitig schreiben können, das ist das muss dein Storage hergeben, das ist das ist genau das Problem und dafür die großen Cloud Provider.

Haben das so ein bisschen gelöst, indem sie halt gesagt haben okay wir bauen und jetzt wird es abgefahren. Storage ist auch nur ein Container, der Halt beschreibbar ist. Und es gibt halt auch Anbieter so kommerzielle Anbieter. Es gibt auch Open Source Projekte die eben so so eine Storage Lösung die zum Beispiel sich dann auch wieder über mehrere Server Stretched dazu stellt. Also zum Beispiel gibt es da als Open Source Projekt gibt es das SAF, also CEPH.

Und dann baust du dir im Endeffekt nen Cluster auf, der erstmal nur dafür da ist für für Storage. Also es hat nichts mit Cubonetes zu tun, aber der kann Cubonetes Storage zur. Verfügung stellen. Also so n bisschen früher, wie mein Cluster File System wo was ich irgendwie per Netzwerk irgendwie spannend über verschiedene Worker und so weiter und dann da passiert viel Magie drin, synchronisiert sich von allein und ich schreibe da einfach rein und hoffe, dass nichts passiert, wenn ich es gleichzeitig tue. Genau.

Und wir haben das tatsächlich. Wir haben das Across Data Center, also wir haben, wir haben, ich habe Projekte, wo ich mitgearbeitet habe, wo der Storage eben dieses, dieses dieser Shared storage und dann um dann halt auf diesen Speed zu kommen, über Data Center hinweg geht, das heißt du hast einen Storage Cluster der über mehrere Data Center die physikalisch auseinander sind hinweg funktioniert.

Alternativ, du musst halt deine Applikation einfach darauf optimieren. Also wenn man jetzt wieder auf dieses ganze Thema kommt, was du ja gemeint hast, du brauchst irgendeine riesige Datenbank, es gibt ja mehrere Datenbanktechnologien, die im Endeffekt in der Lage sind, ein großes, eine große verteilte Aufbau hinzustellen, also zum Beispiel wenn ich jetzt einen Microservice habe.

Der mit einer Persistenten, also mit einer SQL Datenbank arbeitet. Dann lese ich halt von den von den Slaves. Ich habe vielleicht meine meinen Master auf den ich schreibe oder es gibt ja auch zum Beispiel Datenbanken die über Charts arbeiten, also Mongo DB zum Beispiel ist ja so eine klassische Chart Datenbank wo du eben aufbauen kannst, dass das auch über die über die gleiche Mehrgröße sich erstreckt und im Endeffekt ist das eigentlich der Anwendungsfall den du mit Kubanitis dann auch bauen musst.

Ist du baust deine Applikation und. Muss genauso global laufen können wie du selber. Das heißt, das ist auch das Problem, dass Legacy Applications in den Cubonetes Cluster packen und das ist vielleicht dann auch der Überleitung zu Gerrit von wegen für wen ist es interessant und für wen nicht? Eine Legacy Application in einen Cluster zu packen kann ich schon machen, ist aber wahrscheinlich nicht so klug, aber.

Also der der einzige Anwendungsfall ist. Ich will das Ding irgendwann ablösen und ich will mich jetzt nicht selber um eine VM noch mit kümmern wo das Ding drauf läuft oder einen Server drum kümmern, dass es zumindest schon mal in der neuen Welt ist. Aber performant wirst du es niemals kriegen. OK, verstanden?

Also das ist nicht so einfach erklärt, da gibt es also ich fasse das nur mal diesen Aspekt zusammen, dann lasse ich gerade ein bisschen mehr Aspekte zusammenfassen, aber diese diese dann, das hat ja auch noch so ein Zuckerstückchen mit Daten. Wenn ich jetzt, wenn ich jetzt zum Beispiel eine datenlastige Anwendung habe, unsere ist zum Beispiel ziemlich datenlastig, da werden relativ viele Daten andauernd gespeichert und gelesen, und wenn ich das jetzt aber auch noch performant hinkriegen will, also sowas wie ein Realtime im Browser, dann will ich ja eigentlich vermeiden, dass ich jetzt aus einer riesen zentralen Datenbank, die irgendwo liegt, andauernd einen Netzwerk Call mache, denn das muss ich ja tun,

die liegt ja vielleicht gar nicht auf dem gleichen Note und und und. Wieviel Speed kriege ich, wenn ich, wenn ich die Daten direkt neben dem Computing neben der Computing Engine habe? Liegen hab ja, da muss ich ja nur von der Platte lesen und spiele ja immer hoch. Ja das sind ja alles so Sachen wo ich mir denke so boah wenn das das klingt ja alles toll und so, ich kann damit irgendwie skalieren, aber da geht ja ganz schön viel reibungsverlust drauf so gerade wenn ich jetzt irgendwie so zentrale Clusterpfeil ist. Ja oder vielleicht macht das auch kein, vielleicht macht das auch kein Brot so ja aber.

Der Punkt ist tatsächlich, und das ist das Schöne da dran, es kommt im Endeffekt drauf an, wie ist die Verbindung zwischen den Notes, also wie. Was hast du im Endeffekt zwischen den Notes für Networking? Weil die Notes sind verbunden zu den zu der Controlplane, also die Workernotes zu der Controlplane sind in der Regel verbunden über ein Tool, das nennt sich Connectivity, also mit K geschrieben, das ist auch ein Teil von Google nethers Projekt ist ein Layer 2 TCP Proxy.

Du musst nicht durch irgendwelche, und das ist der Vorteil, wenn jetzt die Datenbank in deinem Cluster mitlaufen lässt. Und ja, ich bin ein Freund, Datenbanken in seinem Cluster mitlaufen zu lassen und damit damit werden jetzt ganz viele Leute wahrscheinlich eigentlich an die Gurgel springen, dass ich das sage, aber im Endeffekt musst du das Ganze so sehen, dass dadurch, dass die Datenbank in dem Cluster mitläuft. Hab ich auch nicht mehr diesen diesen Networking Overhead, wo ich vielleicht in n anderes Netzwerk gehen muss, sondern das ist ja alles ein innercluster Network was miteinander agiert und wir benutzen oder viele und da jetzt wird es super technisch und das machen wir auch bloß

ganz kurz. Das Container Network Interface, also wie quasi das Network in einem Cluster aufgebaut, ist mit zwischen den Containern. Da gibt es mehrere Möglichkeiten und der oder das am meisten verbreitete aktuell ist tatsächlich silium und Silium ist IBPF based und IBPF based. Es geht quasi auf Kernel Ebene runter, das heißt ein Network Traffic geht bis auf die Linux Kernel Ebene runter.

Und damit kriegst du halt schon ganz schön viel Geschwindigkeit raus aus diesen ganzen Sachen. Also Performance ist immer ein Thema, aber wenn man sich, ich sag mal genug Hirnschmalz reinsteckt, wenn man sich seine Architektur baut, dann macht das durchaus, dann dann kriegt man da tatsächlich irgendwie Gewinn bei raus. Cool, danke.

So, jetzt können wir wieder aufsteigen aus dem technischen Sumpf, ja. Jetzt habt ihr hier so einen Spannungsbogen aufgebaut. Ich kann gar nicht so viel zusammenfassen, aber aber. Aber also letzten Endes fand ich schon ganz kurz zu verstehen, dass es NN Cluster gibt und das hat insofern Limitierung, dass man sagt, bis wohin ist eigentlich getestet von der Open Source Gemeinschaft.

Also was bei 5000 Notes war und 125 Pots dann pro Note oder bis zu 125 und im Cluster gibt es verschiedene Komponenten, so ne Art Steuerungsbrücke haben wir gesagt, ist controlplain und was ich da spannend fand ist, dass du gesagt hast wenn es 3 Stück sind, spricht man eigentlich von Hochverfügbarkeit.

Das heißt, wenn Zweibrücken Abrauchen ist immer noch eine da und dann hab ich quasi n hochverfügbares System, ja dann gibt es die Workernotes, wo die eigentlichen Pots laufen, ein Pod ist immer ein Stellplatz für einen Container von meiner eigentlichen Anwendung ne und und von denen kann es beliebig viel geben 5000 ist getestet, du hast aber auch gesagt 65000 ist, man munkelt über 65000. Also Google hat es getestet.

Also Google hat macht damit Werbung. Sie haben mit 65000 Notes getestet und es läuft. So, und dann gibt es ne ganze Menge an an Komponenten, die ich jetzt nicht noch mal wiederholen will, aber die dafür sorgen, dass Container vernünftig verteilt werden in diesem, in diesem Cluster oder immer an der Stelle gestartet werden und wieder gestoppt, wo es halt gerade am sinnvollsten ist.

Ne, darum geht es ja eigentlich viel jetzt um das Container hochziehen und immer wieder Container auch wieder schließen. So und dann gibt es noch. Nicht nur ein Cluster, sondern die Cross Cluster hast du glaube ich gerade gesagt. Da gibt es auch noch Kommunikation. Genau. Und dann gibt es auch noch die Möglichkeit, dass man eben Cross Cluster Cross Cluster Communication macht, aber da brauchst du halt wieder andere Tools, da kommt dann das ist dann der Punkt wo dann so Service Mashes interessant werden und Cluster mashes, die dann eben sich über mehrere Cluster erstrecken.

Und das brauche ich erst, wenn ich, wenn ich so international und soweit schon aufgestellt mit meiner Software das. Dass ich ganz viele Nutzer aus den USA hab und ganz viele aus aus der Dachregion vielleicht und so weiter und den möchte ich nicht durch die Welt schicken, quasi. Genau oder einfach, wenn du und da sind wir auch wieder bei der wie baue ich Architektur, wenn ich dann sage, ich zersplitte meine Architektur von Microservices über über Cluster, dass quasi ein Cluster sterben kann, und dann ist nur eine Komponente weg. Ja.

Weil weil irgendwas passiert. Aber andere Komponenten laufen dann halt weiter. Das ist, das ist einfach immer ne Architekturfrage wie wo befinden wir uns da in und wie ist das Umfeld oder vielleicht brauch ich auch einfach ne ne physikalische Trennung weil ich vielleicht ne kubonäres Cluster in der Fabrik laufen lasse oder mehrere Kubonieres Cluster in der Fabrik laufen lasse. Daran anschließend hab ich hab ich mich gerade was gefragt, aber schon länger.

Was ist denn eigentlich der der Typische? Anwendungsfall hab ich als Softwareanbieter eigentlich n Cluster. Also jetzt sag ich mal heisenware wir machen unsere Local Plattform und so jetzt mal angenommen wir sind irgendwann ganz groß, das gibt es weltweit und dann würden wir uns ein Cluster aufsetzen um unsere Kunden zu bedienen oder ist es eigentlich andersrum, dass irgendein Endkunde der ne weiß ich nicht meinetwegen im Manufacturing Bereich hat irgendwie 100 Werke auf der ganzen Welt und Riesen IT Anforderungen, dass der sich eigentlich eher nen Cluster aufbaut oder Kubernetes nutzt.

Also oder ist es auf beiden Seiten nutzbar? Also es. Ist auf beiden Seiten nutzbar, weil im Endeffekt ist halt wenn ihr Software as a Service anbietet, dann seid ihr im Endeffekt der skalierende Faktor. Ne, das heißt ihr bietet die Plattform an und ihr lasst quasi die Sachen auf ne kombinierte Klasse laufen oder auf mehrere Laufen und bietet das euren Kunden an wenn du in der Industrie bist, gibt es ganz andere Anwendungsfälle im Endeffekt, weil da ist ja das Problem in der Regel, die wollen ja auch weiterlaufen wenn die mal kein Internet haben. Weil irgendwie keine Ahnung.

Bagger hat durchs Kabel gebaggert, vor der Fabrik kein Job, das habe ich schon mal miterlebt und dann war halt das Werk offline und aber die Produktion muss ja weitergehen, das heißt, Cubonetes ist eben, und ich glaube, das ist das Schöne daran, was man sagen kann, ist cubonetes ist so, so generisch mittlerweile und so allumfassend für als.

Als Grundstock, um deine Container laufen zu lassen. Dass du das eben in allen Bereichen im Endeffekt einsetzen kannst. Also im Endeffekt ist es egal, welche Größe du hast. Also von von kleineren Firmen bis größeren Firmen, also zum Beispiel ein Bekannter von mir, der benutzt ein cubonetis Cluster, einfach eine Managed, eine Managed cubonetis Lösung, er hat selber nicht wirklich die Ahnung was was die einzelnen Komponenten im Cubonetis Cluster. Tun, weil er eben den Cluster selber nicht managen muss, sondern einfach nur den Service benutzt als als commonites Endanwender.

Und das Einzige, worum er sich kümmern muss, ist, wie kriege ich meine meine Deployments, also wie kriege ich meine Pods in den Cluster, aber um den Betrieb des Clusters muss er sich selber nicht kümmern und das ist eben glaube ich so, dieser der Grund auch warum das mittlerweile so den Weg als die Standardplattform für für Containeranwendungen gefunden hat ist weil es eben verschiedene Optionen und Anwendungsfelder gibt. Also ich kann zum Beispiel auch n Cubonetes Cluster als Single Note betreiben, wo Worker und Controlplain auf der gleichen Note basieren, also dann ist das im. Im Endeffekt ist das halt dann eine einzige Maschine und dann gehen wir dann irgendwie in Edge Bereich. Also ich hab nen Cluster gebaut

der läuft auf 3 Raspberry Pies und n Jets NNX also von Nvidia für für ne GPU und das Ding ist 10 * 10 Zentimeter. Ne das das sind halt dann winzige tragbare Coronitisklasse, die halt wahnsinnig es einfach machen Software auszurollen in einer standardisierten Art und Weise, weil das ist ja auch die Idee von Docker damals gewesen.

Ne, ich kann deinen, ich kann deinen Entwicklerrechner nicht shippen in production, aber ich kann Container shippen und im Endeffekt ist es eben so. Ich kann vielleicht nicht irgendwie dieses containerzusammelsurium shippen, aber ich kann Standard bereitstellen, wo das überall. Gegeben ist, dass das überall funktioniert, also da, da kommen wir halt wieder in die Welt von dir, die IT Welt baut sich selber ihre Standards auf das. Ist interessant was du sagst, weil man könnte jetzt die die Meinung kriegen, so kompliziert dieses anhört und so viel Komponenten wie es da gibt und so weiter und es ist ja auch wirklich komplex und kybernet das ist jetzt nicht, das machst du frühstückst du immer nicht

eben beim so nebenbei ab und dann kannst du das, da muss man sich schon glaube ich einen Schluck länger mit befassen, es ist aber dennoch. Relativ performant und dünn also. Es ist nicht so, es ist gar nicht so ein dickes Ding, wenn du sagst, ich kann das irgendwie auf dem Rugby drauf laufen lassen und hat es zwar viele Konzepte und so, es ist von der Architektur vielleicht herausfordernd, je nachdem was ich so mache damit, aber es ist, es braucht gar nicht selber so viele Overhead und Ressourcen, es läuft relativ schlank und ist hochoptimiert quasi meine Anwendung irgendwie zu zu managen.

Genau, und das ist portabel, ne, also du kannst es halt in den verschiedensten Umgebungen laufen lassen, du kannst es auf armbasierter Technologie laufen lassen, du kannst es auf den klassischen X 86 Architekturen laufen lassen, es gibt auch eine sig Windows, also du kannst es auch auf Windows laufen lassen, wer immer das möchte, genau du bist halt portabel, das ist das ist das Schöne da dran und es ist halt nen.

Es ist halt sehr, sehr recilent was das Ganze angeht. Ne das ist glaub ich ich glaub das haben wir auch bisher noch gar nicht gesagt, also der Grund warum ich nen Cubonitis benutze ist cubonitis hat ne self feeling Funktion weil Cubonitis versucht erstmal Sachen immer wieder das heißt wenn irgendwas kaputt geht versucht es das ganze so lange bis es geht.

Deswegen habe ich dann vielleicht, wenn wirklich was kaputt ist, irgendwie da steht bei einem Pod, der Pod wurde irgendwie 8950 mal neu gestartet, dann. Habe ich wahrscheinlich einen Bug in der Software irgendwo gehabt? Genau das ist das. Klingt erstmal irgendwie, oh, das ist ja total doof, aber manchmal ist es auch einfach nur ein Schluckauf und dieser schluckauf behebt sich halt dann selber, wenn das halt, wenn wenn halt irgendwas passiert. Deswegen ist diese Self Feeling Architektur da halt immer das was man vielleicht was die meisten Leute. Auch nicht nicht wirklich so auf dem Schirm haben ist, wenn jetzt ein Pod kaputt geht, weil die Software crasht, dann kriegt der Couponet das ja mit.

Hey, der Pod ist gecrasht, aber wie ich weiß, dass es vorher gelaufen ist. Das heißt Escatular einfach. Also ich nehme diesen Pod und packe ihn einfach wieder irgendwo hin und dann wird er wieder komplett neu aus dem Docker Image gestartet und das was den den Pod crasht so verursacht hat. Ist dann im Endeffekt erstmal egal. Ne, das heißt ich kann das heißt ich habe zwar die Downtime in dem Moment wo der Pod kaputt gegangen ist, aber in dem, aber dann wird sofort wie dieser quasi neuer Pod gestartet mit dem gleichen Container drin und ich habe quasi nicht so diese Ausfallzeit und ich glaube das ist auch das was was viele Leute irgendwie nicht unterschätzen ist, wenn ihr mir jetzt eine komplette Node kaputt geht die

unten drunter liegt von diesen Workernotes und ich habe noch genug Platz auf den anderen Sachen, dann nimmt er die Pods die. Die auf der Workernote drauf hätten laufen sollen oder gelaufen sind und pack die auf die anderen Notes mit drauf. Das heißt dein dein System bleibt obwohl du vielleicht irgendwie hardwareausfälle hast oder obwohl irgendwo einen Software Crash ist, wird dein System am Laufen erhalten, ohne dass du erst mal was tun musst.

Also generell sollte man sich eine kaputte Note vielleicht trotzdem mal anschauen, aber. Von der Idee her ist das Halt. Es nimmt dir halt schon mal Arbeit ab und hilft dir auch eben quasi hoch verfügbar eben zu sein. Ja, das ist ein total wichtiger Punkt da. Da will ich noch was zu ergänzen, denn das hat man mir auch so beigebracht, das ist ja so, je größer ich eine Anwendung Anwendung werden lasse, mit je mehr Komponenten und je mehr Server dabei bei quasi arbeiten, desto höher ist ja die Wahrscheinlichkeit, dass man was ausfällt.

Ja und man muss als Softwarearchitekt nicht denken. Darf das System nie so sein, dass ich denke okay im optimalen Fall läuft hier immer alles, sondern ich muss die Annahme zur Regel machen, dass immer mal wieder was kaputt geht, gerade wenn es, wenn ich ein großes System habe, das heißt, wenn ich ein resilient System aufbauen will, hilft mir kubanitis dabei, quasi diese Annahme hier wird mal irgendwie eine Festplatte ausfallen, hier wird mal irgendwie ein Cluster nicht da sein, hier ist mal irgendwo ein Netzwerkkabel irgendwie was.

Oder irgendjemand hat das sogar im Rechenzentrum irgendwie verbockt oder irgendsowas, das gehört halt quasi zum Daily, zum Daily Business und dann hilft mir das System quasi trotzdem so gut es geht halt. Ja, es gibt natürlich immer auch steigerungsstufen ne, wenn es halt irgendwie alles erdgabel weg ist. So in der Ostsee und es ist halt blöd, ja, aber wenn es das halt nicht ist, dann dann bin ich trotzdem relativ stabil in meiner Anwendung und das denkt das Kybernet es quasi für mich mit so ich es verstanden habe.

Und muss mir nicht ganz so viele Gedanken mehr selber machen als Anwendungsentwickler überhaupt die Stabilität meiner Anwendung gegebenen Ausfällen von Hardware oder Netzwerk oder wie auch immer. Genau, und das ist eben wirklich der wichtige Punkt an dieser, an dieser ganzen Geschichte. Es hilft dir bei der Stabilität deines Systems und zum Beispiel also bei vielen Projekten in der Vergangenheit sind wir immer von einem offline Szenario ausgegangen, obwohl vielleicht sogar eine Verbindung ins Internet da gewesen ist.

Das heißt, wenn man sich große Projekte anschaut, dann. Du gehst immer eigentlich davon aus, dass irgendwas kaputt geht. Das ist eigentlich erst mal deine Grundannahme ist Something will Break. Genau. Damals ne Stunde hingearbeitet, sehr gut, das find ich super, wenn es für euch OK ist, lasst doch noch mal n bisschen tiefer drauf eingehen, ab wann sollte ich kubanitis eigentlich verwenden, wann lohnt es sich, welche Vorkenntnisse brauche ich angenommen ich hab noch gar keine, bin aber trotzdem Softwareentwickler, vielleicht die Voraussetzungen gegeben was was was mach ich eigentlich als Erstes um um da reinzukommen und loszulegen. Also du solltest generell kombiniertes immer verwenden. Immer.

Nein, also die Frage ist, wie sehr, wie sehr ist man immer bereit, sich damit mit auseinanderzusetzen und wieviel Resilence. Also klar, wenn ich n kombiniertes Cluster aufbaue hab ich immer nen Overhead ne also ich hab immer diese 3 Control Play Notes die erstmal also wenn ich das ganze hoch verfügbar mache und wir gehen einfach mal davon aus jeder möchte irgendwie hoch verfügbar sein das heißt ich nehm 33 Maschinen und diesen erstmal.

Du meinst jetzt du meinst jetzt einen Overhead im Sinne von ich brauche mehr Server als ich als ich so ohne bräuchte. Genau, was du dadurch gewinnst, ist eine Widerstandsfähigkeit und eben diese Hochverfügbarkeit. Und du brauchst halt Leute, die sich damit auskennen, wie man eine Klasse betreibt und ich glaube, dass das ist der, das ist genau der springende Punkt, da muss man dann eben entscheiden. OK, ich habe mehrere Anwendungen die laufen müssen. Also wenn ich jetzt irgendwie nur 2 Container habe oder 2 Softwarepakete habe, die irgendwo laufen müssen, dann packt die auf eine VM oder besser packt die auf irgendeine Containerplattform die als Service funktioniert. Also es gibt ja im Endeffekt

Plattformen wo ich einfach Container reinschmeißen kann, die großen Cloud Provider benutzen einiges davon, stellt da einiges zur Verfügung, das ist dieses berühmte Serverless was dann immer. Dogmatisiert wird aber im Endeffekt ist es genau das. Ich habe einfach nur beschränkte Anwendungen, die Container Anwendungen, wo ich einen überschaubaren Wert habe, die einfach laufen sollen, wenn das ganze komplexer wird und mehr Zwischenspiel zwischen den Anwendungen passiert, dann gehe ich auf einen cubanitis Cluster on Prime finde ich macht ein cubanitis Cluster total Sinn, also alles was irgendwie in Deinem Data Center oder in deiner in deiner Umgebung läuft, weil.

Ich muss mich nicht da darum kümmern, dass irgendwie VM 1 bis VM 5 läuft, sondern für mich sind VMS dann nur noch Nodes. Das heißt, sie sind werden von man sagt ja immer so schön PET to Kettle, also hier Haustiere zu zu Herdentiere im Endeffekt, weil der einzelne Server interessiert mich dann nicht mehr so sehr, weil wenn VM kaputt geht gut, dann hänge ich halt eine andere VM in den Cluster rein und muss mich nicht mehr drum kümmern, das ist glaube ich der der Moment wo ich mir. Wo ich mir dann den Gedanken mache, OK, jetzt gehe ich in Kubonetes im Zweifel, wenn ich sage, OK, ich krieg das Wissen nicht her und sei mal ehrlich kubonetes wissen ist in Deutschland, vor allen Dingen in

der Dach, also Deutschland, Österreich und Schweiz, immer noch ein sehr überschaubares Thema, was was da irgendwie an Vorwissen mitkommt und wo es irgendwie echt hart ist Leute zu finden. Es gibt genug Anbieter die zum Beispiel Kubonetes as a Service anbieten, vielleicht wäre das auch einfach der Weg, dann kann ich mir erstmal die die.

Die Zehen ins kalte Wasser tippen, indem ich erstmal nur mich damit beschäftige, wie kriege ich meine Applikation in so einem Cluster zum Laufen, weil das ist ja an sich schon mal ein riesiges Thema und wenn ich das geschafft habe, dann kann ich mir mal darüber Gedanken machen, wie betreibe ich eigentlich so ein Cluster und ich glaube, das ist so die Wege von Größe kann ich, kann ich dann nicht mal sagen, also ich habe einen Kumpel der läuft. Der ist das ist ne 2 Mann Firma, die lassen irgendwie mehrere kubonetes Cluster laufen und benutzen das quasi als nur als Consumer bei einem bei einem Manage Service. Ich kenn große ich kenn große Industriekunden die auch noch gar kein Kubonetes benutzen in

ihrer Umgebung weil sie sagen unsere OT kriegt das nicht hin ne weil weil einfach das Wissen fehlt also ich glaube da das hängt ganz ganz starker Faktor ist da auch immer hab ich das wissen wenn wenn ich das n wissen nicht hab kann ich mir das wissen einkaufen. Und euch könnte man buchen, um dieses Wissen einzukaufen. Richtig?

Tatsächlich, ja, wir machen, wir machen Cubonetis Trainings, und zwar für alle Bereiche, also zu allem, du bist ein Developer und willst einfach nur den Anwendungsfall mal wissen oder du willst in Operations gehen, du willst das Ding betreiben oder worst case, wir machen auch Managed Service, also wir machen auch tatsächlich, wir betreiben Eure Cubonetis Cluster für euch auf unserer Plattform, aber da reden wir dann eher so von. 5060 100000 clustern ich ich genau Skalierung.

Du kannst mit weniger Leuten mehr dadurch, dass alles die gleiche Technologie ist, brauchst du weniger Headcount um mehr Server zu verwalten, also insgesamt ne, weil Community ist ja immer das Gleiche. Das ist richtig. Dafür brauchst du aber, was du vorher gesagt hast, den richtigen Head, das ist ja, das ist ja ne allgemeine Wahrheit, so, wenn du gute Softwareentwickler hast, dann brauchst du auch nur wenige davon, so ne aber ja wie das so ist. Ist schon n komplexes Thema, das ist ja auch der Bereich, das sag ich jetzt auch noch mal, für der der Begriff ist auch nicht gefallen, so DEV OPS und so weiter es gibt ja immer so stellen, wenn sich das mal jemand fragt, ja was ist denn DEV Ops Development operations,

weil das spielt da glaub ich auch mit rein ne und das sind die das sind die Herren die tatsächlich auch relativ ja teuer sind und viel Geld verdienen, einfach weil es halt ne komplexe Geschichte ist und weil es natürlich auch n bisschen critical ist. Ja wenn ich da. Ich habe auch immer ein bisschen Schweißperlen auf der Stirn, wenn ich irgendwie deploye, auch wenn du mal mal ein versions Upgrade, davon haben wir noch gar nicht gesprochen, das muss ja auch alles gemanagt werden, ich habe ja keine Software, die auf einem Versionsstand ist. Das entwickelt sich ja auch noch alles weiter und so, da kann man ja was falsch machen.

Ja, da kann man auch mal kann man nicht, das ist wahrscheinlich im Jammel einfach mal ein paar falsche Sachen eintragen und dann ist auch blöd. Ja, also insofern. Und wir haben 3 Releases pro Jahr und es ist Akt der die Supported Version ist immer nur current Version minus Two, das heißt nur Akt ja nur eben 3 Versionen. Das heißt du musst einmal pro Jahr musst du deine musst du alle deine Klassen updaten.

Kubanites wird dreimal im Jahr aktualisiert und also quasi alle ihr, die alles Jahr muss ich dann auch updaten. Genau also meine Versions Patch Releases kommen natürlich öfter, Patch Releases kommen dann, wenn CVES oder Critical Critical Sachen rausgefallen sind, aber generell hast du. Problem, dass du einen cubanitis Cluster in der Miner Version dreimal, also einmal pro Jahr mindestens updaten solltest und wir deprecatend syncs. Also da fallen auch dann einfach mal API endpoints raus und so und dann musst du halt schauen was in deinem Cluster läuft und dann danach kaputt geht.

Okay das heißt, ich brauche eigentlich Experten für die Einführung von Cubanitis also und dann auch für den Betrieb und das ständige Updaten und warten der Plattform. Jetzt wieder mal zum Open Source Projekt. Wie viele Kontributoren gibt es dort, kann man das ungefähr sagen? Haha, jetzt hast du mich.

Du hast mich auf einem Fuß erwischt, den ich eigentlich wissen müsste, weil ich tatsächlich am Freitag da drüber gesprochen habe, weil es gibt nämlich ein Meeting der Cubonetis. Org, das einmal pro Monat stattfindet, und das nennt sich. Cubonatis contributor orientation, das heißt, wenn irgendjemand Interesse daran hat, ein Contributor zu werden, zu cubonatis, da gibt es quasi da die Übersicht über. Wie funktioniert das Projekt an sich selber, wo finde ich irgendwie die ersten Aufgaben, wo kann ich irgendwie irgendwelche Issues lösen und da haben wir eine Statistik und wenn du mir eine Sekunde gibst, dann finde ich die, weil ich habe, wie gesagt, ich habe die letzten Freitag vorgelesen. Genau, also wir haben

tatsächlich in den 10 Jahren von die es Cobonitis gibt, 92200 contribute gehabt, also 92000 verschiedene Menschen, die aktuell zu Cobonitis beigetragen haben und. Und aktiv sind aktuell in der org. Also die org ist quasi Leute, die regulär an dem Projekt arbeiten 1200 Leute. Ich habe jetzt im in den vergangenen Podcasts folgen ein bisschen gelernt, dass viele Projekte vielleicht ein bisschen kleinere Projekte ein oder 2 so hauptkontributoren haben, also ne, also was weiß ich beim beim beim Linux, Linux, beim Linux ist es der Linus Torwart so ne oder beim beim Git auch. Gibt es sowas auch bei Kubanitis oder ist es ich sag mal ein bisschen basisdemokratischer?

Also das witzige an der ganzen Sache ist, und das ist relativ spannend, ich glaube kubanitis ist an sich ein sehr ein sehr sehr gut aufgestelltes Projekt was Organisation und Verteilung aufgibt. Also wir hatten zum Beispiel, das ist immer wenn Qcon ist, gibt es immer den Contributor Summit, der war jetzt dann eben vorletzte Woche in Salt Lake City. Und da war es so, dass da eben alle zusammenkommen und da waren dann zum Beispiel 200, 200, contribute einfach zusammen da. Und klar, es gibt immer wieder Leute, die halt mehr contributen es gibt immer wieder Leute, die halt weniger contributen, aber es gibt im Endeffekt.

In den einzelnen Teilbereichen gibt es schon Leute, die viel machen, aber das sind in der Regel eher die, die quasi reviewen. Also wir haben sozusagen die Review, da gibt es relativ wenig Leute, die den Code, der da reinkommt oder die Beiträge, die da reinkommen, wirklich reviewen, da gibt es, das ist der kleinere Anteil, und die haben natürlich am meisten Contributions, weil durch deren Hände geht natürlich irgendwie der der ganze Code und Couponate ist selber ist organisiert in Special Interest Groups.

Und das sind quasi einzelne kleine Teilbereiche in dem Projekt. Und da drin wurschteln dann sozusagen mehrere Leute drin rum. Also da gibt es zum Beispiel Sick Networking, die sich Aussichtlich dazu beschäftigt, wie funktioniert eigentlich der Netzwerktraffic, in dem Communities, Cluster oder Sick Note, wie wird eigentlich so eine Note so eine Workernote installiert und das sind dann halt auch wieder irgendwie ein paar Leute und die kümmern sich eben genau um diesen kleinen Teilbereich. Also es gibt quasi nicht so dieses. Große Ganze, sondern es ist alles ganz viele kleine Teilbereiche und es gibt halt Six, die sozusagen über alle diese Teilbereiche drüber gehen, weil die eben zum Beispiel es gibt einen Sick Release, die

kümmert sich nur darum, dass Releases gebaut werden für Corponites. Danke für die Einblicke. Da ist ganz spannend in so einem extrem aktiven oder von so einem extrem aktiven Projekt auch mal zu hören, wie es in der Praxis läuft. Ich habe noch. Schnell ne technische Frage, die hab ich ganz vergessen.

Ja im im Bekanntenkreis sagen wir es mal so, gab es mal einen der hat aber ganz viel über Helmcharts gesprochen, ne im cubanitis Kontext kannst du mal erklären was n helmchart ist? Genau, also Helm hat erstmal nichts mit Cubanitis zu tun. Also Helm hat schon was mit Cubanitis zu tun hat gehört aber nicht zu cubanitis selber. Also Helm ist im Endeffekt nen Package Manager für Erweiterungen die du in deinem Cluster laufen lassen möchtest. Das ist halt.

Im Endeffekt kannst du das Ganze so sehen, dass du sagen kannst, hey, ich will eine mongol DB in meinem Cluster laufen haben, da müsstest du ja erst mal anfangen und sagen, Hey boah, wie baue ich denn jetzt irgendwie die mongol DB? Gibt es da irgendwie schon einen Container? Ich kann ja nicht irgendwie den normalen Container da einfach in den Cluster reinwerfen und da gibt es quasi einen Helmchart und das Helmchart ist dafür da, zum Beispiel um eine ha, um eine ha geschartete mongol DB in deinem Cluster zu installieren.

Das ist quasi wie ein Package Manager, den du auch zum Beispiel auf Linux hast. Da kannst du zum Beispiel sagen, Hey, wenn du jetzt in deinem, in deinem Linux sagen würdest, upgate install mongo DB, dann installiert er dir mongo DB und das gleiche machst du quasi mit Helm und mit Helm sagst du in Helm install mongo DB und dann installiert er dir mongo DB in deine Klasse mit rein und das ist quasi Helm.

Also als Softwareanbieter nur clever so einen Helmchart zur Verfügung zu stellen, weil ich dann als Betreiber super easy. Das entsprechende Softwareprodukt in meinen Cluster einbinden kann eigentlich ne. Ja OK, ja dann ergibt das Sinn für mich. Gut, ich bin erst mal befriedigt was mein mein mein Wissensdurst über Kubanisches angeht haben wir irgendwas noch vergessen oder Burka hast du noch irgendwas auf dem unter den Fingernägeln was was was doll brennt?

Nee, eigentlich nicht mehr. Also ich, ich glaube, ich würde tatsächlich die Frage ist, wenn man mal anfängt, und das würde ich mal machen, irgendwann auch, dann würde ich, glaube ich, auch mit so einer. Geschlossenen Version anfangen, wo ich quasi auf einer Node alles habe, die die Workplain und die und so weiter und dann würde ich mit den Yamel Files anfangen und so wahrscheinlich gibt es für alles auch schon wieder uis und so was das abstrahiert.

Es gibt ja immer abstraktionslevel, aber ich glaube ich würde es schon einmal richtig verstehen wollen und mir die ganzen Komponenten einmal angucken und auch sehen wollen, welche Container da gestartet werden von der Controlplain und so weiter und so. Corbonetis hat seine eigene. Ui, also es wird dann natürlich sehr gut passen.

Genau, es gibt quasi eine UI, dass du einfach das ist, das Dashboard, das kannst du einfach mitinstallieren und vielleicht ist das Burkhard, was du gerade gemeint hast. So noch mal so als Abschluss vielleicht so die ein guter, ein guter Ansatz. Du kannst ja im Endeffekt quleser auf deinem, auf deinem Rechner laufen lassen.

Genau. Da gibt es verschiedene Tools, da gibt es das eine ist zum Beispiel Mini Cube, dann gibt es k 3 s, womit du es laufen lassen kannst. Dann gibt es K Zero S. Dann gibt es Cubonates für Docker. Das ist, glaube ich sogar Teil von irgendwie deinem Docker Desktop Client. Kann das mit sein und ohne jetzt da irgendwie groß Werbung für zu machen? Wir haben unser eigenes Open Source Single Cluster Life Cycle Management Tool, das kannst du entweder Single Note lassen oder zurzeit kannst du es tatsächlich auch benutzen um wirklich ha zu bauen und wir machen das ganze Deklinativ das heißt Cube One. Gibt es auch im offiziellen Cubanatis Lectional als als Listing und ist auch als 1.

Der offiziellen oder als zertifiziertes Installer Tool mit gelistet auf der CNCF. Seite ich glaube, das Wichtigste ist, das fasse ich noch mal zusammen. Also ich kann es jetzt mal von meiner Perspektive aus sagen, wenn ich es mal vor hätte, jetzt auf cubanatis Umzuschwingen von unserem Docker compost plus x. Ich würde es versuchen zu verstehen, die Konzepte noch mal sehr gut zu verstehen und.

Und ich glaube, dann muss man, da muss man genau anschauen, und das hattest Du gesagt, Legacy und so weiter im Prinzip ist ja unsere Anwendung, auch wenn sie schon microservice und so weiter voll, voll modern ist und so weiter im Docker Bild ist sie schon so ein bisschen Legacy noch und wir nutzen zum Beispiel Halt, und das ist das müsste man dann rauskriegen, das wäre mein größter Knackpunkt, den ich architektonisch dann erstmal lösen müsste. Wir sind darauf angewiesen, dass wir Volumes haben, die neben den, ich sag mal in Potsdam quasi laufen und die die. Die da auch bleiben, die da gebunden sind und die dann auch wenn wenn jetzt mal der Pod umziehen würde aufeinander node müsste das Volume mit umziehen

und so weiter das sind die Dinger wo ich mir Gedanken machen müsste, weil wir nämlich keine zentrale Datenbank haben, sondern also auch, aber nicht nur, weil wir quasi auch aus Speedgründen relativ zügigen einfach Zugriff auf Volumes haben, wo wir im Prinzip Chasing Daten raus reinlesen und so weiter und ich glaube das ist wichtig, dass man wirklich.

Bevor man da überhaupt, also man muss erstmal ein bisschen spielen, um zu verstehen, was ist, ist die Architektur begreifen und dann, bevor ich überhaupt da irgendwas anfange, muss ich, glaube ich erstmal auf dem Papier oder an einem großen Whiteboard oder irgendsowas mir ein paar Gedanken machen und Voraussetzungen klar machen, wie kann ich das umziehen, weil ich schätze, dass das alles, das sind alles keine kleinen Projekte, das muss man auch schon sagen, selbst selbst wenn ich eine Anwendung habe, die noch ein alter Monolith ist und die ich mal in Docker konvertieren will, das ist alles nicht sooo schnell gemacht, man muss sich schon, wenn das effizient und performant laufen soll, muss man sich schon.

Euch n bisschen Zeit geben, alleine für die Architektur und das ist eigentlich nur mit dem Stift und also ich mach das ganz altmodisch mit dem Bleistift und Zettel ne, aber ich bin auch schon n bisschen älter. Denk auch. Also ich glaub das ist auch tatsächlich. Also Architektur ist das Wichtigste, also Architektur ist einfach wie wie funktioniert, wie funktioniert meine Applikation jetzt, wie soll sie mal funktionieren, wie ist der Weg dorthin und das das krasse ist zum Beispiel ne also wenn es jetzt zum Beispiel so Sachen gibt, es gibt ja so Applikationen die brauchen so Startupdaten.

Ne, Sie brauchen Daten, die quasi am Anfang da sind. Wenn das wenn der Container gestartet ist. Und so femeral so what's only. Und da gibt es jetzt so, da gibt es zum Beispiel Sachen, die die meisten Leute halt nicht noch nicht wissen, weil das war jetzt im letzten couponatis Release drin. Du kannst jetzt ein Docker Image als Volume attachion zu einem anderen Container der gestartet wird und dann nimmst du daraus die Daten und das ist halt ein Alpha Endpoint, der jetzt irgendwie als neuestes Feature mitgelauncht wurde, aber. Aber dadurch, dass das Halt ein Alpha Endpoint ist, benutzen das die Leute noch nicht.

Aber zum Beispiel für die Community und das ist auch immer ganz wichtig zu wissen, es gibt relativ viele Alpha und Beta Endpoints, aber nur da sind Änderungen möglich, wenn das mal stabil ist, ist eine Änderung sehr sehr viel schwerer, das heißt wenn Leute anfangen mit kombiniertes Rumzuspielen, dann spielt auch mit diesen Alpha und Beta Endpoints rum, weil da könnt ihr quasi Sachen sagen wie können wir das nicht so machen weil. Weil da, das ist das Feedback, was eigentlich so eine die cubanitis Community auch immer gerne hätte, aber nie kriegt, weil ja die Leute immer sagen, das ist Alpha, das ist Beta, das können wir ja gar nicht benutzen. Also da ist es noch jung und formbar, ja. Ich sag vielleicht auch noch was

ich, ich glaube, man kann auch sagen, dass es nicht verwerflich ist, nicht gleich mit Cubanitis anzufangen, sondern auch erstmal mit Docker Compost zu arbeiten, mit überhaupt immer diese ganze Containerwelt in den Griff zu kriegen, selber manuell, da ein bisschen was zu machen ich. Ich glaube, es gibt auch Projekte. Also ja, im Prinzip ist übernehmen das eine Art Standardisierung, ist meine mein Standardfrachter mit der Standardbrücke und so weiter da sind die Knöpfe alle klar und auch langfristig ist das vermutlich auch das Beste, aber ich würde trotzdem auch alle Softwareentwickler anregen, die so noch gar nichts mit dem Thema zu tun haben, die vielleicht nur eine ganz kleine Anwendung

haben, irgendwie diese blogspot Webanwendung, so die, die könnten ja erst mal mit Micro Services anfangen, mal in Datenbanken in Micro Service packen und dann mal einen kleinen Ingress dazu und so weiter das haben wir auch schon mal Beispiele gemacht und. Dass man Docker compose hochziehen, das vielleicht sogar mal verteilen noch 2 Server, das kann man ja mit Hetzner und so weiter gibt es ja auch sehr einfach zum Beispiel also oder auch mit anderen Hostern und da kriegt man ganz schön viel, wenn man das mal so gemacht hat.

Ich würde sagen, das ist vielleicht die für mich wäre das die Grundausbildung, ja, das muss man einmal, glaube ich, da muss man aber durchgegangen sein, ja, und dann kann man dieses, dieses krasse, weil das ist ja so eine krasse abstraktions Ebene mehr, das kann man nicht, das da passiert ja so viel im Hintergrund, du hast ja gesagt, da gibt es Leute, die sich nur im Netzwerk, das kann ich auch nicht mehr verstehen, das will ich auch nicht mehr verstehen an der Stelle aber. Aber so ein gewisses Gefühl dafür zu bekommen, was muss da passieren eigentlich, damit das funktioniert? Und ist das dann effizient oder nicht? Dafür ist, glaube ich ganz cool, irgendwie erstmal mit den kleineren Teilchen zu spielen,

bevor man groß wird. Also insofern lehne ich mich zurück, ich hoffe du siehst das genauso wie ich und wir werden irgendwann mal den kybernetischen Sprung vielleicht auch machen, aber im Moment fühle ich mich ganz wohl, ich spiele damit meinen kleinen Puzzleteilchen. Ihr wisst ja, wo ihr anrufen müsst.

Ja, genau. Ja, die letzten 3. Worte, lieber Mario, würde ich auf der D überlassen. Dürfen dich die Leute kontaktieren, wie dürfen sie dich kontaktieren oder euch oder wie findet man Chromatik verlinke ich natürlich alles in den Shownotes musst du jetzt keine Ur LS aufsagen oder so aber ja vielleicht hast du noch so einen kleinen Aufruf irgendwas zum Ende um auch noch mal auf Burkhardt einzugehen, was er gerade gesagt hat und ansonsten wär's das. Also vielen, vielen Dank, dass ich hier sein durfte. Ich habe ich hoffe ich habe alle Klarheiten beseitigt. Schön gesagt.

Und genau also ich sehe es auch so, das sind alles Schritt für Schritt, keiner fängt irgendwie sofort bei dem Containerschiff an, es gibt eben die die einzelnen Schritte, die man nach und nach machen sollte für dieses ganze komponiertes Thema. Was immer ganz hilfreich ist, ist auch wenn man bei Docker ist, weniger über die GUI machen, einfach mehr über Files machen, über die CLI machen, weil das ist da wo man es im Endeffekt lernt und das ist dann, wo man auch Infrastructure als Code am Ende machen kann, dass eben alles nachvollziehbar ist. Ich glaube, das ist so das das Wichtigste worauf man immer achten sollte, ansonsten immer gerne rumprobieren, alle Open Source Projekte dieser Welt

freuen sich A entweder über contributions oder. Eine Contribution vielleicht nicht aber, sondern eine Contribution ist auch tatsächlich einfach Feedback zu einem Feature oder irgendwie einem Wunsch, was irgendwie nicht funktioniert, wenn ihr da irgendwie einfach ein bisschen Zeit nehmt, jeden, jeden Contributor, jeden Maintainer freut es, wenn ihr von außen irgendwie Input bekommt, das hilft. Und man findet mich auf linkedin am besten zum Anschreiben oder auf Blue Sky und Twitter und Cubomatic eben ganz normal im Netz oder untergithub.com Slash Cubomatic cool, weil alle unsere Produkte sind Open Core.

Alles klar wird verlinkt. Ich bedanke mich ganz herzlich. Auch im Namen der der Hörerinnen und Hörer. Ja, ich glaube, es war ein richtig cooler erster Einblick in cubanitis ich glaube, man kann noch mal deepdives machen, sicherlich für jede einzelne dieser Komponenten, aber erstmal haben wir einen Überblick bekommen, was die Technik angeht und auch ja die die Art und Weise, wann und wie es eingesetzt werden kann. Also vielen Dank.

Gerne. Ja, von meiner Stelle auch. Vielen dank Mario und viel Erfolg weiterhin. Schön, dass du dich so engagierst für diese. Open Source Open Core ein Projekt ist nicht gut, es trägt die Softwareentwicklung weltweit weiter. Es braucht immer Leute, die sowas machen, vielen dank und dann sage ich Tschüss aus Hamburg, Tschüss.

Einfach komplex wird präsentiert und produziert von Heise mehr. Wir freuen uns auf deine Fragen und deinfeedbackanpodcast@heisemehr.com vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.

0:00 / 0:00