Von der Revolution zur Reife: Kubernetes heute

Voiceover: Hallo und herzlich willkommen bei Digital Future, dem Podcast zu Technologie

Voiceover: und Unternehmenskultur.

Voiceover: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei inovex.

Voiceover: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Voiceover: aus verschiedenen Blickwinkeln kennengelernt.

Voiceover: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Voiceover: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Voiceover: vorzustellen und mich mit ihr oder ihm über das jeweilige Fachgebiet zu unterhalten.

Voiceover: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Voiceover: In der heutigen Folge spreche ich mit meinem Kollegen Maximilian Bischoff.

Voiceover: Er ist schon lange im Bereich Kubernetes unterwegs und ja, das ist auch das

Voiceover: Thema unserer heutigen Folge.

Voiceover: Kubernetes ist mittlerweile ja schon über zehn Jahre alt und sehr weit verbreitet.

Voiceover: Wir sprechen heute darüber, was der aktuelle Stand ist. Ist das System vielleicht

Voiceover: schon ausentwickelt oder gibt es noch viele Innovationen und Weiterentwicklungen?

Voiceover: Und natürlich habe ich Maximilian auch gefragt, welche Rolle KI bei Kubernetes

Voiceover: spielt. Und jetzt wünsche ich euch viel Spaß beim Zuhören.

Wolfgang: Hi Maximilian, schön, dass du da bist. Ich freue mich auf unser Gespräch.

Wolfgang: Aber bevor wir in die Wunderwelt der Operations abtauchen, würde ich mich freuen,

Wolfgang: wenn du dich einfach mal kurz vorstellst. Wer bist du?

Wolfgang: Seit wann bist du schon bei InnoVax und was machst du so den lieben langen Tag bei uns?

Gast: Ja, hi Wolfgang. Schön, dass ich eingeladen wurde von dir.

Gast: Ich bin Maximilian, das wisst ihr jetzt schon.

Gast: Und ich bin hier bei InnoVax seit fast sieben Jahren jetzt mittlerweile.

Gast: Ich glaube, im April sind sieben Jahre als Cloud-Plattform-Engineer tätig.

Gast: Was heißt das? Es ist immer ein bisschen unterschiedlich, kommt so ein bisschen

Gast: auf das Projekt und den Kunden an.

Gast: Aber im Großen und Ganzen bin ich eben im Cloud-Bereich unterwegs.

Gast: Viele Themen, wo es darum geht, Kubernetes zu betreiben, zumindest in der Vergangenheit.

Gast: Das wird jetzt immer weniger.

Gast: Da kommen wir bestimmt auch nochmal drauf zu sprechen. Und heute ist mehr Entwicklung

Gast: auf Kubernetes oder Plattformbau auf Kubernetes.

Wolfgang: Ja, und Kubernetes ist ein gutes Stichwort, denn da wollen wir uns heute mal drüber unterhalten.

Wolfgang: Ich habe mich schon mal mit jemand anderem hier im Podcast, ich glaube,

Wolfgang: vor so drei Jahren über Kubernetes unterhalten.

Wolfgang: Und ich glaube, es wird mal wieder Zeit, über das Thema zu sprechen.

Wolfgang: Denn da ist, glaube ich, viel passiert und mich würde vor allem interessieren,

Wolfgang: was ist denn der heutige Stand beim Thema Kubernetes?

Wolfgang: Aber Maximilian, wer mich kennt, weiß, dass ich auch ein ganz,

Wolfgang: ganz großer Freund von kleinen Zeitreisen bin.

Wolfgang: Und deswegen würde ich mit dir mal ganz kurz gerne in die Vergangenheit reisen.

Wolfgang: Und vielleicht können wir ja mal ganz kurz die kurze Geschichte von Kubernetes durchgehen.

Wolfgang: Du arbeitest schon länger mit Kubernetes. Vielleicht kannst du mich da mal so

Wolfgang: ein bisschen aufschlauen.

Wolfgang: Wo kommt Kubernetes her und wie lange kennen wir das jetzt eigentlich schon?

Gast: Also man muss dazu sagen, mein Einstieg mit Kubernetes war so 2017,

Gast: würde ich schätzen, für meine Bachelorarbeit.

Gast: Müsste ich jetzt auch nochmal selber gucken, wann das genau war. Aber sagen wir mal 2017,

Gast: damals noch in der Google Cloud ein bisschen GKE-Cluster geklickt,

Gast: um mein Zeugs zu deployen und tiefer mit beschäftigt dann quasi erst auch in den folgenden Jahren.

Gast: Aber die Anfänge sind so 2014, 2015 rum gewesen, dass Google eben dieses Projekt veröffentlicht hat.

Gast: Und die Geschichte dazu, die kann man auch ganz gut nachlesen in vor allem zwei

Gast: Papern rund um Borg, Omega und Kubernetes, die Google auch veröffentlicht hat.

Gast: Die Geschichte dazu ist quasi, Google hatte schon fast seit Anfangszeiten ihr

Gast: eigenes Tooling am Laufen, denn Google hatte ja immer das Problem,

Gast: sie haben halt viele Rechner.

Gast: Vielleicht kennt ihr auch die Geschichte, dass sie ihr Rechenzentrum quasi auf Pappe gebaut haben.

Gast: Also die hatten keine Serverschränke, weil das war zu teuer,

Gast: sondern die hatten halt Consumer-Hardware gekauft.

Wolfgang: Ja, die Geschichte kenne ich. Da gibt es auch so Bilder, wo man dann wirklich

Wolfgang: diese ganzen Consumer-Geräte halt einfach sieht.

Gast: Genau, ja. Und dann eben natürlich auch viele Programme, die da drauf laufen müssen.

Gast: Also Suchindexen suchen natürlich auch beantworten oder Suchanfragen beantworten.

Gast: Ja, genau. Und um das alles eben hinzubekommen, haben sie ihr eigenes Tooling geschrieben.

Gast: Und dieses Tooling, das nennen sie heute zumindest Borg und das ist quasi ein

Gast: großer Scheduler, hat also erstmal eine ähnliche Funktion wie Kubernetes,

Gast: nämlich ich habe hier Prozesse, ich habe Aufgaben, die irgendwo ausgeführt werden

Gast: müssen und die möchte ich jetzt auf Rechner verteilen und die brauchen vielleicht

Gast: noch ein paar Dinge zusätzlich,

Gast: noch ein bisschen Speicher oder Netzwerkanbindung und das alles eben muss geleistet

Gast: werden und das ist bei denen wohl auch intern historisch gewachsen.

Gast: Bis sie halt irgendwann gesagt haben, boah, jetzt haben wir schon ein paar Probleme

Gast: und ein paar Herausforderungen, die würden wir gerne lösen. Implementieren wir es doch neu.

Gast: Und du weißt ja wahrscheinlich, Wolfgang, aus deiner Erfahrung,

Gast: es ist immer eine gute Idee, von null anzufangen, alles neu zu implementieren.

Wolfgang: Ja, natürlich. Greenfield-Development.

Gast: Ja, genau. Macht am meisten Spaß. Machen wir gerne. Wurde dann im Endeffekt nicht so ganz was.

Gast: Also sie hatten ein paar gute Ideen. Sie haben quasi auch ein neues Tool entwickelt.

Gast: Und dieses Tool, das wissen wir jetzt eben heute, wurde Kubernetes im Endeffekt.

Gast: Aber es war dann doch nicht so praktikabel, Borg komplett zu ersetzen durch

Gast: Kubernetes. Wer hätte es gedacht?

Gast: Stattdessen haben sie dann eben die besten Ideen, die sie entwickelt haben in

Gast: dieser Neuentwicklung oder die sie gefunden haben bei der Neuentwicklung,

Gast: zurückimplementiert nach Borg.

Gast: Und dann hatten sie ja noch so eine Codebase, ursprünglich mal noch in Java geschrieben.

Gast: Und diese Codebase wurde eben Kubernetes. Und da haben sie dann entschieden, wir Open-Sourcen das.

Wolfgang: Ja, und das war dann so 2014, hast du gesagt.

Gast: Ich meine 2014 oder 2015.

Wolfgang: Ja. Also zum Zeitpunkt der Aufnahme heute liegt das auch schon so rund zehn Jahre zurück.

Wolfgang: Und da ist dann viel passiert. Also gerade von diesen Problemen sprachst,

Wolfgang: dass es doch nicht so einfach war, das System jetzt komplett abzulösen.

Wolfgang: Da musst du natürlich an die ganzen Systeme denken, die heute noch in Betrieb

Wolfgang: sind, wo auf Basis von COBOL laufen, wo man ja auch immer wieder mal versucht

Wolfgang: hat, irgendwas abzulösen.

Wolfgang: Und ich kenne das aus dem Befreundeskreis, da arbeiten ein paar Leute im Bereich Finanzen,

Wolfgang: wo noch alte Kobold-Systeme am Start sind, wo dann auch immer mal versucht wurde,

Wolfgang: was zu erneuern und was abzulösen und es dann doch nicht so 100 Prozent funktioniert hat.

Gast: Ja, kostet auf jeden Fall viel Zeit und man hat natürlich die Gefahr,

Gast: viel Wissen zu verlieren.

Wolfgang: Absolut.

Gast: Ich glaube, der Vorteil für jetzt Projekte wie Kubernetes ist,

Gast: dass sie nicht ganz so businessspezifisch sind.

Gast: Und das ist wahrscheinlich auch der Grund, warum sie dann eben entschieden haben,

Gast: jetzt open sourcen wir das Tool, haben dem Ganzen natürlich dann auch nochmal Namen geben müssen.

Gast: Das war wohl auch ein längerer Prozess, bis das eben bei den Google-internen

Gast: Prozessen dann durchging.

