‫Lassen Sie mich Ihnen von Trockenläufen und Diffs erzählen,
‫was neu ist.
‫Die letzten Versionen von Kubernetes beginnen mit 1. 13 haben diese
‫neue Option, mit der wir sehen können, was
‫wir ändern werden, bevor wir es ändern.
‫Das haben wir schon mal gesehen.
‫Ich habe Ihnen vorhin einige Beispiele gezeigt.
‫Diese Methode zur Verwendung mit dem
‫Befehl apply ist jedoch neu
‫und besser. Was wir in der Vergangenheit
‫hatten, war, dass wir einen Trockenlauf hatten, aber es war nur
‫auf den Kunden. Der Client hat nicht mit
‫dem Server gesprochen, um zu sagen, ob diese Ressourcen bereits vorhanden sind.
‫Muss ich sie neu erstellen oder werden sie aktualisiert oder was
‫wird passieren? Richtig.
‫Das ist vorher nicht passiert.
‫Jetzt gibt es eine Server-Trockenlaufoption, die unsere
‫YAML an den Server sendet und vergleicht, herausfindet,
‫was tatsächlich passieren muss, und dann an
‫die Befehlszeile zurückmeldet, was sich
‫ändern wird. Lassen Sie uns das in Aktion sehen.
‫Ich bin im K8s YAML-Verzeichnis, wie ich bereits in einer Vorlesung besprochen
‫habe. Wenn Sie sich im Repo von Docker Mastery befinden und dieses Verzeichnis
‫nicht haben, müssen Sie einen
‫GIT-Pull durchführen, um die neuesten Updates zu erhalten.
‫Dies ist eine Datei, die wir in einer
‫früheren Vorlesung gesehen haben, App. yml. Dies ist ein Dienst
‫und eine Bereitstellung in einer Datei.
‫Technisch gesehen werden mit einem Apply-Befehl zwei
‫Ressourcen erstellt, die miteinander verbunden sind.
‫Der Dienst verwendet einen Selektor, über den wir
‫noch nicht gesprochen haben. Selektoren sind, wie ein Objekt
‫die Ressourcen findet, mit denen es sprechen oder etwas
‫tun möchte.
‫Ein Service muss mit Pods sprechen, also muss er einen Weg finden, um
‫zu diesen zu gelangen.
‫Es verwendet Selektoren als wesentlichen
‫Mustervergleich, um die Beschriftungen der Schlüssel und
‫Werte dort abzugleichen. Wenn ich hier den traditionellen
‫Trockenlauf machen würde, dann würde der Kunde sich nur die Bewerbung ansehen
‫und sagen: Ja, ich werde diese Objekte erstellen.
‫Gut. Es wird immer wiederkommen und sagen, erschaffen.
‫Das liegt daran, dass die Bewerbung nicht
‫sehr spezifisch ist. Wenn Sie ein Update oder
‫einen Befehl zum Erstellen oder Löschen verwendet haben, ist
‫das meiner Meinung nach wiederum kein sehr DevOps-basierter Workflow.
‫Diese Befehle würden nur einen Probelauf machen und Sie wissen,
‫dass das Update ja sagen
‫würde, beide werden aktualisiert. Aber es weiß nicht wirklich auf
‫Ihrem Cluster, richtig. Es hat nicht mit dem Server gesprochen, um das herauszufinden.
‫Wir möchten versuchen, den Server-Testlauf durchzuführen, der standardmäßig
‫für 1 aktiviert ist. 13 und neuer.
‫Wenn ich das tue, wird es dann mit dem Server sprechen und
‫mir eine richtige Antwort geben.
‫Lassen Sie uns fortfahren und dies schaffen.
‫Ich werde den Server trocken laufen lassen.
‫Dadurch werden die beiden Ressourcen, die Bereitstellung und der
‫Dienst, erstellt.
‫Wenn ich nun auf den Aufwärtspfeil drücke und zum Trockenlauf
‫des Servers zurückkehre, wird angezeigt, dass beide unverändert sind.
‫Es sagt mir nicht, was sich geändert hat oder ob es
‫etwas gab, das sich ändern würde,
‫was es sein würde. Es sagt mir nur, dass
‫eine Ressource geändert oder nicht geändert wird. Es ist eine Art Umschalter, ja oder nein.
‫Was ist mit dem tatsächlichen Unterschied zwischen dem, was
‫wir dem Server geben möchten, und dem
‫aktuellen Status unserer Ressourcen?
‫Das ist der Kubectl Diff Befehl.
‫Wenn ich es einfach als Diff anstatt als Apply
‫bezeichne, wird die YAML, die ich habe, mit der
‫Spezifikation verglichen, die sich auf den Servern befindet, die
‫jetzt ausgeführt werden. Dieser Status kehrt zurück, und das
‫wird sich ändern. Lass uns das tun.
‫Es wird nichts sagen, weil es keinen Unterschied gibt.
‫Aber was ist, wenn wir die YAML ändern?
‫Was ist, wenn ich die Replikate in zwei ändere?
‫Dann füge ich ein Label in die Metadaten ein und gebe es
‫in etwa ... so etwas wie.
‫Server dmz.
‫Ich habe es erfunden. Ist eigentlich egal.
‫Dann haben wir die Repliken von zwei.
‫Wenn ich den gleichen Unterschied mache, kommt es mit den Vor-
‫und Nachteilen zurück.
‫Wenn Sie es gewohnt sind, Unterschiede zu lesen, ist
‫dies für Sie absolut sinnvoll. Wenn Sie nicht an Diffs gewöhnt sind, bedeutet
‫das Minus, dass die Zeile nicht mehr angezeigt wird.
‫Dann würden diese Zeilen hinzugefügt.
‫Hier unten wird angezeigt, welche Zeile und welches
‫Zeichen in der Zeile entfernt
‫wird.
‫Dies wird hinzugefügt.
‫Die YAML-Formatierung bleibt erhalten, was sehr schön ist.
‫Es lässt uns wissen, dass mehrere Änderungen stattfinden.
‫Toll. Natürlich ist dies nicht wirklich so
‫etwas wie ein Kanarienvogel oder eine Testbereitstellung oder so.
‫Es geht nicht darum, das Ding zu machen und dann zu sehen,
‫was das Ergebnis ist. Es geht wirklich nur um die
‫Spezifikation, die es in den Akten hat, und die Spezifikation, die wir auf
‫unserer Festplatte haben. Weitere
‫Informationen dazu finden Sie auf den Ressourcen-Links.
‫Es ist ein Blog-Artikel des Kubernetes-Teams über die
‫Zukunft dieser und darüber, wie sie aus der
‫Beta herauskommen werden. Denken Sie daran, diese Funktionen sind im
‫Moment Beta, zumindest in 1. 15 sie sind.
‫Hoffentlich können Sie damit Ihren eigenen Workflow zum Erstellen von
‫YAMLs von Grund auf neu erstellen,
‫die Spezifikationen in diesen YAMLs verwalten und dann den Befehl apply
‫immer wieder verwenden, um Ihre Änderungen vorzunehmen.
‫Das ist eine viel
‫DevOps-freundlichere Infrastruktur.
‫Alles, was Sie tun, ist hoffentlich in Git dokumentiert.
‫Wir hoffen, dass Sie für jede Änderung, die Sie an Ihrer YAML vornehmen,
‫ein GIT-Commit durchführen, bevor Sie sie auf dem Server bereitstellen.
‫Dann haben Sie diese nette Dokumentation in Git, sowie die
‫Dokumentation, wenn Sie so etwas wie ein Diff machen, um zu
‫sehen, was Sie haben und was tatsächlich läuft.