#48 Der Layer unter Docker: containerd, Kubernetes, Container Runtime Interface, CRI-O und Open Container Initiative (OCI)

Wie sieht eigentlich der Layer unter Docker aus? Und wie interagiert Kubernetes mit Containern?

In Episode 46 haben wir geklärt, welches Problem Docker eigentlich löst. Das Container-Ecosystem ist jedoch weit größer. Deswegen widmet sich diese Folge der darunter liegenden Ebene. Wir besprechen die Modularisierung von Docker, die herausgetrennte Highlevel Runtime containerd, wie Kubernetes mit Docker-Containern umgeht, ob Docker Container die einzige Art von Containern ist, die Kubernetes unterstützt, was ein Container Runtime Interface (CRI) ist, was die Open Container Initiative (OCI) und ob auch du dir deine eigene Highlevel Container Runtime programmieren kannst.

Bonus: Was die Linux-Mafia ist und wieso es bald eine österreichische Container Runtime gibt.

Sprungmarken

(00:00:00) Intro

(00:00:58) Computerbild, c't und iX und einen Layer tiefer als "Was ist Docker"

(00:04:31) Der nächsttiefere Layer nach docker run: Highlevel Runtime containerd

(00:07:05) Was ist denn ein Container-Lebenszyklus und der Unterschied zwischen Highlevel und Lowlevel-Runtime?

(00:09:37) Ist containerd noch ein Teil von docker?

(00:10:35) Kann containerd auch von anderen Clients als docker angesprochen werden?

(00:13:06) Verwendet Kubernetes auch docker? docker shim, CoreOS, rkt

(00:16:01) Container Runtime Interface (CRI) von Kubernetes

(00:19:44) Kubernetes, API-Server, kubelet und die Highlevel-Runtime

(00:20:58) Eine alternative Highlevel-Container-Runtme zu containerd: CRI-O

(00:24:15) Die Cloud Native Computing Foundation (CNCF)

(00:28:16) Was ist besser? Containerd oder CRI-O?

(00:29:57) docker shim und unterstützt Kubernetes noch docker?

(00:32:10) Docker container sind eigentlich Open Container Initiative (OCI) Images und Container

(00:33:21) Woher kommt die Open Container Initiative (OCI) und die Standards?

(00:34:41) Zusammenfassung und die Möglichkeiten eure eigene Runtime zu schreiben

(00:36:31) Ausblick auf die nächste Container-Folge und Feedback

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:00:54)

Container, Kubernetes und Runtimes. Heute machen wir deine Buzzword-Bingo-Karte voll. Willkommen zu einer neuen Episode vom Engineering Kiosk. In Episode 46 haben wir uns mit dem Thema Docker und Container beschäftigt und darüber gesprochen, welches Problem Docker eigentlich löst. Heute gehen wir mal eine Ebene tiefer und klären, Welche Teile aus Docker herausgetrennt wurden, um für das erweiterte Container-Ökosystem nützlich zu sein? Was eine High-Level-Container-Runtime ist und was für Verantwortlichkeiten diese hat? Wie Kubernetes mit einer solchen Runtime kommuniziert? Ob es verschiedene Container-Runtimes gibt? Ob Kubernetes überhaupt Docker unterstützt? Und wir schmeißen Begriffen wie CNCF, OCI, CRI, SHIM und Co. um uns. Wenn du mit Docker noch nicht so viel zu tun hattest, empfehlen wir dir zuerst Episode 46 zu hören. Die heutige Episode kann als Folge 2 davon angesehen werden. Also, Bingo-Karten raus und los geht das Spiel.

Wolfi Gassler (00:00:58 - 00:01:24)

Einen wunderschönen, guten Episodenstart, Andi. Morgen sage ich jetzt nicht, weil es gibt ja vielleicht Leute, die mitten in der Nacht hören. Also einen schönen, guten Episodenstart. Andi, letztes Mal hast du die ganze Hörerschaft, wie du da Spezialist drin bist, schon beleidigt mit deinem Computerbild-Thema Docker. Das heißt, alle, die sich für Docker interessieren, sind Computerbildleser. Möchtest du jetzt, wo wir noch tiefer in Docker einsteigen, schon mal auch wieder irgendwas Beleidigendes am Anfang sagen?

Andy Grunwald (00:01:24 - 00:01:30)

Also wir bewegen uns auf jeden Fall von dem Hype-Thema für die Masse jetzt langsam in dieser Episode ein bisschen weg.

Wolfi Gassler (00:01:30 - 00:01:38)

Moment, die letzte Episode war kein Hype-Thema. Da sind wir in die Tiefen eingedaucht. Das haben höchstwahrscheinlich die wenigsten gewusst, hoffentlich zumindest.

Andy Grunwald (00:01:38 - 00:02:55)

In der letzten Episode haben wir uns um Docker gekümmert. Primär darum, welches Problem Docker eigentlich löst, was die Vorteile sind, was die Nachteile sind, was der Unterschied zu Virtual Machine sind und so weiter und so fort. Und ich muss schon sagen, da Docker ist ja schon sehr lange auf dem Markt ist, kann man schon sagen, es ist ein Hype-Thema, weil es ist nicht nur eine Applikation, die von Linux-Kernel-Freaks genutzt wird, sondern nenn mir mal jemand, der heute in der Softwareentwicklung arbeitet, der noch keine Berührungspunkte mit Docker hat. Ich glaube, diese kleine Gruppe wird sehr schwer zu finden sein. Besonders im Webumfeld ist es natürlich mega gehypt, auch durch die Hyperscaler, Amazon, Google, Microsoft und so weiter, durch deren neuen Services. Natürlich aber auch durch Sachen wie Kubernetes und Co. Deswegen, heute bewegen wir uns ein bisschen weg von diesem Hype und gehen eine Ebene tiefer. Ich will nicht sagen, wir gehen jetzt von der Build zu Computerbuild, sondern ich würde jetzt eher sagen, wir gehen von der Build heute schon, vielleicht sogar schon auf CT-Level vom Heise Verlag. Vielleicht noch nicht auf das IX Level, weil meines Erachtens nach ist das IX Level noch ein bisschen tiefer als das CT Level. Aber ich denke, heute bewegen wir uns so irgendwo zwischen CT und IX. Ich denke, wir gehen nämlich mal ein Layer tiefer. Und das ist ja wohl keine Beleidigung, oder?

Wolfi Gassler (00:02:56 - 00:03:07)

Es gibt sicher jemanden, den du jetzt beleidigt hast, je nachdem, was für Magazine und Zeitschriften wer liest, aber es ist okay. Für mich bist du jetzt einfach der Computerbild-Experte, eindeutig. Das bleibt ja dieser Titel.

Andy Grunwald (00:03:07 - 00:03:14)

Ich muss mal eine Sache offenbaren. Und zwar habe ich früher sehr oft CT gelesen. Also in meinen jüngeren Jahren. Ich auch. Eine super Zeitschrift.

Wolfi Gassler (00:03:14 - 00:03:20)

Es war meine Lieblingszeitschrift damals. Vor allem, da war das Internet noch nicht so weit, wie ich noch jung war zumindest.