Gast: Ja, und dann haben sie es auch nochmal neu geschrieben. Das wissen wahrscheinlich

Gast: auch viele Leute, die die Code-Basis mal gesehen haben.

Gast: Es ist ja mittlerweile in Golang geschrieben. Das heißt, diesen ganzen Java-Code

Gast: haben sie eben auch nochmal umgeschrieben nach Golang.

Wolfgang: Go ist aber auch von Google, oder? Wurde, glaube ich, auch damals entwickelt

Wolfgang: bei Google ungefähr zu der Zeit?

Gast: Auch hier habe ich die genaue Jahreszahl natürlich nicht parat,

Gast: aber kommt grob aus der gleichen Zeit.

Gast: Also in der Zeitlinie kann man noch sagen 2013 ist das Jahr,

Gast: wo Docker so durch die Decke ging.

Gast: Ich glaube auch tatsächlich offiziell released wurde und dieser ganze Trend

Gast: ist dann offensichtlich auch ziemlich schnell losgerollt.

Wolfgang: Und jetzt für alle Leute, die vielleicht gar nicht so ganz genau wissen,

Wolfgang: was Kubernetes ist, wie würdest du Kubernetes in so zwei, drei Sätzen beschreiben?

Gast: Und Kubernetes ist auf jeden Fall ein Scheduler, also erstmal ein Tool,

Gast: um eben Prozesse auf Rechner zu verteilen.

Gast: Und aber auch ein Management-Tool, also eine Management-Ebene,

Gast: um eben diesen ganzen Prozessen, die ganzen Dinge zu geben, die sie so drumherum noch brauchen.

Gast: Also ein bisschen konkreter, wir haben eigentlich keine Prozesse,

Gast: sondern Container als Einheiten, die verteilt werden in Kubernetes.

Gast: Und diese Container, die brauchen eben manchmal noch ein bisschen Storage,

Gast: dafür gibt es Integration, die brauchen eine Netzwerkanbindung,

Gast: das ist quasi ein Kernteil, den jedes Kubernetes-Cluster leisten muss.

Gast: Genau, kann aber auch eben noch mehr Funktionen dann drumherum kommen.

Gast: Der Kern bei Kubernetes ist eigentlich die API und über diese API läuft eben alles.

Gast: Genau, und darüber lassen sich die Funktionen eben auch erweitern,

Gast: die man so im Cluster hat. Und Grundfunktionen, die man dann eben über,

Gast: ich habe hier einen Container am Laufen, haben kann, sind dann so Themen wie

Gast: Autoscaling zum Beispiel.

Wolfgang: Also das heißt jetzt, um es mit meinen einfachen Worten vielleicht so zusammenzufassen,

Wolfgang: ich habe ein Rechenzentrum und da steckt ein Haufen Hardware drin.

Wolfgang: Auf der einen Seite Storage, auf der anderen Seite aber auch klassische Compute-Hardware.

Wolfgang: Und ich habe jetzt verschiedene Anwendungen vielleicht, die ich darauf laufen lassen möchte.

Wolfgang: Und Kubernetes kümmert sich darum, dass meine Anwendungen, die in einzelnen

Wolfgang: Containern stecken, da optimal verteilt werden.

Wolfgang: Ich kann noch Vorgaben machen, wie ich möchte eine gewisse Redundanz vielleicht

Wolfgang: haben. Ich möchte sowas wie Autoscaling haben, was wir auch von den großen Hyperscalern kennen.

Wolfgang: Und im Idealfall läuft das alles automatisch. Ich muss mich nicht darum kümmern,

Wolfgang: wenn so ein Container abstürzt, wird er neu gestartet, wenn da mehr Ressourcen

Wolfgang: irgendwie benötigt werden, werden die bereitgestellt etc.

Wolfgang: Und das ist quasi vielleicht so diese Idealvorstellung von Kubernetes.

Gast: Genau, ja. Die Idealvorstellung trifft es auch ganz gut. Gerade so der letzte

Gast: Punkt, den du genannt hast mit, wenn ich mehr Ressourcen brauche,

Gast: werden die bereitgestellt.

Gast: Wenn wir eben mehr Cluster-Ressourcen wollen, dann brauchen wir hier zum Beispiel

Gast: schon wieder eine Integration, die halt auch mehr Rechner im Endeffekt dazustellt, also Server oder VMs.

Gast: Und da ist eben so, Kubernetes beschäftigt sich an sich recht wenig mit den Rechnern.

Gast: Also ihr müsst das quasi auf jeder VM jetzt in eurem Cluster,

Gast: auf jedem Node würde man in Kubernetes-Sprech sagen, eben Kubernetes erstmal

Gast: selbst installieren und vorkonfigurieren. Da gibt es auch wieder Tooling in

Gast: X-Varianten für, aber das müsst ihr eben erstmal stellen.

Gast: Und dann ab dem Moment, wo ihr eine Node im Cluster habt, kümmert sich Kubernetes

Gast: überhaupt erst um Themen.

Gast: Sprich, diesen Prozess, wie kriege ich denn jetzt eine Node ins Cluster,

Gast: wenn mein Cluster voll ist, der ist halt wieder ein Plugin.

Wolfgang: Aber es ist natürlich praktisch, wenn ich jetzt einfach in sehr großen Dimensionen

Wolfgang: unterwegs bin und beispielsweise wirklich im Rechenzentrum da 1000 Server stehen

Wolfgang: habe oder 1000 Nodes stehen habe und dann muss ich mich halt nicht wirklich

Wolfgang: die ganze Zeit um jeden einzelnen Knoten kümmern, sondern ich sorge dafür,

Wolfgang: dass die dann eben im Cluster sind, dass da irgendwie mein Kubernetes-Agent

Wolfgang: drauf läuft und Kubernetes an sich managt mir dann so alles.

Gast: Alles auf dem Knoten, ja.

Wolfgang: Alles auf dem Knoten, ja.

Gast: Wenig, aber alles auf dem Knoten, ja.

Wolfgang: Okay, cool. Ja, sag mal, wir haben jetzt 2025 und wir haben ja gerade schon

Wolfgang: darüber gesprochen, dass wir jetzt Kubernetes so seit roundabout zehn Jahren

Wolfgang: da draußen haben in Produktion.

Wolfgang: Wo stehen wir denn da heute? Ist das der große Standard oder gibt es da nebendran

Wolfgang: noch andere Systeme, die was ähnliches leisten?

Gast: Also es gibt schon Konkurrenz sozusagen. Mitbewerber könnte man auch sagen.

Gast: Zum Beispiel von HashiCorp gibt es Nomad, was eigentlich erstmal die gleichen

Gast: Ziele und Ideen wie Kubernetes verfolgt.

Gast: Also auch wir haben eine API im Kern, die uns eben ermöglicht,

Gast: Anwendungen, die containerisiert sind, auf mehreren Maschinen zu managen.

Gast: Hat dann aber als Grundprinzip, dass die Komponenten von Nomad erstmal ein bisschen einfacher gebaut sind.

Gast: Also die Idee von HashiCorp war, glaube ich, schon zu sagen,

Gast: wir nehmen jetzt Kubernetes so vom Konzept her, aber wir machen es halt einfacher auch zu managen.

Gast: Genau, also das wäre Konkurrenz. Das haben sich auch Kollegen immer mal wieder angeschaut.

Gast: Man merkt dann aber doch recht schnell, dass halt Kubernetes der Platzhirsch ist. Ja.

Gast: Genau, und eben auch am meisten Integration hat, dass es viele Tools gibt,

Gast: die eben für Kubernetes geschrieben wurden, die auf Kubernetes laufen,

Gast: wo wir dann halt auch schon fertige Konfigurationen fürs Deployment und so kriegen.

Gast: Und dass es das halt schon schwierig macht, auf ein Alternativsystem zu gehen.

Wolfgang: Das heißt aber, Nomad ist kein Fork oder so, sondern eine komplett eigenständige Codebasis?

Gast: Genau, also Nomad ist erstmal stark getrennt von Kubernetes und wenn wir dann

Gast: Richtung Fork schauen wollten,

Gast: wäre es dann wahrscheinlich am ehesten OpenShift von Red Hat,

Gast: was eben grob auch erstmal Kubernetes mit ein paar Standard-Add-ons ist.

Gast: Zumindest soweit mein Verständnis immer. Ich selber hatte noch kein OpenShift-Projekt.

Gast: Aber im Prinzip unter der Haube haben wir erstmal Kubernetes.

Gast: Wir haben halt einige Dinge, die uns schon mehr gestellt werden von OpenShift.

Gast: Also sowas wie eine Prometheus-Integration oder ein Standard-Increase-Controller

Gast: sind eben Dinge, die OpenShift schon mitbringt.

Gast: Aber an sich ist sonst eben einfach immer noch Kubernetes.

Wolfgang: Das heißt, Red Hat hat da quasi so eine eigene, in Anführungszeichen,

Wolfgang: Distribution geschnürt geschnürt, wo noch vielleicht auch Red Hat spezifische Sachen dabei sind.

Gast: Genau, also eine eigene Distro trifft es, glaube ich, ganz gut.

Wolfgang: Das heißt, wenn man jetzt aus irgendwelchen Gründen im Red Hat Universum gefangen

Wolfgang: ist, dann wäre das so die Weapon of Choice, die man wählt.

Gast: Ja, ich glaube vor allem, wenn man schon Tools von denen hat,

Gast: dann macht das vielleicht Sinn.

Gast: Und ich meine, von der Grundidee eben zu sagen, wir geben dir schon ein paar

Gast: mehr Standardkonfigurationen mit, auch Richtung User Management,

Gast: hat OpenShift schon ein bisschen was dabei.

