Hallo zusammen.
Und willkommen zurück.
Im vorherigen Video hatten wir eine großartige Einführung in die Container-Orchestrierungs-Engine.
Wir hatten ja bereits besprochen, dass es mehrere Orchestrierungs-Engines gibt.
Es gibt also Docker Swarm, Apache Missiles, Kubernetes und verschiedene andere.
Kubernetes ist also bei weitem eine der beliebtesten Container-Orchestrator-Engines, die es gibt.
Und im heutigen Video gibt es eine umfassende Einführung in Kubernetes, gefolgt von einigen
kurzen Demos.
Kubernetes ist eine Open-Source-Engine für die Container-Orchestrierung, die von Google entwickelt wird.
Kubernetes wurde also vollständig von Google entwickelt und gewartet. Später wurde es an die C und ZF,
die Cloud Native Computing Foundation, übergeben, die es derzeit verwaltet.
Kubernetes wird daher auch als k8s in Kurzform bezeichnet.
Der Grund, warum Sie k8s haben, ist, dass Sie zwischen K und S acht Zeichen haben.
Aus diesem Grund wird es auch als K bezeichnet.
Jetzt geht es um die Architektur von Kubernetes.
Sie haben hier einen Kubernetes-Master und die Worker-Nodes.
Worker Nodes sind also im Grunde die physischen Server oder die virtuellen Maschinen, auf denen die Container ausgeführt
werden.
Und der Kubernetes-Master ist derjenige, der die Container verwalten wird.
Der Kubernetes-Master empfängt also grundsätzlich die Befehle der Benutzer.
Nun stellt sich die Frage, wie sie die Befehle empfangen wird.
Er kann also die Befehle über die API, über die CLI und über die Benutzeroberfläche empfangen.
Es gibt also API CLA und GI, über die Benutzer Befehle an den Kubernetes-Master senden können, und der Kubernetes-Master
wird die in den Befehlen genannten Dinge verarbeiten.
Lassen Sie uns dies anhand einer einfachen Analogie verstehen.
Nehmen wir also an, Sie haben einen Befehl mit dem Namen Ich möchte App A starten.
Dies ist also der Befehl, den Sie Kubernetes geben, Master.
Jetzt prüft der Kubernetes-Master, wie viele Knoten er hat.
Derzeit gibt es also drei Knoten, die mit dem Kubernetes-Master verbunden sind.
Die Anwendung wird also in einem der Knoten gestartet.
Nun gibt es verschiedene Algorithmen, auf deren Grundlage ein bestimmter Knoten ausgewählt wird, es ist
also nicht so, dass Knoten A derzeit 100 % der CPU-Last trägt.
In diesem Fall wird der Kubernetes-Master die Anwendung also nicht wirklich an Node one senden.
Er sendet sie an den Knoten, der mehr Ressourcen zur Verfügung hat.
Es gibt also eine Menge Dinge, die hinter den Kulissen passieren, aber im Moment sehen wir hier nur
einen Überblick auf hoher Ebene.
Also gut.
Im Moment haben Sie also den Befehl, der vom Benutzer bereitgestellt wurde, Kubernetes ist Master hat ihn genommen
und den Container in einem der Worker Nodes gestartet.
Nehmen wir nun an, dass dieser Arbeitsknoten aus irgendeinem Grund nicht mehr funktioniert.
Es kann einen Grund geben, warum der Server nicht mehr funktioniert, z. B. ein Stromproblem, eine Netzwerkverbindung, ein
Kernel-Problem oder anderes.
Sobald dieser Arbeitsknoten nicht mehr funktioniert, wird er von Kubernetes Master automatisch erkannt.
So wird automatisch erkannt, dass der Worker-Node nicht richtig funktioniert, und der Container wird auf einen
anderen laufenden Worker-Node verlagert.
Daher wird dies auch als Absichtserklärung bezeichnet.
Die Absichtserklärung ist also im Wesentlichen eine Übersicht über die Absichtserklärung.
Die Absichtserklärung wird also in der Regel vom Benutzer abgegeben, der angibt, dass er eine App in einem Container starten möchte.
Dies ist also der App-Container.
Und als Benutzer sage ich dem Kubernetes-OC, dass ich den App-Container starten möchte, und das war's.
Jetzt brauche ich nichts mehr zu tun.
Kubernetes kümmert sich sowohl um das Starten des Containers als auch um dessen langfristige Verwaltung.
Wie wir bereits besprochen haben, geht es also nicht nur darum, den Container einmalig zu starten.
Es geht auch um den Gesundheitscheck.
Der Kubernetes-Master kann nicht nur erkennen, dass der Knoten ausgefallen ist, sondern auch, dass die Anwendung nicht ordnungsgemäß funktioniert.
Und wenn der App-Container nicht richtig funktioniert, kann er automatisch neu gestartet werden.
Es kann den App-Container automatisch auf verschiedene Worker Nodes und andere migrieren.
Es gibt also eine Menge Dinge, die hinter den Kulissen passieren.
Im heutigen Video lag unser Hauptaugenmerk also auf der Einführung.
Wir wollen uns also nur einen Überblick darüber verschaffen, wie die Dinge funktionieren.
Lassen Sie uns also schnell in die Demo einsteigen, damit wir mehr darüber erfahren.
Ich bin also in meiner Klasse und wir machen schnell einen Würfel.
Knoten erhalten.
Sie sehen, dass ich derzeit einen Knoten habe, der verfügbar ist.
Wir haben also in der Architekturphase darüber gesprochen, dass es einen Kubernetes-Master und mehrere
Worker-Nodes gibt.
Die Worker Nodes sind also im Grunde die Orte, an denen die Container bereitgestellt werden.
Es kann sich also um einen Arbeitsknoten handeln, um 100 oder sogar um 1000.
Das hängt also wirklich davon ab.
Für unsere Demo haben wir also einen Arbeitsknoten, der derzeit verfügbar ist.
Auf der nächsten Folie sprachen wir über die Aufzeichnung der Absicht, wobei durch eines der Medien API
klar sein kann, dass wir eine Aufzeichnung der Absicht geliefert haben.
Die Absichtserklärung war also, dass ich eine App in einem Container starten möchte, also probieren wir es aus.
Ich sage also, es wird laufen, ich nenne es Motor X und ich starte es von dem Image von Motor X.
Sie brauchen sich jetzt keine Gedanken darüber zu machen, wie diese Befehle lauten.
Wir werden diese in dem kommenden Video ausführlich besprechen.
Dieses Video soll Ihnen nur einen Überblick über Kubernetes geben.
Wenn Sie dies ausführen, heißt es, dass die Deployment Engine erstellt wurde.
Und wenn du jetzt einen Würfel machst, bekommt er Häfen.
Sie werden sehen, dass Sie einen Pod haben, der sich gerade in der Erstellungsphase befindet.
Was genau ist also passiert?
Wir haben Kubernetes mitgeteilt, dass wir einen Container aus dem Engine-X-Image starten wollen.
Das ist also der Teil, den wir gemacht haben, und dieser wurde an den Kubernetes-Master geliefert.
Der Kubernetes-Master prüft nun die Worker Nodes und startet dann diesen speziellen Pod in einem
der Worker Nodes.
Sie können den Pod also zunächst als Container bezeichnen.
Kubernetes hat also den Container in einem der Worker Nodes gestartet.
Wenn Sie nun die Seite aktualisieren, werden Sie sehen, dass der Status des aktuellen Boards "in Betrieb" ist.
Jetzt läuft dieser Pod also auf meinem Server, auf dem wir die CLI-Befehle ausführen.
Wenn ich also ein Docker-Stück über die Maschine X mache, dann kann ich diesen Namen kopieren.
Sie werden sehen, dass Sie einen Container mit einem funktionierenden Motor haben.
Also lassen Sie uns jetzt eines tun.
Halten wir diesen Container an und schauen wir, was genau passiert.
Ich sage also: Docker, hör auf.
Gefolgt von dem Container.
Wenn Sie jetzt ein Docker-Stück machen, sollten Sie sehen, dass der erste Container, den wir angehalten hatten,
hier nicht mehr vorhanden ist.
Nun also zur Architektur.
Wir haben also Kubernetes angewiesen, einen Container aus dem Engine-X-Image zu starten.
Kubernetes fuhr fort und erstellte den Container.
Anstatt den Knoten zu löschen, haben wir den Container manuell angehalten.
Oder man kann sagen, wir haben den Container getötet.
Jetzt kann Kubernetes erkennen, dass dieser Container nicht mehr funktioniert, und kann ihn automatisch
starten oder einen neuen Container auf einem anderen Knoten starten.
Wenn Sie also noch einmal sehen wollen, lassen Sie uns ein Docker-Stück machen und Sie werden sehen, dass ein weiterer Container gestartet wurde.
Dieser Container wurde also vor 53 Sekunden gestartet.
Dies ist also eine der großartigen Eigenschaften einer typischen Orchestrator-Engine, in unserem Fall Kubernetes.
Ich hoffe also, dass Sie auf hohem Niveau verstanden haben, was Kubernetes ist.
Auch hier handelt es sich nur um eines der Beispiele, die wir genommen haben.
Kubernetes verfügt über eine Vielzahl von Funktionen, die wir im Laufe des Kurses besprechen
werden.
Bevor wir dieses Video beenden, möchte ich Ihnen noch eine Sache zeigen.
Wir haben also darüber gesprochen, dass es drei Möglichkeiten gibt, wie man Kubernetes mit Befehlen versorgen kann.
Herr Meister, Sie haben die API, Sie haben die Kundenbetreuung und Sie haben die Benutzeroberfläche.
Der CTL-Befehl, den wir in dieser Demo ausgeführt haben, war also ein Beispiel für CLI.
Sie haben auch die Funktion der Benutzeroberfläche.
Wenn Sie also sehen wollen, wie Java genau aussieht, ist dies das UI-Dashboard für Kubernetes.
Wenn Sie also hier in den Knoten sehen, wird angezeigt, dass ein Arbeitsknoten verfügbar
ist.
Es zeigt Ihnen auch die CPU- sowie die speicherbezogenen Spezifikationen dieses spezifischen Arbeitsknotens an.
Darüber hinaus können Sie verschiedene Informationen über die aktuellen Container anzeigen, auf denen
die Daemon-Sets, Bereitstellungen usw. ausgeführt werden. Dies ist also ein großartiges GI, das zur Verfügung steht und
wirklich hilft, Dinge schneller zu verstehen, da die Benutzeroberfläche immer der schnellste Weg ist, Dinge zu demonstrieren.
Das ist also der GI.
Wir haben uns auch mit der CLI befasst und sind sicher, dass man sogar Befehle über die API liefern kann.
Das ist also der grobe Überblick über Kubernetes.
Auch hier haben wir in unserem heutigen Video einen sehr umfassenden Überblick gegeben.
Ich hoffe, Sie haben einen Überblick darüber bekommen, was Kubernetes ist und was es alles kann.
In den kommenden Videos werden wir uns ausführlich mit Kubernetes befassen und viele Funktionen
der Kubernetes-Orchestrator-Engine näher betrachten.
Damit schließe ich dieses Video ab.
Ich hoffe, dieses Video war informativ für Sie, und ich freue mich darauf, Sie im nächsten Video wiederzusehen.