Andy Grunwald (00:03:21 - 00:03:40)

Also damals, als ich mit diesen ganzen Computern und Sachen angefangen habe, habe ich natürlich irgendwie so Webseiten gelesen wie WinFuture und was weiß ich, um da mal ein bisschen reinzukommen. heise.de habe ich lange Zeit gar nicht so wirklich so wirklich verstanden. Irgendwann habe ich mal eine CT gekauft, da habe ich dann auch nur Bahnhof Kofferklauen verstanden und echt super lang gebraucht.

Wolfi Gassler (00:03:40 - 00:03:41)

Was hast du verstanden?

Andy Grunwald (00:03:41 - 00:04:31)

Bahnhof Kofferklauen, also eigentlich nix. Bahnhof Kofferklauen. Ich habe die Hälfte der Artikel einfach nicht verstanden. Dann habe ich die mal wieder zur Seite gelegt und irgendwann, so ein Jahr später, habe ich mir wieder eine CT gekauft und dann habe ich die verstanden. So dann ging das so weiter und irgendwann habe ich mir ne ix gekauft da habe ich mir da wieder dann nicht mehr als die hälfte nicht verstanden habe ich die wieder zur seite gelegt und irgendwie ein jahr später habe ich mir wieder ne ix gekauft und dann habe ich angefangen auch die die tieferen artikel von ix besser zu verstehen. Also das war faszinierend, das war so ein bisschen meine Lernkurve mit CT, IX und Computern. Aber wenn du es mit der Print-Medien-Landschaft vergleichen möchtest, ist es genau da. Wir gehen heute nämlich ein Layer tiefer. Nämlich wir gehen nicht ganz runter auf Linux, aber wir gehen ein Layer tiefer als Docker und natürlich spielt da auch der aktuelle Platz hier Kubernetes eine Rolle.

Wolfi Gassler (00:04:31 - 00:04:47)

Okay, dann fangen wir mal ganz vorne an. Ich als normalsterblicher User und nicht als Computerbildexperte, ich rufe da ja einfach docker run auf. Was wäre denn dann die nächste tiefere Ebene? Oder was passiert denn da? Oder ist docker run schon die tiefe Ebene?

Andy Grunwald (00:04:48 - 00:05:54)

In der Programmierung würde man sagen, nein ist es natürlich nicht. Docker Run ist jetzt erstmal das User Interface von der Applikation Docker mit deinem Command Line Parsing und so weiter und so fort mit dem Befehl Start oder Docker Run hast du gerade gesagt und dann dem Image Namen und so weiter und so fort. Jetzt ist es natürlich so, dass Docker durch den Hype, durch die Verbreitung immer mehr Features dazu bekommen hat. Also das Feature-Set, was ihr heute von Docker kennt, das war ja von Anfang an nicht so. Und so wie es in jedem großen Software-Projekt ist, fangen die Software-Engineers da langsam mal an, darüber nachzudenken. Okay, wie können wir die ganze Sache denn hier mal aufteilen? Wie können wir die ganze Sache vielleicht ein bisschen modularer machen? Und als dieser Gedanke dann ein bisschen weitergetrieben wurde, hat man sich überlegt, okay, Docker selbst braucht eine sogenannte Runtime. Und diese Runtime kümmert sich eigentlich um die Verwaltung und das Lifecycle-Management von den eigentlichen Containern. Das war schon immer alles in Docker implementiert. Und als erste Modularisierung haben sie einen Teil dieser Runtime, die sogenannte High-Level-Runtime, rausgetrennt. alleine zur Verfügung gestellt?

Wolfi Gassler (00:05:54 - 00:06:09)

Also am Anfang war es quasi ein Monolith, das war einfach Docker, ein großes Schiff. Und man hat dann angefangen, das in Services, wenn ich es mal so mit dem Hype-Namen benennen darf, rauszutrennen, um das einfach modularer zu machen, um das auch ein bisschen zu öffnen.

Andy Grunwald (00:06:10 - 00:07:06)

Ja, kann man schon so sagen. Ich denke, das war vielleicht gar nicht so freiwillig alles, weil das ganze Thema Container hat natürlich einen mega Pfad aufgenommen. Und da kam natürlich sehr viel Druck von außen. Ich sag nur so Stichwörter wie Kubernetes und Co., da kommen wir aber gleich zu. Und von außen sieht das auf jeden Fall so aus, als hätte Docker, Docker Inc., die Firma dahinter, so ein bisschen die Flucht nach vorne ergriffen und gesagt hat, okay, das Thema Container nimmt Pfad auf, da spielen grad mehr Firmen mit, dann lass uns doch als Platzhirsch etablieren, weil wir haben die Codebase ja schon. Und als ersten Move hat Docker einen Teil ihrer High-Level-Runtime herausgetrennt. Das haben sie als einzelnes Projekt auch released. Und die ganze Sache haben sie, so innovativ wie Docker auch ist, Container-D genannt. D steht in dieser Hinsicht für Daemon, so wie im klassischen Linux-Umfeld bekannt. Und Container-D ist ein einzelner Linux-Daemon mit der Hauptaufgabe, den kompletten Container-Lebenszyklus auf dem Host-System zu managen.

Wolfi Gassler (00:07:07 - 00:07:10)

Was ist denn ein Container Lifecycle?

Andy Grunwald (00:07:10 - 00:07:26)

Da muss man jetzt einmal ganz kurz verstehen. Ich rede die ganze Zeit von High Level Runtime und Low Level Runtime. Im Container-Ecosystem unterscheidet man die ganzen Sachen. Die Low Level Runtime kümmert sich um die Fähigkeiten des Betriebssystems, Container zu erschaffen, zu isolieren und so weiter.

Wolfi Gassler (00:07:26 - 00:07:39)

Also das ist der Teil, der dann mit ChangeRoot und so, wie wir erklärt haben, quasi kommuniziert, beziehungsweise, wenn man sich das so einfach vorstellt, dann dieses ChangeRoot macht und dann mit dem Linux-Betriebssystem in irgendeiner Form kooperiert.

Andy Grunwald (00:07:39 - 00:07:57)

Ganz genau. Kernel, Space, Commands. user space commands, lxc, also linux namespaces, changeroot und all diese magie, von mir aus auch freebsd jails und solaris container und weiß jetzt grad nicht wie es auf windows heißt, aber all diese magie, also der harte kram.

Wolfi Gassler (00:07:57 - 00:07:59)

Der harte kram ist lowlevel, richtig?

Andy Grunwald (00:07:59 - 00:08:13)

Der harte Kram ist Low-Level und das nennt man halt Low-Level-Runtime. Da kommen wir mal irgendwann in Folge 3 oder 4 zu. Auf jeden Fall, wenn es um das Managen des Container-Lebenszyklus geht, dann reden wir in der Regel von einem High-Level, von einer High-Level-Runtime.

Wolfi Gassler (00:08:13 - 00:08:22)

Und was jetzt zum Beispiel das Netzwerk, also die Docker-Netzwerke, die miteinander kommunizieren, ist das dann Low-Level oder ist das dann High-Level?