Gast: Das ist natürlich erst mal ganz schick, weil viele Dinge bauen wir halt auch

Gast: immer wieder selbst, wenn wir Kubernetes selbst machen.

Gast: Ich glaube aber tatsächlich auch, Kubernetes ist jetzt gar nicht mehr auf der

Gast: Ebene, wo wir sagen, gibt es hier Konkurrenz, es ist die einzige Wahl,

Gast: sondern Kubernetes ist eher wie Linux geworden.

Gast: Es ist eine Art Körnel und dann hast du ja auch schon gesagt,

Gast: OpenShift wäre eine Distro, wie jetzt Ubuntu oder Debian oder sowas.

Gast: Und ich glaube, auf der Ebene sind wir langsam mit Kubernetes gelandet.

Gast: Also die API ist ziemlich Standard, wir haben viel Tooling, was damit integriert.

Gast: Aber, genau, wir nutzen halt eigentlich nicht mehr Kubernetes selbst.

Gast: Also wir bauen nicht unser eigenes Kernel und installieren unseren eigenen Package

Gast: Manager obendrauf, sondern wir nehmen halt entweder OpenShift oder man managt

Gast: Kubernetes in der Public Cloud.

Gast: Da gibt es ja auch genug Angebote, eben von den drei großen auf jeden Fall.

Gast: Aber auch die kleineren Cloud Anbieter ziehen da ziemlich nach.

Wolfgang: Okay. Ja, sag mal, was sind denn da aus deiner Perspektive so die großen Argumente

Wolfgang: für und gegen Kubernetes?

Wolfgang: Und zwar jetzt nicht allgemein, sondern so projektspezifisch.

Wolfgang: Denn wir machen ja Projektarbeit für unsere Kunden und unsere Kundenprojekte

Wolfgang: sind ja alle schon unterschiedlich.

Wolfgang: Wir haben durchaus Kunden, wo dann sehr viel in der Cloud oder irgendwo läuft,

Wolfgang: also wo viele Applikationen laufen, wo man vielleicht hochskalierbar sein muss.

Wolfgang: Wir haben natürlich aber auch Kunden, wo es dann eher Anwendungen gibt,

Wolfgang: die jetzt nicht so skalieren müssen, wo es vielleicht auch gar nicht irgendwie

Wolfgang: eine Million Concurrent User gibt, weil es eine interne Applikation ist.

Wolfgang: Und da frage ich mich immer, wie kann ich denn beurteilen, ob Kubernetes jetzt

Wolfgang: die richtige Lösung ist für diese Herausforderung oder ob es vielleicht auch

Wolfgang: eine Stufe kleiner geht.

Wolfgang: Also ich meine, auf dem einen Ende der Skala, da haben wir vielleicht irgendwie

Wolfgang: die VM und da läuft eine Applikation drauf und gut.

Wolfgang: Auf dem anderen Ende der Skala haben wir vielleicht sowas wie Kubernetes,

Wolfgang: wo man sehr viele Freiheiten hat, sehr viel Flexibilität hat.

Wolfgang: Aber das kommt natürlich auch mit einem Preis.

Wolfgang: Und da würde mich natürlich von dir interessieren, du hast da viel Erfahrung in dem Bereich.

Wolfgang: Wie kann man es denn so ausloten, ob es eine gute oder schlechte Idee ist?

Gast: Ja, ist gar keine so leichte Frage.

Wolfgang: Ja, deswegen stelle ich es.

Gast: Genau, das ist glaube ich auch die Frage, die uns mehr oder weniger jeder Kunde

Gast: stellt, der noch am Anfang steht eben in dieser Entscheidung.

Gast: Ich würde sagen, wenn man nicht wüsste, warum man es braucht,

Gast: dann braucht man es vielleicht auch einfach nicht.

Wolfgang: Gute Antwort.

Gast: Ganz stumpf geantwortet, ja. Ich glaube, wenn man eine Anwendung hat und man

Gast: möchte die deployen, dann kann man mit hundertprozentiger Sicherheit sagen,

Gast: Kubernetes ist nicht die richtige Wahl.

Gast: Und ich glaube andersrum, wenn du zehn Teams hast, die Microservices machen,

Gast: die vielleicht dann nochmal jeder Team fünf Microservices haben und du möchtest

Gast: da ein bisschen standardisieren, wie die Sachen laufen, dann ist Kubernetes

Gast: eine ziemlich gute Wahl.

Gast: Und dazwischen wird es halt kniffliger.

Wolfgang: Das heißt, dass man bei einer hohen Komplexität von meiner Applikationslandschaft,

Wolfgang: wenn ich jetzt sehr viele Microservices habe,

Wolfgang: dann hat man da schon eine gewisse Komplexität, dass dann Kubernetes sicherlich

Wolfgang: eine gute Entscheidung sein kann.

Wolfgang: Aber beim klassischen Monolithen oder bei einer sehr kleinen Anwendung,

Wolfgang: wie mein Beispiel hier im Podcast, ist immer mein Online-Shop,

Wolfgang: wo ich meine Fahrräder verkaufe,

Wolfgang: wo ich vielleicht irgendeine eShop-Lösung habe, die möchte ich selber hosten.

Wolfgang: Da wäre es dann wahrscheinlich keine gute Idee, sowas wie Kubernetes zu nehmen,

Wolfgang: weil dadurch ja die Komplexität nochmal enorm steigt.

Gast: Ja, würde ich auf jeden Fall sagen. Also ich meine, die Komplexität,

Gast: die verschwindet natürlich nicht, wenn ich jetzt zum Beispiel Managed Containers

Gast: as a Service von Azure oder so nehme.

Gast: Die schwindet halt einfach nur woanders hin. Also im Zweifelsfall muss ich da

Gast: mit dem Azure Support sprechen, wenn sich irgendwas nicht so verhält,

Gast: wie ich es erwarte. Oder deren Doku lesen.

Gast: Aber keine Ahnung, wenn du jetzt sagst, ich bin eigentlich ganz firm hier mit

Gast: VMs. Ich habe hier zwei VMs rumstehen bei Hetzner.

Gast: Die betreibe ich schon seit zehn Jahren für meinen Mail-Server,

Gast: dann schmeiß es doch einfach da drauf.

Gast: Und wenn dein Shop auch mal im schlimmsten Fall eine Stunde offline sein darf, dann passt es ja.

Gast: Also ich meine, was will man da noch groß? Dann brauchst du kein Autoscaling,

Gast: da brauchst du nicht viel Redundanz.

Gast: Wenn du jetzt nicht Millionen von Kunden hast, die da am Black Friday gleichzeitig

Gast: darauf anstürmen, dann wird es der Web-Server auch abhaben können.

Wolfgang: Okay, verstanden. Was mich jetzt aber noch interessieren würde,

Wolfgang: wäre, wenn ich mich dazu entscheide,

Wolfgang: auf Kubernetes zu setzen, weil ich habe eine komplexe Applikationslandschaft,

Wolfgang: wie mache ich es denn dann am besten fest, ob ich jetzt sowas selbst betreibe,

Wolfgang: also im Rechenzentrum selbst Kubernetes installiere oder von so einem Profi

Wolfgang: wie dir installieren lasse oder ob ich jetzt so eine Managed Kubernetes-Lösung

Wolfgang: bei einem von den drei großen Hyperscalern wähle.

Gast: Ja, also die meisten unserer Kunden wissen das quasi schon, wenn sie zu uns

Gast: kommen, weil die sind vielleicht schon in einem Cloud-Provider-Ökosystem ziemlich viel unterwegs.

Gast: Sie haben vielleicht schon ein paar Datenbanken in Managed Form,

Gast: also Managed Postgres oder sowas bei Azure oder was auch immer.

Gast: Und dann macht es vielleicht auch einfach Sinn, auf diesem Cloud-Provider zu

Gast: bleiben, weil es halt auch oft ein paar schicke Integrationen gibt.

Gast: Zum Beispiel eben die Möglichkeit, heißt meistens Workload Identity oder so.

Gast: Halt ein Cloud Provider Credential, also mit dem sich meine Anwendung bei dem

Gast: Cloud Provider eben bei den APIs anmelden kann, direkt im Cluster hinterlegen zu lassen.

Gast: Das funktioniert dann mehr oder weniger magisch. Zum Beispiel bei Google funktioniert

Gast: das so, ich habe halt in meinem Google Kubernetes Engine Cluster ein Pod am

Gast: Laufen, also ein Container am Laufen im Endeffekt einfach.

Gast: Da möchte ich mit irgendeinem SDK sprechen und wenn ich das dann eben einmal

Gast: konfiguriert habe, dass dieser Container diese Identität haben soll,

Gast: dann läuft da ein bisschen Zauberei im Hintergrund.

Gast: Also ich glaube konkret ein Proxy, der halt diese Authentifizierung für einen

Gast: übernimmt und der kriegt dann eben das Credential und so weiter.

Gast: Also da handhabe ich gar nicht mehr irgendwelche Access-Keys oder irgendwas,

Gast: sondern das wird für mich automatisch gelöst.

Gast: Sowas ist natürlich ganz schick. Und allgemein natürlich, wenn der Kunde schon

Gast: einen Rahmenvertrag hat, auch aus Kostengründen, das ist wahrscheinlich so das

Gast: Nummer 1 Argument, wird der halt beim Cloud Provider bleiben.

Gast: Wenn du jetzt aber, Wolfgang, zufällig in deinem Keller ein Rechenzentrum stehen

Gast: hast und du weißt vielleicht, es soll sich nicht viel damit anzufangen oder

Gast: du möchtest es vielleicht auch einfach besser nutzen für dich.

Gast: Dann würde ich schon sagen, dass man da auch Kubernetes drauf betreiben kann.