Andy Grunwald (00:08:22 - 00:08:23)

Das gehört zum High-Level.

Wolfi Gassler (00:08:24 - 00:08:31)

Aber die Ausführung passiert dann auch irgendwo Low-Level natürlich im Betriebssystem, aber die Organisation passiert im High-Level-Team.

Andy Grunwald (00:08:31 - 00:09:39)

Ja, man kann halt einfach sagen, die High-Level-Runtime kümmert sich generell um die Verwaltung von Containern. Und das bedeutet starten, stoppen, pausieren und so weiter. Um das Herunterladen von Images, ja, aus gewissen Repositories oder von Object Storage. Um das Verwalten von Storage und von Netzwerken. Aber auch um die Überwachung von Containern, dass sie auch wirklich ausgeführt werden. Und die High-Level-Runtime gibt der Low-Level-Runtime dann natürlich auch weiter, dass die Containerprozesse tatsächlich erstellt und ausgeführt werden. Also, das ist so der Lebenszyklus, ja? Also, man lädt ein Image runter, es werden Netzwerke erstellt, es wird Storage erstellt, das Image wird vielleicht entpackt. Dann sagt man, okay, dann sagt die High-Level-Runtime, okay, starte das ganze Ding noch mal, und dann wird dieser Startbefehl an die Low-Level-Runtime übergeben. Da wird dann die Linux-Körnermagie gemacht oder halt auch Windows-Körnermagie oder Solaris-Körnermagie. Dann übernimmt die High-Level-Runtime wieder und die kümmert sich dann um die Überwachung des Containers, dass der dann wirklich läuft und all drum und dran. Also der Lebenszyklus von einem Container gemanagt bei der High-Level-Runtime-Container, die in diesem Sinne.

Wolfi Gassler (00:09:39 - 00:09:51)

Das Container-D, wird das dann mitgeschippt mit Docker direkt? Also wenn ich mir jetzt Docker installiere, ist das irgendwo in Docker drin versteckt oder ist das schon sauber herausgelöst?

Andy Grunwald (00:09:51 - 00:10:27)

Beides. Container-D ist sauber herausgelöst. Es ist in einem eigenen GitHub-Repository. Könnt ihr selbst klonen, könnt ihr selbst nutzen. Es ist aber auch so, wenn du Docker, den Docker-Daemon installierst, bekommst du automatisch Container-D mit. Weil sie haben es wirklich so rausgelöst, dass sie es auch selbst immer noch nutzen. Und Containerd wurde halt, wie bereits schon gesagt, von Docker erstellt, von Docker rausgetrennt und wieder integriert, wenn man so möchte. Und Docker verwendet selbst Containerd. Das bedeutet, wenn man Docker installiert, wird Containerd automatisch mit installiert.

Wolfi Gassler (00:10:28 - 00:10:46)

Okay, ich habe jetzt gerade bei mir mal gecheckt auf meinem Fedora Linux. Ich habe einen Container, die wirklich als eigenes Package installiert wurde, scheinbar mit Docker höchstwahrscheinlich dann mal mit installiert. Aber jetzt, wenn du sagst, okay, man kann es auch mit anderen Clients ansprechen. Gibt es da jetzt irgendwas oder ist das nur in der Theorie möglich?

Andy Grunwald (00:10:46 - 00:11:19)

Nee, das ist möglich. Und ich kann dir aus dem Stehgreif eigentlich drei eigene Clients sogar nennen, die in der Praxis ohne Problem möglich sind. Die erste Vorstellung ist, du kannst dir deinen eigenen Client schreiben. Containerd bietet ein Programminginterface an, womit du z.B. in Go recht einfach Images aus der Registry herunterladen kannst, starten kannst usw. Das bedeutet, wenn du dann mal ein bisschen Go schreiben möchtest und dir deinen eigenen Containerclient schreiben möchtest, kannst du das sehr gut tun. Dann gibt es die, dann gibt es eine Implementierung von ContainerD selbst, nennt sich NerdControl für ContainerD-Control.

Wolfi Gassler (00:11:19 - 00:11:24)

Wenn du sagst von ContainerD selbst, dann steckt da wieder Docker dahinter?

Andy Grunwald (00:11:24 - 00:11:24)

Nein.

Wolfi Gassler (00:11:24 - 00:11:26)

Oder ist das mittlerweile ein offener?

Andy Grunwald (00:11:26 - 00:11:46)

Das ist inzwischen ein eigenes Repository, eine eigene Organisation auf GitHub. Klar, die Hauptcontributor sind, so viel ich weiß, immer noch die Leute von Docker, aber ist jetzt nicht mehr an Docker Inc. so stark gebunden. Die Lizenz von Containerd ist nämlich die Apache-2-Lizenz. Von daher ein ganz klassisches Open-Source-Projekt, würde ich mal sagen.

Wolfi Gassler (00:11:47 - 00:11:57)

Okay, und was macht jetzt da deine Wattwitz-Library-Client-Containerd? Man muss das lesen, damit man diesen dummen Wattwitz versteht. Dir hat das sicher gut gefallen, oder?

Andy Grunwald (00:11:57 - 00:12:27)

Bei der Vorbereitung habe ich darüber stark gelacht. Nee, NerdControl ist ein CLI-Interface, was ebenfalls Containerd implementiert. Und als Showcase haben die mal zum Beispiel so tolle Features eingebaut wie Lazy Pulling. Was zum Beispiel Docker von Haus aus nicht kann. Lazy Pulling ist eine Technik, um Container bereits zu starten, bevor das Downloaden von Images komplett abgeschlossen ist. Wie es unten runter funktioniert, weiß ich leider nicht. Klingt auf jeden Fall recht geil.

Wolfi Gassler (00:12:27 - 00:12:37)

Das heißt aber, Container D ist auch ziemlich flexibel, weil das Downloaden übernimmt höchstwahrscheinlich Container D, das Starten auch. Das heißt, die greifen da schon ziemlich tief dann ein.

Andy Grunwald (00:12:37 - 00:13:04)

Genau, wie ich gerade gesagt habe, Container D übernimmt alle möglichen Aufgaben von einer High-Level-Runtime. Beim Starten eines Containers übergibt er natürlich irgendwann die Kontrolle an die Low-Level-Runtime, je nach Betriebssystem und Co. Aber was halt zum Starten alles dazu gehört, Volumes, Storage, Netzwerk, Namen checken von bereits existierenden Containern, damit du keinen Namenskonflikt hast und so weiter und so fort. All sowas übernimmt natürlich dann die Container, die High-Level-Container, Runtime-Container D in der Hinsicht.

Wolfi Gassler (00:13:04 - 00:13:06)

Okay, und was ist jetzt deine Nummer drei?

Andy Grunwald (00:13:06 - 00:13:11)

Nummer drei ist Kubernetes. Kubernetes kann nämlich ebenfalls mit der High-Level-Runtime-Container D zusammenarbeiten.

Wolfi Gassler (00:13:11 - 00:13:15)

Okay, das heißt Kubernetes verwendet gar kein Docker?