Gast: Es sollte einem halt klar sein, wenn ich Services habe, zum Beispiel,

Gast: die 24-7 verfügbar sein sollen, dann muss ja auch meine Kubernetes-Plattform 24-7 verfügbar sein.

Gast: Und ich kann die Kubernetes-Plattform halt nicht noch nebenbei von einem Entwicklerteam

Gast: mitmanagen lassen, sondern ich brauche da schon ein paar Leute,

Gast: die sich richtig gut mit auskennen und sich da auch reinfuchsen.

Gast: Eben weil ich es ja auch selber betreibe in dem Fall.

Gast: Und dann sprechen wir schon wieder von acht oder zehn Leuten,

Gast: die wir brauchen, wenn wir auch noch 24-7-On-Call und alles haben wollen.

Gast: Also es sind natürlich enorme Kosten, kann sich aber schon rentieren,

Gast: wenn du entsprechend viel Hardware brauchst, die ja der Cloud-Provider auch

Gast: mit einem großen Preis-Premium rausgibt.

Gast: Dann kann sie das schon rentieren.

Wolfgang: Ja, das ist eine gute Frage, denn ich habe auch so festgestellt,

Wolfgang: vor ein paar Jahren gab es ja diesen großen Boom, dass alle Leute in die Cloud sind.

Wolfgang: Und die Hyperscaler waren immer so die erste Adresse für ein neues Projekt.

Wolfgang: Und ich glaube, ein häufiges Argument war vor allem, dass du halt mit niedrigen

Wolfgang: Onboarding-Kosten durchstarten kannst.

Wolfgang: Du musst nicht irgendwelche Leute finden und ausbilden, musst keine Hardware kaufen etc.

Wolfgang: In der letzten Zeit sehe ich aber durchaus, ich möchte nicht sagen Trend,

Wolfgang: aber so eine kleine Bewegung vielleicht,

Wolfgang: dass Leute wieder aus der Cloud rausgehen und ich glaube das bekannteste Beispiel

Wolfgang: ist wahrscheinlich 39 Signals, das ist ein Softwareunternehmen,

Wolfgang: die machen unter anderem so eine Projektmanagementsoftware,

Wolfgang: die haben oder ich glaube der Chef von denen hat einen Blogartikel geschrieben

Wolfgang: vor ein paar Monaten, wo er irgendwie geschrieben hat, naja sie sind jetzt rausmigriert

Wolfgang: von der Cloud, ganz normal ins Rechenzentrum und sie sparen jetzt irgendwie.

Wolfgang: Wie so eineinhalb Millionen Dollar im Jahr, weil es halt teurer war.

Wolfgang: Vielleicht oder mutmaßlich, weil die Rabatte abgelaufen sind,

Wolfgang: wo manche Hyperscaler ja schon ordentlich reingelangt haben,

Wolfgang: was Rabatte anging, sodass du eigentlich keine Chance hattest, Nein zu sagen.

Gast: Ja, ich glaube, das hat sich auch ein bisschen entwickelt in den letzten Jahren.

Gast: Also zwei Punkte vielleicht. Das eine ist ja das Onboarding-Thema,

Gast: was du angesprochen hast.

Gast: Da ist natürlich immer die Frage, wenn ich jetzt Entwickler habe,

Gast: die direkt mit der Cloud-AP arbeiten sollen oder direkt mit dem Cloud-Provider,

Gast: wie viel Wissen sammeln die da wirklich an?

Gast: Also ist das halt was, was sie zwangsweise nebenbei machen oder können die das

Gast: danach sozusagen auch wirklich?

Gast: Also kann man jetzt sagen, okay, ich habe hier einen AWS-Experten,

Gast: in Anführungsstrichen, der eigentlich halt 90 Prozent seiner Zeit Backend gemacht

Gast: hat. Und dann kommt er ins nächste Projekt und dann versteht er genau, was dort passiert.

Gast: Ich würde ja sagen, oft sind es halt eben eher die Architektursachen oder die

Gast: kleinen Details, die man sich halt wieder anschauen muss.

Gast: Auf der Gegenseite für dieses Onboarding-Thema oder dieses überhaupt Dinge-die-ploinen-Können-Thema

Gast: sehe ich halt auch so diese klassische IT-Welt, die ich tatsächlich auch erlebt

Gast: hatte schon in meinem Nebenjob während dem Studium,

Gast: wo man halt VMs anfragen musste per Ticket bei der IT,

Gast: dann hat man die halt mit ein bisschen Glück schon einen Tag später bekommen,

Gast: aber vielleicht auch erst ein, zwei Wochen später.

Gast: Und da ist natürlich so ein Hyperscaler schon geil, weil ich kriege halt einen

Gast: Haufen Services auch von höherer Komplexität, sage ich mal, eben wie so eine

Gast: Datenbank oder S3 oder irgendwie sowas.

Gast: Einfach per Klick oder per Terraform, wenn ich es vielleicht noch ein bisschen

Gast: selber managen können möchte mit den ganzen Prozessen drumherum.

Wolfgang: Ja, und du hast aber auch solche Features dabei, wie so Georedundanz. etc.

Wolfgang: Das habe ich halt in meinem Rechenzentrum nicht. Wenn da irgendwas kaputt geht,

Wolfgang: sind meine Daten weg und wenn ich halt Georedundanz haben möchte,

Wolfgang: wie es vielleicht bei S3, dann kostet es mich natürlich auch wieder viel, viel Geld.

Wolfgang: Wahrscheinlich gibt es keine einfache Antwort drauf.

Gast: Ja, ich denke, es hat sich vielleicht ein bisschen geändert auch in den letzten Jahren.

Gast: Heute ist halt die einzige Alternative zur AWS nicht meine eigene IT mit Ticketbetrieb,

Gast: sondern es könnte auch sein, meine IT stellt mir halt eine OpenStack Cloud.

Gast: Und was jetzt von der Qualität her vielleicht nicht genau dasselbe ist,

Gast: aber trotzdem im Endeffekt auch eine API und eine UI, mit der ich sprechen kann,

Gast: mit der ich mir selber Ressourcen provisionieren kann, mit der ich auch sowas

Gast: wie Autoscaling bauen kann,

Gast: Loadbalancer kriege und S3 kriege und alles Mögliche.

Gast: Also auch das hat sich natürlich ein bisschen geändert. Also ich glaube,

Gast: es ist viel praktikabler, heute im eigenen Rechenzentrum sich auch Services

Gast: auf einem höheren Level aufzubauen oder schon mal, ich sag mal,

Gast: schenken zu lassen, in Anführungsstrichen, weil im Endeffekt betreibt es ja trotzdem noch jemand.

Gast: Aber das eben quasi zu kriegen ohne viel Aufwand, als es vor zehn Jahren jetzt zum Beispiel war.

Wolfgang: Ja, Maximilian, wie sieht denn das eigentlich heute aus, wenn man in diesem

Wolfgang: Kubernetes-Umfeld arbeitet?

Wolfgang: Du bist Cloud-Plattform-Engineer, wenn ich es mir richtig gemerkt habe.

Wolfgang: Wie sieht denn so dein Alltag aus? Also ich meine, ich war früher Softwareentwickler.

Wolfgang: Ich wusste, wie die Softwareentwicklung aussieht. Ich war nebenher so in Anführungszeichen

Wolfgang: Admin. Also da gab es noch kein Kubernetes damals.

Wolfgang: Da war ich derjenige, der sich dann mit dem Root-Account auf irgendwelche Server

Wolfgang: eingeloggt und von Hand was deployed hat.

Wolfgang: Lang, lang ist es her. Aber wie sieht so dein Berufsalltag aus,

Wolfgang: wenn du im Kubernetes-Umfeld tätig bist?

Gast: Also es gibt diverse Rollen, die ich schon gemacht habe in dem Umfeld.

Gast: Ich glaube grob kann man sagen, das eine so auf dem niedrigsten Level,

Gast: sage ich mal, wäre Kubernetes Cluster Betrieb.

Gast: Genau, das bedeutet halt eigenes Rechenzentrum, nur den Fall,

Gast: den wir gerade eben schon beschrieben hatten.

Gast: Darauf lief ein Kubernetes-Cluster und auf diesem Kubernetes-Cluster haben dann

Gast: die Entwickler gearbeitet.

Gast: Und das Ziel war eben, den Entwicklern schon viel bereitzustellen.

Gast: Also die hatten dann schon Monitoring und Logging und Storage und sowas im Cluster,

Gast: was sie halt alles kriegen konnten.

Gast: Also ich sage mal, vom Level her, dass man auf der Kubernetes-API eben schon

Gast: ähnlich viele Integrationen hat, wie man in der Public Cloud hätte.

Gast: Teilweise sogar ein bisschen mehr.

Gast: Eben die ganzen Observability-Stacks zum Beispiel.

Gast: Genau, und in dem Umfeld ist dann

Gast: schon eher so, dass ich halt viel mit Automatisierung gearbeitet habe.

Gast: Sprich, das eine große Problem und auch der Nachteil bei Kubernetes an sich

Gast: erstmal ist, dass ich ja das Ding auch zum Laufen kriegen muss.

Gast: Und wir hatten da halt ziemlich viel Tooling, wo es einfach nur darum ging,

Gast: wie fahre ich denn jetzt mal einen Knoten hoch, sodass der am Ende in meinem Cluster steht.

Gast: Und das Ganze war eben gebaut nach Immutable Infrastructure-Prinzipien,

Gast: sprich wir hatten da VM-Images,

Gast: da waren schon alle Tools mit drin, die man so gebraucht hat und dann noch einen

Gast: kleinen Config-Server und dann ist die Maschine gebootet, hat sich vom Config-Server

Gast: noch die letzten paar Infos gezogen,