Andy Grunwald (00:13:15 - 00:13:20)

Ja, die Antwort auf diese Frage ist jetzt ja und nein. Ich weiß, das bringt dich jetzt nicht weiter.

Wolfi Gassler (00:13:20 - 00:13:23)

Korrekt. Dann erklär mal. Computerbildspezialist.

Andy Grunwald (00:13:23 - 00:13:25)

Dafür müssen wir ein bisschen ausholen.

Wolfi Gassler (00:13:25 - 00:13:33)

Unser Computerbildspezialist holt jetzt ein bisschen aus, um den Unterschied zwischen Container, die Docker und die Verwendung in Kubernetes zu erklären. Herr Grunwald.

Andy Grunwald (00:13:33 - 00:13:51)

In den ersten Tagen von Kubernetes hat Kubernetes wirklich mit der Docker CLI geredet. Die hatten eine sogenannte Docker-Shim eingebaut, um Container von Docker zu supporten, zu starten und so weiter, und haben dann die ganze Verwaltung an Docker abgegeben, haben sich dann die Resultate rausgeholt.

Wolfi Gassler (00:13:52 - 00:14:00)

Das heißt, die haben quasi Docker Run aufgerufen auf der Shell, wenn man es jetzt ganz dumm sieht, so wie ich das mache. Nur Kubernetes hat das halt automatisch für mich gemacht.

Andy Grunwald (00:14:01 - 00:14:08)

Ja, mit hoher Wahrscheinlichkeit haben sie das schon halt, weil Kubernetes auch in Go geschrieben ist, sich dann die Packages rein importiert und das dann auf programmatischem Level gemacht.

Wolfi Gassler (00:14:08 - 00:14:10)

Kannst du einfach sagen, ja, oder?

Andy Grunwald (00:14:10 - 00:14:19)

Mich würde es sehr stark wundern, wenn die wirklich einen Shell-Command mit Docker Run gefeuert hätten und sich dann auf Exit-Code-Basis da irgendwas runtergeholt hätten. Aber von daher, Jetzt bin ich extra.

Wolfi Gassler (00:14:19 - 00:14:32)

Auf deine Ebene vom Computerbild gegangen, dass man das möglichst auf einfache Sicht auf die Dinge, aber du musst natürlich das wieder auf der tiefen Sicht sehen. Aber da merkt man halt, dass du der Spezialist bist, der Computerbildspezialist.

Andy Grunwald (00:14:32 - 00:14:45)

Auf jeden Fall hat das die ganze Zeit super funktioniert. Und ich weiß nicht, aber kannst du dich noch an die Zeit erinnern? Das war in den ersten Tagen, wo Docker so gehypt wurde, da gab's nämlich einen sehr, sehr großen Competitor, nannte sich CoreOS.

Wolfi Gassler (00:14:45 - 00:14:46)

Um ehrlich zu sein, an mir vorbeigegangen.

Andy Grunwald (00:14:47 - 00:15:03)

CoreOS war ein Operating System, was alles in Containern hatte. Das bedeutet, jeder einzelne Prozess auf dem Operating System lief in Containern. Und die hatten eine eigene High-Level-Runtime, die nannte sich RKT, kurz für Rocket.

Wolfi Gassler (00:15:04 - 00:15:05)

Okay, das sagt mir wieder was.

Andy Grunwald (00:15:05 - 00:16:05)

Und weil ja Kubernetes jetzt der Container-Scheduler mehr und mehr an Market-Share begriffen hat, wurde irgendwann die Frage gestellt, ja Moment mal, aber Kubernetes hat jetzt Docker eingebunden, aber ich möchte jetzt Kubernetes auf CoreOS laufen lassen und da läuft die High-Level-Runtime-Rocket. Geht das? Und die Antwort war erst mal nein. Was dann gemacht wurde, Rocket wurde ähnlich wie Docker in Kubernetes implementiert. Und du merkst schon, wohin das geht. Jeder Softwareentwickler, da kräuseln sich so langsam die Finger und Fußnägel, weil du kannst dir vorstellen, zu diesen Zeiten gab es jetzt kein standardisiertes Interface zwischen Docker und Rocket. Das bedeutet, irgendwo gab es so eine If-Else-Condition oder so eine Switch-Condition. Wenn wir jetzt hier auf der Container-Runtime-Docker unterwegs sind, dann führe bitte dieses Set an Befehlen aus. Und wenn wir auf dem Container Runtime Rocket sind, dann führen wir bitte den linken Pfad da aus. Und jetzt stell dir mal vor, wo wir heute wären, wenn dies einfach so weitergegangen wäre. Das wäre ein Riesenprogrammierpfeil mit if else, if else, if else.

Wolfi Gassler (00:16:05 - 00:16:11)

Genau, und jeder gute Programmierer, wenn er so ein Case hat, macht dann ein Interface üblicherweise.

Andy Grunwald (00:16:11 - 00:16:45)

Und das ist es nämlich. Die Jungs und Mädels von Kubernetes sind nämlich sehr gute Programmierer und immer wieder gedacht, hey, das kann nicht so weitergehen, wir brauchen hier mal eine Abstraktion. Und dann hat Kubernetes die sogenannte CRI, die Container, das Container Runtime Interface erstellt. Das Container Runtime Interface ist eine Kubernetes API. Die wurde im Dezember 2016 eingeführt. Nur mal kurz zur Timeline. Container D, der erste Commit von Container D als Raustrend war im November 2015, also ein Jahr davor. Ihr merkt schon, das hängt alles miteinander zusammen.

Wolfi Gassler (00:16:45 - 00:17:01)

Man könnte jetzt sagen, das war natürlich einfach ... Der Lauf der Zeit, Container, die wird schön rausgetrennt, danach gibt's ein Interface, die lieben sich alle. Aber was man so mitbekommen hat, war das ja eher alles zu Krieg und etwas unfreiwilliger, das Ganze, oder? Und wer behauptet den Markt?

Andy Grunwald (00:17:01 - 00:17:19)

Also so tief steck ich in der Politik nicht drin, aber ich glaub, ich kann das recht einfach zusammenfassen. Überall, wo sehr viel Geld im Spiel ist, und im ganzen Container-Ökosystem ist sehr viel Geld im Spiel, da wird sich, glaub ich, auch gezankt. Ja, weil Geld verändert Menschen und da wird dann hier und da natürlich auch um Marketshare gekämpft.

Wolfi Gassler (00:17:19 - 00:17:39)

Aber dieses Container-Runtime-Interface, das jetzt Kubernetes da gebaut hat, haben die das allein gebaut oder ist das ein Konsortium, das dahinter steckt? Weil klassischerweise gewinnt man ja so den Marktkrieg am ehesten mit so einem Konsortium oder wenn da möglichst viele an Bord sind. Und war der Dockerfall mit dem Spiel auch? Oder waren das Gegner dann?

Andy Grunwald (00:17:39 - 00:18:06)