Gast: hat dann auch sich von einem HashiCorp Vault direkt noch Zertifikat in sowas

Gast: geben lassen, das ist halt so der Standardmechanismus in Kubernetes,

Gast: wie sich die Komponenten untereinander authentifizieren können.

Gast: Und dann hat die Maschine sich eben einmal initialisiert und lief dann im Cluster.

Gast: War also kein Autoscaling, aber

Gast: halt wichtig, wenn wir Updates machen wollten, um ausrollen zu können.

Gast: Und das war so eine Baustelle, wo man natürlich immer wieder dran ist,

Gast: dieses ganze Setup, sowohl Images bauen oder zumindest anpassen,

Gast: diesen Config-Server bespielen, das ganze Zeugs.

Gast: Also da managt man dann schon eher wieder unter dem Kubernetes-Layer Dinge.

Gast: Ja, das wäre so das eine.

Wolfgang: Gibt es da jeden Tag was zu tun? Ich frage mal ein bisschen provokant.

Wolfgang: Ich meine, man installiert ja alles, fährt alles hoch, installiert die Nodes und dann läuft es doch.

Wolfgang: Ich meine, klar, es gibt mal ein Update, da muss man da sicherlich mal ran,

Wolfgang: irgendwie ein Update installieren.

Wolfgang: Aber im Best Case, gibt es da jeden Tag was zu tun, wenn du sagst Management vom Cluster?

Gast: Ja, also jeden Tag jetzt nett und das hat sich seitdem ich in dem Projekt war

Gast: auch nochmal ein bisschen verlangsamt.

Gast: Also als ich angefangen habe mit Kubernetes, hatten wir noch vier Releases im

Gast: Jahr, jetzt haben wir drei Releases im Jahr und bei den größeren Releases,

Gast: eben diesen vier im Jahr oder jetzt drei, kann sich schon auch mal was Größeres

Gast: ändern, also dass ein paar APIs geändert werden und so.

Gast: Also und dann fange ich eben auch an an dem ganzen, ich nenne es mal das Base

Gast: Layer, also sobald mal ein Cluster steht, auch die ganzen Grundkonfigurationen,

Gast: die ich da ausgerollt habe, daran musste ich dann schon mal schrauben.

Gast: Und das war eben damals 2018, 2019, als ich in dem Projekt war,

Gast: tatsächlich so, dass da doch relativ viel sich geändert hat.

Gast: Also so von den Dingen, die wir heute als gegeben annehmen, ich sage mal Deployments

Gast: und Ingress für die Leute, die schon damit gearbeitet haben,

Gast: auf jeden Fall zum Begriff, hat sich halt doch nochmal immer wieder was geändert.

Gast: Ein paar Felder wurden umbenannt, die API-Version wurde ein bisschen hochgedreht.

Gast: Das war jetzt keine riesen Umschrauberei, kann man jetzt auch ein bisschen drüber lächeln.

Wolfgang: Ein paar schöne kleine Breaking Changes.

Gast: Ein paar schöne kleine Breaking Changes, genau. Und dann fängt man eben an,

Gast: das natürlich auch auf mehrere Stages auszurollen, zu testen.

Gast: Und ich meine, ich war auch blutiger Anfänger. Also natürlich ist alles auch

Gast: kaputt gegangen, was ich angefasst habe.

Gast: Das ist mal das eine. Und dann gibt es aber natürlich auch ein paar...

Gast: Dependencies, die Kubernetes selbst hat, also was Kubernetes nicht mitbringt,

Gast: ist eine Container Runtime.

Gast: Das mag jetzt für Leute, die sich das im Moment angeschaut haben,

Gast: überraschend klingen. Ich habe hier ein Tool, was Container laufen lässt,

Gast: aber es kann keine Container laufen lassen.

Gast: Aber das hatten die quasi von Anfang an im Kubernetes-Projekt halt rausgescoped.

Gast: Die haben gesagt, ja, wir nehmen an, auf dieser Maschine gibt es einen Docker

Gast: und jetzt heute mittlerweile gibt es dafür halt auch einen Standard oder zwischenzeitlich,

Gast: nicht erst seit heute, gibt es eben dieses Container Runtime Interface.

Gast: Und über das sprechen wir halt eine Container Runtime an.

Gast: Und was du dann wählst, ob das jetzt quasi Docker wäre, supporten sie gar nicht

Gast: mehr, aber sagen wir mal Docker oder die moderneren wären Container D und CRIO.

Gast: Ist dann eigentlich relativ egal. Das Endziel ist halt, da läuft ein Container.

Gast: Und solche Dinge muss man natürlich auch managen und wenn dann deine Container

Gast: Runtime halt ein Breaking Change hatte, was mal vorkam oder das Netzwerk Layer

Gast: hatte größere Changes, dann muss man da halt auch mal dran schrauben.

Gast: Ja, zum Beispiel eine Story, an die ich mich auch noch ganz gut erinnere,

Gast: war, ich sollte halt eben das Netzwerk-Plugin, was wir da im Cluster laufen

Gast: hatten, Calico updaten auf eine neue Major-Version oder vielleicht auch noch

Gast: eine Minor-Version, aber auf jeden Fall ein größeres Versions-Update.

Gast: Das hatten die Leute, die halt im Team waren, eine Weile liegen lassen, hatten die Zeit dafür.

Gast: Genau, das habe ich dann halt gemacht. Im Endeffekt sah das erstmal einfach

Gast: aus. Ich habe halt ein paar Config-Files anpassen müssen, weil sich da im Format

Gast: ein bisschen was geändert hat.

Gast: Soweit so straightforward. Und dann habe ich das halt ausgerollt auf die Development-State.

Gast: Und dann ging das auch bei, von den, was weiß ich, 20 Knoten der Development-State super.

Gast: Und dann beim 21. war es halt plötzlich so, ja, da lief es nicht.

Gast: Und die Long Story Short habe ich dann halt fünf Tage lang da eine Race-Condition-Debug,

Gast: da haben wir in der eine Zeile Code geändert, Pull-Request bei denen aufgemacht und das dann so gefixt.

Gast: Und das sind natürlich auch Dinge, das ist halt alles Open-Source-Zeugs.

Gast: Und wenn du der Erste bist, der diesen Bug findet,

Gast: Und du die Zeit hast zumindest oder dir deine Firma das erlaubt,

Gast: was ja Innerwex zum Glück tut, dann darf ich halt auch eine Woche lang Race

Gast: Condition debuggen und am Ende den Bug fixen.

Wolfgang: Und es fühlt sich so großartig an, wenn man es gefunden hat.

Wolfgang: Ich meine, die vier Tage davor sind furchtbar, aber wenn du es herausgefunden

Wolfgang: hast, ich meine, so einen Triumph hast du doch selten im Leben, oder?

Gast: Und die große Freude kam auch nochmal ein paar Wochen später,

Gast: wo ich plötzlich Innerwex-Post hatte. Ich kriege ja eigentlich nie Post ins Office.

Gast: Als du angefangen hast, hat man noch Post bekommen?

Wolfgang: Ja, ganz selten, ja.

Gast: Okay, also ich habe einmal Post bekommen und das war dann von der Firma,

Gast: die dieses Open-Source-Projekt Calico macht, Tigera, hat mir der Maintainer

Gast: einen kleinen Brief geschickt mit Danke für deinen Beitrag und zwei coolen Stickern.

Wolfgang: Okay, das ist natürlich sehr.

Gast: Sehr geil. Mega geil, habe ich mich richtig gefreut.

Wolfgang: Ja, das ist sehr cool. Aber dann nehme ich so deinen Schilderungen,

Wolfgang: dass der Alltag als Cloud-Plattform-Engineer im Kubernetes-Umfeld schon sehr

Wolfgang: abwechslungsreich ist.

Wolfgang: Also ich meine, du hast halt auch diesen riesen Lifecycle von dieser ganzen

Wolfgang: Plattform von ich baue was neu auf mit dem Team zusammen, ich betreibe das,

Wolfgang: ich mache vielleicht nur ganz normale Überwachung, Wartung, ich spiele ein Update ein,

Wolfgang: ich habe Breaking Changes in der API und muss jetzt vielleicht dafür sorgen,

Wolfgang: dass größere Teile umgebaut und angepasst werden.

Wolfgang: Also da ist schon viel Abwechslung dabei, oder?

Gast: Ja, also es beschäftigt einen auf jeden Fall. Ich glaube, heute auch wieder

Gast: ein bisschen anders als damals.

Gast: Also was ich jetzt so heute sehe an Projekten, wo gerade Kollegen drin sind,

Gast: ist halt, die machen nicht Betrieb von, was hatten wir damals,

Gast: sechs Kubernetes-Cluster oder sowas, sondern die machen halt Betrieb von hunderten Clustern.

Gast: Da sind jetzt vielleicht weniger Breaking Changes, weil die Kubernetes-Abi eben

Gast: stabiler geworden ist und viele Themen jetzt langsam einmal dadurch sind.

Gast: Aber dafür haben die halt plötzlich ein ganz anderes Management-Tooling und

Gast: nochmal ein ganzes Layer drüber, was halt wieder eigene Komplexität mitbringt.

Wolfgang: Das verstehe ich. Da muss man schon ganz neue Ansätze finden,

Wolfgang: damit es auch skaliert irgendwie, dass du das alles managen kannst überhaupt.

Gast: Genau, und da gibt es eben auch wieder Open-Source-Tools, also von SAP,

Gast: den Gardener oder Kubermatic.

Gast: Ich glaube, die Firma ist auch Kubernetes-Management-Tools sind, so generalisierte.

Gast: Aber dass das dann in deinem System natürlich auch genau läuft,