Wer jetzt alles an der CRI wirklich dran war, um die zu erstellen, kann ich dir nicht sagen. Was ich dir sagen kann, ist, dass es halt nur ein Interface, nur eine Kubernetes-API ist. Und jetzt zum Beispiel in Mesos oder in Nomad oder vielleicht sogar in EKS, im Amazon-Service, vielleicht ist die Container-Runtime-Interface gar nicht da drin. Es ist halt primär eine Kubernetes-API, die wird definiert, standardisiert und spezifiziert.

Wolfi Gassler (00:18:07 - 00:18:18)

Aber wer wer bindet die dann ein jetzt zum beispiel um die um container die jetzt zu verwenden implementiert dann implementiert dann container die dieses interface oder gibts da ein zwischenteil noch.

Andy Grunwald (00:18:18 - 00:18:26)

Du hörst dich an wie ein wie ein früherer java entwickler wir haben eine abstraktion lassen wir nochmal eine abstraktion und drunter drauf setzen damit wir ja flexibel sind.

Wolfi Gassler (00:18:27 - 00:18:39)

Nein, ich denke mir nur, wenn Docker zum Beispiel da die Gegner sind, dann werden die ja nicht freiwillig da irgendein Interface implementieren von Kubernetes. Oder vielleicht schon, keine Ahnung, wenn es der Markt will, aber ist halt die Frage.

Andy Grunwald (00:18:39 - 00:19:09)

Kubernetes hat dieses Runtime Interface definiert. Containerd selbst hat ein Plugin drin, um dieses Runtime-Interface zu supporten. Das bedeutet, du kannst Container D, wenn du so möchtest, über zwei Arten ansprechen. Einmal über dieses klassische Runtime-Interface, das würde ich empfehlen, weil du dann von Haus aus, wenn du aus deiner selbstgeschriebenen Container-CLI oder aus Nerd-CTL ein Runtime starten möchtest und du implementierst das Container-Runtime-Interface, dann bist du automatisch in der Lage, verschiedene High-Level-Runtimes zu nutzen.

Wolfi Gassler (00:19:09 - 00:19:12)

Aber Docker nutzt wahrscheinlich intern ihr eigenes Ding.

Andy Grunwald (00:19:13 - 00:19:16)

Das weiß ich nicht. Müsste ich mal nachgucken. Können wir mal recherchieren und nachreichen.

Wolfi Gassler (00:19:17 - 00:19:20)

Oder falls es jemand weiß, bitte gerne eine Message schreiben.

Andy Grunwald (00:19:20 - 00:19:38)

Die Container-Runtime-Interface definiert eigentlich nur eine API zwischen Kubernetes und der Container-Runtime. Im Speziellen die Art und Weise, wie Kubernetes mit verschiedenen Container-Runtimes interagiert, also auch wieder den Lifecycle-Manage, bedeutet Container erstellen, runterladen, verwalten, bla, bli, blub.

Wolfi Gassler (00:19:38 - 00:19:42)

Das heißt, Kubernetes spricht über das Container-Runtime-Interface mit Container-D.

Andy Grunwald (00:19:42 - 00:20:17)

Das ist korrekt. Würdest du einem Techniker, der sich ein bisschen tiefer mit Kubernetes auskennt, genau das so an den Kopf werfen und dir sagen, kann man mal ein bisschen konkreter werden? Also Kubernetes selbst ist ja auch wieder ein Riesenschiff und besteht aus etlichen Komponenten, wie zum Beispiel einem API-Server oder einem Kubelet. Ein Kubelet ist eigentlich dieser kleine Agent, der auf jeder Node läuft, auf jedem Server, wo Container gestartet werden können. Also du musst dir vorstellen, es gibt eine Kubernetes Management Plane und dann gibt sie die kleinen fleißigen Bienchen, das sind die Worker Nodes, die von der Management Plane die Aufgaben kriegen. Launch mal bitte fünf Container.

Wolfi Gassler (00:20:17 - 00:20:29)

Also das ist das Docker in Kubernetes quasi. Das, was ich so von der Command-Line kenne, das ist der Docker-Host, den Kubernetes gemacht hat. Und der spricht dann mit Containerd.

Andy Grunwald (00:20:29 - 00:20:58)

Genau, sowas nennt man Kubelet im Kubernetes-Universum. Das bedeutet, die eigentlichen Worker-Nodes, das Kubelet, hat die Container-Runtime-Interface implementiert. Das Kubelet kriegt dann die Aufgaben vom Kubernetes API Server und startet dann Container durch die Container Runtime Interface, zum Beispiel jetzt Container D, weil Kubernetes kann nur High-Level Container Runtimes bedienen, die auch das Container Runtime Interface unterstützen und implementieren.

Wolfi Gassler (00:20:58 - 00:21:05)

Gibt's da jetzt noch andere außer Container D, dieses Rocket Shifter? Ist die Rocket schon abgestürzt, oder gibt's die noch?

Andy Grunwald (00:21:05 - 00:21:48)

Die Rocket ist in der Hinsicht leider abgestürzt. Im ganzen Containerkrieg gibt es leider auch Verlierer. Und zwar ist es CoreOS und Rocket und das ganze Ecosystem drumherum. Die Projekte sind alle eingestellt. Ich weiß gar nicht, wann Kubernetes dann, oder ob es da noch Leichen im Code gibt von Kubernetes mit Rocket, das weiß ich jetzt grade nicht. Was ich aber weiß ist, dass es neben Container-D, weil wir haben ja jetzt ein Container-Runtime-Interface und ein Interface ermöglicht ja andere Implementierungen, neben Container-D gibt es jetzt auch Container-Runtime-Interface-O, also kurz für Cryo. Ich weiß nicht genau wie man es richtig ausspricht, aber es gibt eine alternative High-Level-Runtime neben Container-D als Alternative.

Wolfi Gassler (00:21:49 - 00:22:10)

Also wer übrigens jetzt schon ausgestiegen ist von unseren HörerInnen, wir werden so ein Übersichtsdiagramm auf Twitter gleich mit posten. Das heißt, wenn ihr die Folge hört, schaut euch dieses Diagramm an, dann ist es vielleicht auch leichter zu folgen. Weil wenn wir jetzt das Container Runtime Interface haben und jetzt haben wir das Container Runtime Interface, was nennt sich dieses, für was steht dieses O schon wieder? Schon wieder vergessen.

Andy Grunwald (00:22:11 - 00:22:22)

Ich würde mal fast sagen, Für Open. Ich weiß es grad gar nicht. Es steht leider ... Ich hab's nicht gefunden, wofür das O steht. Aber ich würd mal sagen, es ist ein Open-Source-Projekt für Container Runtime Interface Open.

Wolfi Gassler (00:22:22 - 00:22:36)

Also, mir ist ja mit Bild schon das fast zu schwierig, dir zu folgen. Okay, es gibt jetzt einen zweiten Platzhirsch, würd ich fast sagen. Oder neben Container D dieses Cryo. Und was kann jetzt dieses Cryo oder wer steht hinter diesem Cryo und warum nicht Container D?

Andy Grunwald (00:22:37 - 00:23:03)

Naja, Container D, hatten wir ja gesagt, wurde von Docker erstellt. Und jetzt stell dir mal vor, du wärst ebenfalls eine große Firma in dem ganzen Sektor. Nehmen wir mal als ganz klassisches Beispiel Red Hat oder IBM oder Intel oder Suse. Wie geil findest du das, einen Großteil deines Businesses, deines zukünftigen Businesses, weil du möchtest ja auch was vom Stück vom Containerkuchen abhaben, dich dann 100% auf Docker zu verlassen? So als Firma, so aus der Business-Sicht.

Wolfi Gassler (00:23:03 - 00:23:18)

Okay, das klingt schon wieder ganz danach, dass sich die anderen zusammengetan haben, wir machen jetzt ein Gegenprodukt. Dann lass mich raten, hinter diesem Cryo steht ein Konsortium mit SUSE, was für andere Linux-Distributionen Red Hat hast du genannt, die ganze Linux-Mafia steckt da dahinter?

Andy Grunwald (00:23:18 - 00:24:17)

Wir nennen das jetzt einfach mal Cryo, das hört sich an so wie cry, wir müssen weinen. Aber ja, in der Tat. Und zwar Cryo wurde mit der Unterstützung von Red Hat, IBM, Intel und SUSE als Container-Runtime für Kubernetes entwickelt, weil diese Firmen haben natürlich auch ein Interesse, im ganzen Container-Ökosystem dabei zu sein. Wie zum Beispiel gibt es ja noch OpenShift. Ich glaube OpenShift ist von Red Hat. Die nutzen unten drunter natürlich auch Kubernetes, ja, also die haben dann ihre eigenen Distros da oben drauf gesetzt oder es abgewandelt. Und die wollten natürlich ihr Business jetzt nicht auf einen der Hauptkonkurrenten, wie zum Beispiel Docker, stützen, der natürlich dann die Hand über Containerd hatte. Deswegen haben wir gesagt, okay, cool, es gibt jetzt dieses Container-Runtime-Interface. Jeder kann seine eigene High-Level-Container-Runtime schreiben. Deswegen lass uns doch mal zusammentun gegen den Platz hier, der als erstes da war, Docker ein bisschen ankämpfen und lass uns mal eine alternative Implementierung zu Container D schaffen. Und daraus entstand dann jetzt Cryo.

Wolfi Gassler (00:24:17 - 00:24:27)

Aber ich habe gerade gelesen, dass Cryo Cloud-Native-Computing-Foundation-Project ist. Da steckt Docker auch mit dabei, oder? In der Cloud-Native-Foundation.

Andy Grunwald (00:24:27 - 00:26:58)

Ja und nein. Also gehen wir nochmal einen Schritt zurück. Was ist die Cloud Native Compute Foundation? Die Cloud Native Compute Foundation ist ein Teil der Linux Foundation und die bundeln eine ganze Menge Projekte in diesem Cloud Native Space zusammen. und kümmern sich darum, dass die Entwicklung von diesen ganzen Tools und Programmen weitergetrieben wird. Dass die Qualität vielleicht nicht gewissen Standards entspricht, aber dass da genug Maintainer sind, dass da ein ordentlicher Security-Prozess drauf ist, dass da ordentlich Marketing drauf ist, blabliblub. Also diese Foundation ganz oben drauf kümmert sich eigentlich um die komplette Governance und Co. Und in so einer Foundation gibt es verschiedene Projektlevel. Ähnlich wie die Apache Foundation. Und zwar gibt's da so was wie Graduated, Incubating, Sandbox und Archived. Archived sind erst mal Sachen, die eingestampft wurden. Ja, das sind die Nichtverlierer, aber die haben sich nicht so entwickelt wie gedacht. Zum Beispiel die Container Runtime Rocket ist ein Archived Cloud-Native-Compute-Foundation-Projekt. Und jetzt stell dir vor, du machst ein neues Cloud-Projekt. Du machst jetzt die Wolfgang Container Runtime. Die spricht mit dir auf Österreichisch und die ist optimiert, um auf Bergen zu laufen. Und du sagst, hey, pass mal auf, ich möchte auch Governance haben. Dann kannst du dich bei der Cloud Native Compute Foundation bewerben und dann wird dein Projekt vielleicht, wenn du Glück hast, erstmal in Sandbox aufgenommen und dann musst du dich halt ein bisschen beweisen. Kriegst du es maintained und kriegst du genug Maintainer und hat das genug Traction? Ist das wirklich relevant für das ganze Ökosystem? Und dann steigst du eigentlich mit deinem Projekt ein bisschen auf. Irgendwann kommst du vielleicht in den incubating Bereich, incubating bedeutet jedes Projekt, was im incubating, was Minimum im incubating state ist, wird als stabil angesehen und du kannst es erfolgreich in Produktion einsetzen. Und dann die Königsklasse ist zum Beispiel dann graduated Projekte, das sind so die Flaggschiffe der Cloud Native Und was ist jetzt Cryo? Cryo selbst ist noch im Incubating. Das bedeutet eigentlich, wenn wir sagen, okay, Archived ist Level 0, Sandbox ist Level 1, Incubating ist Level 2 und Graduated ist Level 3 und mehr Level ist immer besser, wissen wir ja alle, dann ist Cryo bereits auf Level 2, somit als stabil anerkannt und somit kannst du Cryo selbst als Container Runtime, als High Level Container Runtime in Produktion einsetzen. nach der Klassifizierung der Cloud-Native Computing Foundation.

Wolfi Gassler (00:26:58 - 00:27:13)

Man muss schon sagen, mit den Contributors Red Hat, Intel, SUSE, Hyper, Microsoft oder Hyper-V, Microsoft, IBM, da stecken dann schon ziemliche Größen dahinter, muss man schon sagen. Also da ist wahrscheinlich auch ziemlich Druck drauf.

Andy Grunwald (00:27:13 - 00:27:22)

Cryo selbst wird ja als Alternative zu Container D gebaut und Container D ist ein graduated Projekt in der Cloud Native Computing Foundation.

Wolfi Gassler (00:27:22 - 00:27:23)

Das ist dann höher oder?

Andy Grunwald (00:27:23 - 00:27:34)

Das ist dann höher. Das heißt aber nicht, dass das eine irgendwie stabiler ist als das andere oder ähnliches. Generell kannst du Kubernetes mit beiden Runtimes konfigurieren, also eigentlich sogar mit mehr.

Wolfi Gassler (00:27:34 - 00:27:45)

Wenn ich jetzt so ein Kubernetes installiert habe oder irgend so ein Managed Kubernetes verwende, woher weiß ich dann überhaupt, was dieses Ding verwendet im Hintergrund? Oder gibt es da einen Standard? Ist es immer Containerd?

Andy Grunwald (00:27:45 - 00:28:24)