Gast: wird auch wieder viel Anpassungsarbeit kosten und viel Wartungsaufwand.

Wolfgang: Ja, sag mal, in deinem Arbeitsalltag, was sind denn so die größten Herausforderungen

Wolfgang: im Umgang mit Kubernetes?

Wolfgang: Also gibt es da Bereiche, wo du sagst, jo, wenn da was ist, dann bedeutet es

Wolfgang: viel Arbeit oder es wird knifflig oder es ist vielleicht aber auch lästig,

Wolfgang: weil irgendwo eine Automatisierung fehlt?

Gast: Jetzt so mit Kubernetes an sich fällt mir jetzt spontan dazu nichts ein.

Gast: Also ich glaube so die zwei großen Hürden, die ich oft sehe,

Gast: sind zum einen eben für andere Leute auch mehr, aber natürlich für mich auch

Gast: immer wieder das Wissen.

Gast: Und das andere ist dann im Endeffekt Config Management, also irgendwo jammelfalls

Gast: rumschubsen, ganz blöd gesagt.

Gast: Und beim Wissen ist es halt so, da merke ich schon immer wieder,

Gast: es sind halt einfach extrem viele Ressourcen, die man in dieser API halt erstellen

Gast: kann und die zusammenspielen und die mal fester und mal loser gekoppelt sind.

Gast: Also vom Grundprinzip her deploy ich meinen Container in Kubernetes meistens

Gast: halt mit einem Deployment, das wäre halt mal eine Ressource.

Gast: Dann möchte ich aber, dass es noch im Netzwerk ansprechend war,

Gast: erstelle ich einen Service dazu, dann soll es im Internet verfügbar sein,

Gast: dann mache ich noch eine Ingress-Ressource dazu.

Gast: Dann brauche ich vielleicht noch Zugriff auf die API. Dafür brauche ich einen Service-Account.

Gast: Und dann noch ein bisschen Zeugs Richtung Role-Based Access Control.

Gast: Dann habe ich nochmal drei Ressourcen mehr.

Gast: Dann möchte ich, dass es autoskadiert. Das ist wieder eine Ressource.

Gast: Dann möchte ich noch definieren, wie verhält sich das Cluster-Update sozusagen.

Gast: Oder wie sorge ich dafür, dass ich nicht zu viele Unterbrechungen bekomme im

Gast: Cluster-Upgrade. Dafür gibt es eine Ressource.

Gast: Dann möchte ich vielleicht in meiner Anwendung nochmal sagen,

Gast: wie du schon gesagt hast, wie redundant soll die laufen.

Gast: Dann kommt da nochmal zwar keine Ressource, aber schon ein relativ komplexes Feld dazu.

Gast: Also das alles erstmal zu überblicken. Und das ist wirklich noch nicht alles,

Gast: was man haben kann für eine Anwendung.

Gast: Also da gibt es schon noch ein, zwei Dinge mehr, je nach Anforderung,

Gast: was halt dazukommen kann.

Gast: Das kostet natürlich auch ein bisschen Zeit. Und dann, wenn was schiefläuft

Gast: und man weiß gar nicht, was es alles gibt, kostet es natürlich umso mehr Zeit,

Gast: und umso mehr Nerven oft auch erstmal zu verstehen, wo es denn eigentlich gerade ist. Problem.

Gast: Also wenn ich ein Problem habe, was an einer Ressource liegt,

Gast: von der ich vorher noch nie gehört habe, ist es natürlich schwierig.

Wolfgang: Ja klar. Ja sag mal, wie würdest du denn das beurteilen? Wenn wir Projekte für

Wolfgang: Kunden machen, dann ist ja auch immer das Ziel, dass der Kunde in der Zukunft

Wolfgang: irgendwann in der Lage ist, dieses System selbst zu handhaben und zu managen.

Wolfgang: Und bei manchen Bereichen, da ist es vielleicht einfacher, wenn es jetzt um

Wolfgang: Java-Entwicklung geht oder Java macht man,

Wolfgang: Das sind immer so cool. Kotlin. Wenn es um Kotlin-Entwicklung geht und beim

Wolfgang: Kunden gibt es schon ein paar Leute, die programmieren, dann können sie sich

Wolfgang: das in der Regel ja relativ einfach drauf schaffen.

Wolfgang: Oder man entwickelt gemeinsam irgendwie.

Wolfgang: Oder selbst wenn jemand dann neue Leute einstellt für die Entwicklung,

Wolfgang: geht sowas meistens ja relativ zügig.

Wolfgang: Kubernetes ist ein komplexes Thema. Und wenn ich jetzt auf Kundenseite vielleicht

Wolfgang: schon ein, zwei, drei Leute habe, die so im administrativen Bereich unterwegs

Wolfgang: sind, vielleicht auch Linux-Skills schon haben,

Wolfgang: Aber kannst du aus dem Bauch heraus sagen, wie viel Aufwand das ist,

Wolfgang: um sich so tief einzuarbeiten, dass man ein gutes Gefühl dabei hat?

Wolfgang: Also nicht, dass man jetzt so absoluter Deluxe-Profi ist, aber ein gutes Gefühl

Wolfgang: hat und versteht, was da passiert?

Gast: Ich glaube, wenn man sich dediziert damit beschäftigt, also entweder eine Schulung

Gast: besucht, also ich bin auch Kubernetes-Trainer zum Beispiel und würde sagen,

Gast: die Schulungsmaterialien decken schon ziemlich viel von dem ab,

Gast: was man eben wissen muss.

Gast: Aber natürlich auch aus anderen Quellen, das heißt jetzt, dass man gerne mit

Gast: Udemy oder YouTube oder anderen Formaten lernt,

Gast: kann man sich schon recht schnell, also auch in ein paar Tagen mal ein gutes,

Gast: breites Grundwissen anhäufen, dass man eben überhaupt mal die ganzen Begriffe

Gast: gehört hat und mal grob einordnen kann, hier gibt es noch was und da gibt es noch was.

Gast: Und dann wird es halt trotzdem noch ein paar Wochen oder auch Monate dauern,

Gast: je nachdem, wie viel man sich jetzt damit beschäftigt.

Gast: Ob ich jetzt einmal die Woche CubeCuddle, GetPods ausführe oder halt doch jeden

Gast: Tag irgendwie ein paar Sachen umkonfiguriere und vielleicht auch ein paar Sachen ausprobiere.

Gast: Aber ich denke, man wird trotzdem halt ein paar Wochen bis Monate brauchen, je nach Intensität.

Gast: Bis man halt sagt, okay, jetzt fühle ich mich ziemlich wohl damit und habe das

Gast: alles so verstanden. Also klar, kostet auf jeden Fall ein bisschen Zeit.

Wolfgang: Ja, du hast gesagt, du bist Trainer. Wie lange dauert so ein Training?

Wolfgang: Ist das eine Woche oder drei Tage?

Gast: Genau, wir haben zwei Trainings. Eins, das richtet sich eher an Entwickler, das geht drei Tage.

Gast: Und ein Training, das richtet sich an Administratoren. Das ist dann einfach

Gast: nochmal ein vierter Tag obendrauf, wo wir auch nochmal ein bisschen mehr unter

Gast: die Haube schauen, auch mal eigene Kubernetes-Knoten hochfahren, konfigurieren.

Gast: Genau, und auch da ein paar Prozesse nochmal mit durchmachen.

Wolfgang: Wäre das dann spannend, wenn ich anfange, direkt am Anfang so ein Training zu machen?

Wolfgang: Oder lohnt es sich erst so ein bisschen im Selbststudium damit zu beschäftigen

Wolfgang: und sich vielleicht mal ein paar YouTube-Videos anzuschauen und ein bisschen

Wolfgang: auf der Konsole rumzuhacken, dass man schon so ein Grundverständnis hat?

Gast: Also für unser Training jetzt gibt es erstmal keine Wissensvoraussetzung Richtung Kubernetes.

Gast: Ist aber ganz gut, wenn du vielleicht schon mal einen Docker-Container gebaut

Gast: hast oder ausgeführt hast und

Gast: auch so ein kleines bisschen Kommandozeilenkenntnisse sind nicht schlecht.

Gast: Weil wir halt auch von den Aufgaben her viel auf kubectl setzen.

Gast: Das ist so das Standard-Tool, um mit Kubernetes zu interagieren.

Gast: Genau. Und da ist es natürlich ganz gut, wenn man schon mal auf der Kommandozeile

Gast: ein paar Sachen getippt hat.

Wolfgang: Okay, cool. Jetzt habe ich noch ein paar Punkte bzw.

Wolfgang: Fragen hier bei mir auf dem Zettel draufstehen. Und zwar die eine Frage,

Wolfgang: Maximilian, auf die alle Leute schon die ganze Zeit warten.

Wolfgang: Und zwar, wie wird sich Kubernetes verändern durch den Einsatz von KI?

Wolfgang: KI steckt überall drin. Wir sprechen eigentlich nur noch über KI.

Wolfgang: Wenn ich News lese, geht es dann nur um KI.

Wolfgang: Ich frage mich, wo steckt die KI in Kubernetes?

Wolfgang: Was wird sich durch KI verändern? Steckt überhaupt schon KI drin?

Wolfgang: Braucht man dich in der Zukunft überhaupt noch? Oder haben wir den KI-Admin

Wolfgang: irgendwie, der alles automatisch macht?

Gast: Wäre natürlich cool, dann kann ich mich auch zurücklehnen, würde ich nehmen.

Gast: Also es gibt Firmen, die das anbieten, die sagen, wir schreiben hier die KI,

Gast: die halt deine Kubernetes-Deployments für dich managt.

Gast: Und bis jetzt bin ich da eher skeptisch, einfach auch wegen der Kritikalität.

Gast: Also wenn ich jetzt hier einen Service am Laufen habe, der macht Logins für

Gast: Millionen von Nutzer und der KI-Admin fährt den halt aus Versehen runter.

Gast: Das gleiche Risiko, wie wenn jetzt ein Junior-Entwickler den aus Versehen runterfährt,

Gast: aber an sich halt nochmal eine andere Quelle dafür.

Gast: Ist halt schon blöd, ne? Also dann kann sich ja kein Nutzer mehr einloggen.

Gast: Also für eine produktive Plattform fühlt sich das aus meiner Sicht erstmal nicht

Gast: so gut an, weil von allem, was ich bis jetzt gesehen habe,

Gast: KI natürlich schon auch oder Generative AI konkreter auch immer noch gerne mal

Gast: halluziniert und natürlich auch nicht perfekt ist.

Gast: Also nicht, dass ich jetzt perfekt wäre, aber zumindest habe ich vielleicht

Gast: manche Fehler schon gemacht und daraus was gelernt und das kann Generative AI

Gast: in der Form ja dann doch nicht.

Wolfgang: Das heißt dann, es gibt ja aktuell so diesen Trendbegriff Wipe Coding,

Wolfgang: also für Softwareentwicklung mithilfe von generativer AI.

Wolfgang: Und wenn man jetzt so sagen würde, Wipe Ops, wärst du jetzt noch ein bisschen

Wolfgang: skeptisch und glaubst, das dauert noch ein bisschen, bis wir hier die Administration

Wolfgang: von solchen Clustern auch in die Hände von so einer KI legen.

Gast: Ich meine, VibeOps klingt natürlich erstmal cool.

Wolfgang: Klingt mega cool.

Gast: Direkt testen, ja. Nachdem ich auch zu VibeCoding schon gelesen hatte von Leuten,

Gast: die halt auch gar kein Programmierwissen hatten und dann gemerkt habe,

Gast: oh, jetzt habe ich hier plötzlich Leute, die meinen API-Key geklaut haben.

Gast: Ja, kann dir natürlich mit VibeOps auch gut passieren, dass dein Backend plötzlich

Gast: deinen API-Key zurückgibt oder so.

Gast: Wird sehr, sehr gut. Dafür müssen wir noch ein bisschen coden.

Gast: Aber kann dir schon passieren, dass du mit VibeOps halt Secrets leagst oder was auch immer.

Gast: Ja, ich könnte mir schon vorstellen, dass es ziemlich praktisch ist.

Gast: Ich habe es selbst auch noch nicht wirklich ausführlich getestet,

Gast: um also den Boilerplate zu kriegen.

Gast: Ich glaube, das ist auch ein großer Struggle eben am Anfang,

Gast: dass man ja eigentlich immer mal etwas braucht.

Gast: Ich sitze vor einem leeren Projekt oder mein Projekt enthält halt nur meinen

Gast: Java-Code. Jetzt hätte ich gerne ein Kubernetes-Deployment mit allem, was ich so brauche.

Gast: Das ist ja mal ganz nett, wenn mir eben mein Chat-GPT da direkt ein bisschen

Gast: was generiert. Und wenn es die API annimmt, dann wird es ja auch schon halbwegs funktionieren.

Gast: Aber klar, dass du dann halt komplexere Prozesse vielleicht abbildest.

Gast: Kann ich mir schwerer vorstellen.

Wolfgang: Ja, wo ich mir das auch gut vorstellen kann, was ich einen schönen Use Case auch finde.

Wolfgang: Bei so generativer KI wird oft ja davon ausgegangen, dass die KI dir den Code

Wolfgang: generiert, dir einen Text generiert, dir Konfiguration generiert.

Wolfgang: Das ist sicherlich auch ein spannender Use Case. Was ich aber genauso spannend

Wolfgang: finde, ist die andere Seite.

Wolfgang: Du machst das selbst und nutzt dann so eine KI quasi, um sowas zu lektorieren.

Wolfgang: Kulturieren. Also du schreibst dir deine Konfiguration und sagst dann,

Wolfgang: hey KI, schau mir mal die Konfiguration an, fällt dir was auf.

Wolfgang: Und das ist was, was ich zum Beispiel teilweise mache, jetzt nicht mit Konfiguration,

Wolfgang: da arbeite ich nicht so viel mit, aber mit anderen Sachen, dass ich sage,

Wolfgang: hey, schau dir das mal an, fällt dir was auf.

Wolfgang: Und sowas finde ich sehr spannend, wenn dann du den Hinweis bekommst,

Wolfgang: hey, schau mal hier, überprüf mal, ob dieser Value hier passt,

Wolfgang: der macht irgendwie keinen Sinn.

Wolfgang: Sowas finde ich super, super spannend. Und sowas gönne ich mir zum Beispiel

Wolfgang: bei so einer konfigurationslastigen,

Wolfgang: Technologie wie Kubernetes sehr gut vorstellen, dass du so eine Art ich möchte

Wolfgang: es nicht Co-Pilot sagen, das ist so geframed, der Begriff, aber so eine Art

Wolfgang: Rubber Duck hast vielleicht, der dir das für dich anschaut.

Gast: Ja, könnte ich mir prinzipiell schon auch vorstellen zu sagen,

Gast: ja, sag mir mal, was ist hier vielleicht sicherheitskritisch an meinem Deployment-YAML

Gast: oder so und dann gibt er dir ein paar Hinweise.

Gast: Generell, was ausgespuckt wird, ist ja meistens schon meistens schon richtig.

Gast: Ich meine, das ist halt immer so ein bisschen das Problem, wie sehr verlasse ich mich jetzt da drauf.

Gast: Im Kubernetes-Umfeld ist eigentlich die Doku auch ziemlich gut.

Gast: Also für meine Verhältnisse zumindest, würde ich sagen, ziemlich ausführlich

Gast: und erklärt die meisten Dinge auch.

Gast: Und wenn du darauf dein Modell am Ende trainiert hast oder dann selber einfach

Gast: mal mit der Doku nachliest, hast du, glaube ich, auch recht große Chancen,

Gast: richtige Informationen daraus zu kriegen.

Wolfgang: Jetzt sind wir schon bei so innovativen Themen wie KI. Wenn du mal ein bisschen

Wolfgang: in deine Kristallkugel schaust, die ja rein zufällig gerade vor dir steht,

Wolfgang: was für spannende Themen siehst du in der Zukunft noch im Bereich Kubernetes?

Wolfgang: Ich bin ehrlich, für mich fühlt sich Kubernetes ein bisschen an,

Wolfgang: als ob es ausentwickelt ist im Großen und Ganzen.

Wolfgang: Das ist ein sehr gut abgehangenes System mittlerweile ist, wo es vielleicht

Wolfgang: nicht mehr so viele Breaking Changes gibt.

Wolfgang: Aber wie siehst du das? Siehst du irgendwelche großen Innovationen dann noch

Wolfgang: am Horizont oder große Themen, wo viel Musik noch drin ist?

Gast: Also so richtig große Themen sehe ich eigentlich gerade nicht.

Gast: Wenn man auch mal in die Release Notes schaut, hatte ich die Tage auch für Kubernetes

Gast: 1.32, was jetzt die aktuelle Version ist.

Gast: Dann ist für mich jetzt irgendwie ein Thema mal rausgesprungen,

Gast: wo ich dachte, ach, das ist ja nett, das ist ein neues Feature,

Gast: das könnte ich nutzen. Klingt ganz praktisch.

Gast: Aber so die großen Entwicklungen, die gibt es jetzt wirklich aus meiner Sicht

Gast: nicht mehr. Also klar, da wird noch geschraubt, da werden noch Dinge verbessert.

Gast: Es gibt vielleicht auch ein paar APIs in Kubernetes, die so ein bisschen überholt

Gast: sind, die man ersetzen könnte.

Gast: Zum Beispiel Network Policy.

Wolfgang: Wer kennt sie nicht?

Gast: Wer kennt sie nicht? Ja, du kennst sie wahrscheinlich nicht,

Gast: aber die Firewall-Policy sozusagen im Kubernetes,

Gast: die ist halt relativ schwer zu verstehen oder ein bisschen umständlich einfach

Gast: gebaut von der Art und Weise, wie man da ausdrückt, was man denn eigentlich haben möchte.

Gast: Dafür könnte es natürlich ein Replacement geben und das haben sie auch schon

Gast: in manchen Bereichen gemacht.

Gast: Aber was wir dann eben machen als Replacement, zum Beispiel jetzt für Ingress,

Gast: was eben für Internetzugriff auf meine Anwendung genutzt wird,

Gast: gibt es als Replacement oder als Alternative mittlerweile die Gateway API.

Gast: Und diese Gateway API, die ist nicht mehr Teil von Kubernetes,

Gast: dem Projekt, sondern ist halt wieder so eine Art Plugin.

Gast: Also kann ich extra installieren in meinen Cluster und dann installiere ich

Gast: halt das Tooling, was damit was anzufangen weiß.

Gast: Also auch ein großer Punkt, in den wir gar nicht so reingesprungen sind bis

Gast: jetzt, ist ja, dass Kubernetes super erweiterbar ist.

Gast: Also dass ich dem auch sagen kann, hier gibt es neue Arten von Ressourcen und

Gast: die kann man jetzt verwalten, auch über die Kommandozeile und über die Tools, die man schon hat.

Gast: Und Gateway API wäre eben so ein Anwendungsfall, wo es eben auch darum geht,

Gast: die Schwächen von der alten Ressource, die halt in Core Kubernetes drin ist,

Gast: dem Ingress ein bisschen auszugleichen

Gast: und ein paar Möglichkeiten mehr zu bieten, als jetzt Ingress hat.

Gast: Aber genau, eben diese Entwicklung und viele andere Entwicklungen,