Defaultmäßig kommt es natürlich darauf an, wer betreibt den Kubernetes Cluster. Ich kann mir schon sehr gut vorstellen, dass wenn du ein Managed Kubernetes Cluster auf Google betreibt, dass sie vielleicht sogar ihre eigene Container-Runtime haben, wie zum Beispiel gVisor oder sowas. Aber wenn ihr Kubernetes in der Firma einsetzt, dann fragt doch einfach mal ab, welche Container-Engine ihr benutzt mit kubectl describe-node und dann den Node-Name. Ich hatte ja vorhin erzählt, die kleinen Worker-Nodes, die Kubelets, die reden mit der Container-Runtime deswegen. Wenn ihr euch die Beschreibung, die Infos von einer aktuellen Node holt mit kubectl describe node, dann seht ihr auch, welche Container Engine, welche High-Level Container Engine ihr dort betreibt.

Wolfi Gassler (00:28:24 - 00:28:29)

Okay und was ist jetzt im Endeffekt besser? ContainerD oder Cryo oder wo ist der Unterschied überhaupt?

Andy Grunwald (00:28:30 - 00:29:22)

Ich lehne mich mal aus dem Fenster und sage, für 95, 98, 99 Prozent der Leute, die Kubernetes, beziehungsweise Docker, beziehungsweise diese High-Level-Container-Runtimes betreiben, da werden die meisten Funktionen identisch sein wie bei Containerd. Cryo selbst hat als Marketing-Claim, dass es für Kubernetes optimiert ist und dass sie committed sind, alle Kubernetes-Tests erfolgreich auszuführen. Ist natürlich ein bisschen logisch, wenn das als Referimentsimplementierung für die Container-Runtime-Interface gebaut wurde. Ist halt immer ein bisschen Marketing. Es gibt jetzt nicht das Kernfeature, wo die sich unterscheiden. Deswegen für die meisten Leute ist das, glaube ich, völlig egal. Cryo selbst kommt aber zum Beispiel auch bei Minikube im Einsatz. Minikube ist so eine Art Mini-Kubernetes, was viele Leute lokal betreiben, um zum Beispiel einen kompletten Kubernetes-Stack auf dem Laptop zu betreiben für die Entwicklung. Da kommt Cryo, wird da mitgeliefert.

Wolfi Gassler (00:29:23 - 00:29:26)

Heißt es dann, es ist irgendwie leichter oder so als Container D?

Andy Grunwald (00:29:27 - 00:29:50)

Unten drunter tun die sich, glaube ich, nicht wirklich viel an Ressourcen, weil beide sind in Go geschrieben, beide managen den Lifecycle von Containern. Und ich meine, das Heavy Lifting macht ja eh die Low-Level-Runtime. Das bedeutet ein bisschen was runterladen, ein bisschen was entpacken. Ich weiß jetzt nicht, inwieweit da jetzt große Performance-Unterschiede drin sind oder ob die, wenn du überhaupt Applikationen erst hochfährst, ob das überhaupt irgendwie zu Buche schlägt.

Wolfi Gassler (00:29:50 - 00:30:05)

Jetzt hast du dir sicher Feinde unter der Cryo-Community gemacht. Also wenn ihr wisst, wo ein großer Unterschied ist oder wenn ihr glaubt, irgendwo ist ein großer Unterschied, lasst es uns wissen. Wir freuen uns dann natürlich auf Input. Wo liegen die wirklichen Stärken von Cryo gegenüber Container?

Andy Grunwald (00:30:05 - 00:30:18)

Wir reden jetzt natürlich darüber Anfang Dezember 2022. Das Container-Ekosystem ist immer noch in Flux und entwickelt sich tierisch schnell. Die ganze Sache kann Anfang 2023 natürlich anders aussehen.

Wolfi Gassler (00:30:18 - 00:30:38)

Also okay, Cuplets greifen über das Container-Runtime-Interface auf ContainerD und Cryo zu und ContainerD und Cryo machen dann das ganze Image-Downloading, Image-Container-Handling und so weiter drunter. Du hast am Anfang Docker-Shim erwähnt. Spielt das jetzt noch irgendwo eine Rolle? Wird der Docker noch irgendwo verwendet? Also das klassische Docker?

Andy Grunwald (00:30:38 - 00:31:42)

Die Antwort ist nein. Kubernetes selbst supportet, wenn man ganz genau ist, kein Docker mehr. Du hattest die Docker-SHIM erwähnt. Nochmal ganz kurz zur Begriffserklärung. Eine SHIM, S-H-I-M, ist eigentlich ein API-Übersetzungslayer, wenn man so möchte. Das bedeutet, man setzt eine Zwischenebene rein, fängt die API-Abrufe ab, passt die übergebenen Parameter an, leitet die Aufrufe um oder fühlt sich gegebenenfalls selbst die Operation aus. Die ganze Shim introduced man eigentlich zur Kompatibilitätserweiterung und ihr könnt euch schon vorstellen, dass wenn sich unten drunter ein bisschen was ändert, dann muss man kontinuierlich diese Shim anpassen, was jetzt auch in der Programmierung nicht wirklich schön und nicht wirklich sauber ist. Deswegen hat Kubernetes vor einiger Zeit gesagt, wir droppen Docker Support. Das war auf jeden Fall die große Überschrift, die durch die sozialen Medien gegangen ist und jeder, der gar nicht so tief im Container-Ekosystem war, hatte irgendwie so Angst. Oh nein, oh nein, oh nein, kann ich jetzt keine Docker-Container mehr auf Kubernetes starten? Da war die Kommunikation vielleicht etwas optimierungsbedürftig.

Wolfi Gassler (00:31:42 - 00:31:43)

Vielleicht bewusst sogar.

Andy Grunwald (00:31:43 - 00:32:02)

Vielleicht auch bewusst sogar, man weiß es nicht, aber in diesem Satz, Kubernetes droppt Docker-Support, stecken halt unglaublich viele Probleme. Weil, was ist Docker? Hatten wir schon in der ersten Episode, auch in dieser Episode. Docker ist ja nicht gleich Docker. Docker ist Docker Inc., das ist Docker CLI, die High-Level-Runtime, blablabla.

Wolfi Gassler (00:32:02 - 00:32:05)

Aber kann ich jetzt meine Docker-Images auf Kubernetes noch verwenden?

Andy Grunwald (00:32:05 - 00:32:50)

Ja, kannst du. Und der Grund ist ganz einfach, was Docker gedroppt hat, ist die Docker-Shim. Und die Docker-Shim wurde durch Container-Runtime-Interface ersetzt, was dann wieder zur Folge hat, dass Container-D, wenn du so möchtest, oder halt auch Cryo, Docker-Container ausführen kann. Docker-Container ausführen kann in dieser Hinsicht aber auch nur in Anführungszeichen, weil immer wenn wir von Docker-Container entsprechen, sprechen wir inzwischen von Container-Images, die dem OCI-Standard entsprechen. OCI, Open Container Initiative, ist mal wieder ein neues Konsortium, was ein paar Standards festgelegt hat, wie zum Beispiel so ein Container-Image auszusehen hat, wie man das entpacken kann und wie man damit agieren kann. Die haben da oben ein Standard drauf gesetzt.

Wolfi Gassler (00:32:50 - 00:32:59)

Die Aber wenn ich jetzt in Zukunft mit EntwicklerInnen spreche und ich sage, ja, ich habe jetzt gerade ein OCI-Image hochgefahren, wie viele Leute verstehen mich denn?