Gast: die finden dann nicht mehr in der Kubernetes-Code-Basis statt,

Gast: sondern halt in dem großen Kubernetes-Projekt.

Gast: Also nennt sich dann in dem Fall eine Special Interest Group, eine SIG,

Gast: die sich halt beschäftigt mit diesem Bereich ich glaube SIG Networking oder

Gast: so und die dann eben diese API und eine Standardimplementierung dafür rausgebracht

Gast: hat und damit kann ich dann eben jetzt auch wieder,

Gast: in meinem Cluster arbeiten, ich muss es aber halt einmal nachinstallieren Ja.

Wolfgang: Aber das klingt für mich ehrlich gesagt ganz gut, denn wenn ich so eine Software,

Wolfgang: produktiv einsetzen möchte, dann wünsche ich mir ja dass sie gut abgehangen

Wolfgang: ist Also ich wünsche mir ja, dass da nicht mit jedem Release sich irgendwie

Wolfgang: alles verändert und dass die Innovation vielleicht,

Wolfgang: Ja, in kleineren Schritten kommt und vielleicht ist es nicht so super glitzert,

Wolfgang: sondern vielleicht das, was schon gut ist, noch ein bisschen besser macht einfach.

Gast: Ja, wäre ja quasi auch die Frage, was möchte ich denn überhaupt von einer neuen

Gast: Version oder was könnte ich mir noch vorstellen, was soll sich fundamental ändern?

Wolfgang: Du, ich finde, da ist ein ganz gutes Beispiel so das Apple iPhone.

Wolfgang: Als das damals rauskam 2007, war das ja richtig krass, sowas gab es noch nicht.

Wolfgang: Und die ersten Jahre war jedes neue iPhone richtig krass. Da war immer was Neues drin.

Wolfgang: Und die Leute waren komplett verrückt.

Wolfgang: Wow, was da drin ist.

Wolfgang: Und so die letzten, weiß ich nicht, sechs, sieben, acht, neun Jahre gibt es

Wolfgang: immer so eine riesen Enttäuschung. Und ich finde es so witzig,

Wolfgang: weil es gibt jedes Jahr die Ankündigung, es gibt dann dieses Apple-Event und

Wolfgang: da werden die neuen iPhones vorgestellt. Naja, und was haben die dann neu?

Wolfgang: Bisschen größer, bisschen kleiner vielleicht, mehr Auflösung im Display,

Wolfgang: besserer Akku und nochmal 20 Megapixel extra auf die Kamera.

Wolfgang: Aber die Leute sind trotzdem enttäuscht, weil sie immer was Krasses erwarten.

Wolfgang: Aber niemand kann dir sagen, was das ist.

Wolfgang: Und das finde ich auch so interessant. Ich weiß nicht, ob es bei anderen Mobiltelefonen

Wolfgang: ähnlich ist, aber ich kann es mir vorstellen, dass es vielleicht beim Samsung

Wolfgang: Galaxy, whatever genauso ist, dass man da immer was Krasses erwartet, aber man weiß nicht was.

Wolfgang: Und das ist so vielleicht ein ganz gutes Zeichen, dass eine Technologie ausentwickelt

Wolfgang: ist, ein böses Wort, aber vielleicht einfach schon sehr, sehr rund ist irgendwo.

Gast: Ja, ich glaube, es wird immer Anwendungsfälle geben, die sich vielleicht nicht

Gast: so gut abbilden lassen in Kubernetes.

Gast: Und da wäre man eben wieder ein bisschen am Anfang so der Monolith oder so,

Gast: der halt auch konstant laufen sollte, wo ich nicht sage, den kicke ich jetzt

Gast: mal weg und fahre ich neu hoch.

Gast: Einfach, weil ich keine Redundanz zum einen habe und zum anderen,

Gast: weil er es vielleicht auch gar nicht mag, weil er irgendwie,

Gast: aufs Filesystem Sachen schreibt und...

Wolfgang: Ja du, ich kenne das. Also ich hatte mal einen Kunden, der hatte im Keller dann

Wolfgang: so zwei Server stehen und in jedem Server steckte ein komplettes Terabyte RAM

Wolfgang: drin, weil das halt auch eine Anwendung war, die drauf lief,

Wolfgang: die halt sehr speicherhungrig war.

Wolfgang: Und da hatte man dann halt einfach immer so einen Server als Standby,

Wolfgang: falls halt einer abschmiert.

Wolfgang: Und man hatte halt den einen Server dann auch noch genutzt, wenn es halt Updates

Wolfgang: gab, damit man halt keine Downtime hatte.

Gast: Ja, genau. Für so einen Fall wäre jetzt Kubernetes nicht wirklich sinnvoll und auch nicht hilfreich.

Gast: Und ich glaube, das ist aber auch einfach in Ordnung. Das ist auch kein erklärtes

Gast: Ziel vom Kubernetes-Projekt, sondern die sagen halt, ihr könnt hier stateless

Gast: Microservices machen, könnt das quasi maximal weit skalieren in die Breite.

Gast: Und ja, wenn das halt nicht das Ziel ist, dann nutze ich halt kein Kubernetes.

Gast: Dann gibt es vielleicht irgendwann mal noch ein anderes Tool,

Gast: was dann das auch noch mit kann.

Wolfgang: Mikro Kubernetes.

Gast: Mikro Kubernetes oder Maxi Kubernetes, weil es ja noch mehr kann.

Wolfgang: Oder weil du Maximilian bist.

Gast: Ja genau, ich mache jetzt das Maxi.

Wolfgang: Dein Fork ist dann Maxi Kubernetes. Okay, watch out. Ja, ja.

Gast: Ja, aber im Endeffekt ist halt das, was es ist und ich glaube,

Gast: das, was es ist, ist ziemlich gut.

Gast: Also so dieses ganze API-Design, API-Driven-Design, dass wir alles deklarativ

Gast: haben in der Kubernetes-Welt.

Gast: Also wir sagen halt, was wir wollen und dann wird das irgendwie gemacht und

Gast: wir sagen nicht, wie wir es machen wollen.

Gast: Das sind halt Grundprinzipien, die ziehen sich auch richtig durch in der ganzen Tool-Welt.

Gast: Das hat Kubernetes so durchgetreten und das funktioniert halt ziemlich gut,

Gast: auch gerade in diesem Infrastrukturbereich.

Wolfgang: Maximilian, zum Schluss noch eine Frage. Du hast es viel erzählt und man konnte,

Wolfgang: glaube ich, auch gut so heraushören, dass dir die ganze Technologie viel Spaß

Wolfgang: macht und du begeistert bist.

Wolfgang: Aber welche Sache motiviert dich eigentlich am meisten, dich da jeden Tag mit zu beschäftigen?

Gast: Ja, ich bin mir manchmal ganz sicher, ob es unbedingt die Motivation ist,

Gast: mich damit zu beschäftigen oder dass man es auch einfach nicht los wird.

Gast: Das muss man ja auch sagen, es ist halt einfach das Standard-Tool,

Gast: gerade auch bei unseren Kunden, was überall eingesetzt wird.

Gast: Aber im Großen und Ganzen fühle ich mich halt auch einfach ziemlich firm damit.

Gast: Also das ist wahrscheinlich einfach, weil ich mich halt gut damit auskenne und

Gast: viel damit gemacht habe.

Gast: Habe ich halt schon das Gefühl, ich weiß, wo ich die Schalter drehen muss.

Gast: Ich weiß, was ich hier machen kann. und ich habe auch ein bisschen das Gefühl,

Gast: dass die Werkzeuge zumindest ziemlich solide sind jetzt so in der Kubernetes-Welt.

Gast: Also ich kann damit gut arbeiten.

Gast: Eben, was ich gerade eben auch meinte, mit deklarativen APIs zum Beispiel.

Gast: Also diese Prozesse, wie ich jetzt Ressourcen update, wie ich Ressourcen verwalte

Gast: und wie am Ende dann einfach meine Anwendung damit dasteht.

Gast: Das funktioniert aus meiner Sicht ziemlich smooth und das macht schon mir zumindest Spaß.

Gast: Wenn es anderen Leuten nicht Spaß macht und die lieber, ich sage mal,

Gast: SCP auf ihre VM machen wollen, dann ist das auch okay.

Gast: Aber für mich ist das alles ziemlich cool und ziemlich praktisch und man kann

Gast: es irgendwie immer erweitern und mit anderen Dingen integrieren.

Gast: Ja.

Wolfgang: Also ich bin ja noch mit SCP unterwegs, aber nur im privaten Bereich.

Wolfgang: Da habe ich noch kein Kubernetes.

Wolfgang: Maximilian, vielen Dank für deine Schilderung. Vielen Dank für deine Geschichten

Wolfgang: und für deine Expertise, die du hier geteilt hast.

Wolfgang: Ich fand es super spannend, da mal reinzuhören ins Thema Kubernetes und vor

Wolfgang: allem mal zu erfahren, wie sich das heute einfach so anfühlt nach den ganzen

Wolfgang: Jahren, wo wir es jetzt schon haben.

Wolfgang: Und ich habe viel gelernt. Vielen Dank, dass du da warst und vielen Dank für deine Zeit.

Gast: Ja, danke Wolfgang, auch dir nochmal für die Einladung. Hat mir auch viel Spaß gemacht und tschüss.

Voiceover: Das war das Gespräch mit Maximilian. Ich hoffe, dass es euch Spaß gemacht hat.

Voiceover: Wenn ihr Feedback habt, dann erreicht ihr mich per E-Mail unter podcast.inovex.de.

Voiceover: Wir hören uns in der nächsten Folge wieder und bis dahin wünsche ich euch viel Spaß und eine gute Zeit.