Andy Grunwald (00:32:59 - 00:33:16)

Ja, das kommt, glaube ich, darauf an, mit wem du dann sprichst. Sprichst du mit der Frontend-Abteilung, die dann in der Regel GraphQL und Next.js machen, die werden dich wahrscheinlich nicht so gut verstehen. Sprichst du mit der DevOps-Cloud-Systems-System-Engineers-SAE-Abteilung, in der Regel sollten die dich dann schon verstehen, was du meinst, ja.

Wolfi Gassler (00:33:16 - 00:33:17)

Sollten zumindestens.

Andy Grunwald (00:33:17 - 00:33:32)

Die Aussage ist ja nicht falsch. Das bedeutet, wenn du einen Docker-Run machst auf deiner lokalen Kiste, fährst du eigentlich dann ein OCI-formatiertes und kompatibles Container-Image hoch mit der High-Level-Runtime-Engine Container-D.

Wolfi Gassler (00:33:32 - 00:33:43)

Aber wenn ich das richtig verstehe, dann ist dieser OCI-Standard aus dem Docker-Image-Standard entstanden. Also der kommt von Docker Inc. Die haben das dort reingebracht, diesen Standard.

Andy Grunwald (00:33:43 - 00:34:12)

Da kommen wir wieder ein bisschen in die Politik und in dieses Business-Spiel. Ja, weil mehr und mehr Leute in dieses ganze Container-Ökosystem kamen, haben mehr und mehr Leute geschrieben, hey, lass doch mal einen Standard machen, damit wir zum Beispiel auch irgendwie Docker-Image starten können. Auch die Docker-Image-Spezifikation hat sich natürlich weiterentwickelt. Da gibt's Docker Version 1, Image-Spezifikation und Version 2. Und die Version 2 wurde als Basis für die Open-Container-Initiative als Image-Spezifikation genutzt, genau.

Wolfi Gassler (00:34:12 - 00:34:22)

Und das heißt jetzt, dass auch Docker innerhalb von der OCI das Ganze weiterentwickelt. Also die kochen nicht mehr ihr eigenes Süppchen, sondern fahren jetzt in dieser gemeinsamen Spezifikation weiter.

Andy Grunwald (00:34:22 - 00:34:47)

Genau, zusammen mit anderen großen Schiffen wie Alibaba, Amazon, Cisco, Facebook, Google, Intel und so weiter und so fort. Jeder, der sagt, okay, ich möchte da einen Fuß in der Tür haben, ist in dieser Open-Container-Initiative. Jetzt ist es natürlich für die einzelnen Runtimes und für die einzelnen CLIs natürlich schon noch von Interesse, ein eigenes Feature-Set obendrauf zu bauen, was dann aber natürlich nicht kompatibel zur Spezifikation wird.

Wolfi Gassler (00:34:47 - 00:35:08)

Weil wahrscheinlich alle HörerInnen jetzt ihr Bullshit-Bingo bereits voll haben und wahrscheinlich alle schon bei Bingo sind mit Docker, mit Kubernetes, mit Kubelet, mit Container Runtime Interface, ContainerD, Cryo und der Open Container Initiative und Cloud Native Computing Foundation. Darum wollen wir euch jetzt gar nicht länger noch mit der Low Level, wie heißt dieses Ding?

Andy Grunwald (00:35:08 - 00:35:15)

Low Level Container Runtime und weiteren Spezifizierungen und Konsortien.

Wolfi Gassler (00:35:16 - 00:35:43)

Genau, da wollen wir euch jetzt nicht weiter noch nerven. Wichtig, was ich mir mitgenommen habe, ist einfach, es ist nicht mehr alles Docker. Es gibt gemeinsame Spezifikationen wie die Open Container Initiative, wo das Ganze weitergetrieben wird. Kubernetes verwendet nicht mehr den Docker Monolithen sozusagen, sondern greift jetzt eben über das Container Runtime Interface auf ContainerD oder Cryo als Stellvertreter auch.

Andy Grunwald (00:35:43 - 00:35:44)

Oder auf die Wolfgang Runtime.

Wolfi Gassler (00:35:44 - 00:35:57)

Die bald natürlich hoffentlich veröffentlicht wird, greift auf diese Runtime zu, die sich dann um das ganze Image Handling, Netzwerk, das Hochfahren von den Containern und so weiter kümmert. Habe ich das richtig so zusammengefasst, Andi?

Andy Grunwald (00:35:57 - 00:36:14)

Ja, ich würde sagen, das hast du recht gut zusammengefasst. Summa summarum kann man natürlich für die Programmierer auch sagen, Durch diese ganze Modularisierung wurde natürlich auch sehr viel Möglichkeit für eigene Side-Projects gestartet. Das bedeutet, falls ihr mal Bock habt, eure eigene Container-Runtime zu schreiben, habt ihr.

Wolfi Gassler (00:36:14 - 00:36:19)

Jetzt ... Ja, mir krippelt's schon unter den Fingern. Also, ich werde jetzt gleich losstarten mit meiner Wolfgang-Runtime.

Andy Grunwald (00:36:19 - 00:37:19)

Guckt mal ein bisschen auf GitHub, da sind so ein paar gute Starts. Es gibt auch diverse Implementierungen. Crye und Containerd sind mit hoher Wahrscheinlichkeit schon die Referenzimplementierungen für die ganzen Standards soweit. Wir sind jetzt ein Layer tiefer als Docker gegangen, haben ein bisschen den Kontext zu Kubernetes mit erklärt. In zukünftigen Folgen werden wir nochmal ein Layer tiefer gehen und die Layer tiefer werden sich dann um Themen wie die Open Cortina-Initiative drehen, inklusive der Runtime und der Image-Spezifikation. Dann gehen wir vielleicht noch ein bisschen ein auf die Low-Level-Runtime. Zum Beispiel sowas wie Run-C oder Cutter-Containers. Und wenn wir irgendwann die Zeit nochmal haben, dann wie das eigentlich auf den einzelnen Betriebssystemen aussieht. Aber bis dahin wünschen wir euch viel Spaß. Wir verlinken natürlich eine ganze Menge relevante Links, wo ihr euch ein bisschen tiefer einlesen könnt in den Shownotes. Inklusive einem sehr gut beschreibenden Bild mit ganz vielen Pfeilen, wie die ganzen Technologien dann wirklich zusammenhalten in den Shownotes. Deswegen viel Spaß beim Eintauchen.

Wolfi Gassler (00:37:19 - 00:37:29)

Und was ganz wichtig ist, wenn ihr Leute beeindrucken wollt, was früher das HTML ist, doch keine Programmiersprache war, ist jetzt, ich verwende doch einen OCI-Container, keinen Docker-Container.

Andy Grunwald (00:37:29 - 00:37:34)

Ich muss gerade lachen, aber schön klug scheißen, gefällt mir immer richtig gut.

Wolfi Gassler (00:37:34 - 00:37:38)

Und damit bis zur nächsten Episode. Schickt uns auch gerne Feedback. Tschau. Tschüss.