Plattform ermöglicht die Automatisierung von , einschließlich in der Infrastruktur von Cloud-Service-Anbietern, auf Virtualisierungsplattformen oder in Bare-Metal-Systemen. Um eine echte Cloud-Plattform zu schaffen, mussten wir alle verwendeten Elemente strengen Kontrollen unterziehen und damit die Zuverlässigkeit des komplexen Automatisierungsprozesses erhöhen.
Die offensichtliche Lösung war die Verwendung von Red Hat Enterprise Linux CoreOS (einer Variante von Red Hat Enterprise Linux) und CRI-O als Standard, und das aus folgenden Gründen …
Da das Thema Schifffahrt eine sehr geeignete Analogie zur Erklärung der Funktionsweise von Kubernetes und Containern bietet, versuchen wir, die Geschäftsprobleme, die CoreOS und CRI-O lösen, anhand eines Beispiels zu erläutern, . Im Jahr 1803 stand Mark Brunel vor der Aufgabe, 100.000 Blocksysteme für die Bedürfnisse der wachsenden Handelsflotte Großbritanniens herzustellen. Ein Blocksystem ist eine Art Ausrüstung, die verwendet wird, um Seile an Segeln zu befestigen. Bis zum Anfang des 19. Jahrhunderts wurden diese Blöcke von Hand gefertigt, aber Brunel gelang es, die Produktion zu automatisieren und begann mit der Herstellung von standardisierten Blöcken mit Maschinen. Die Automatisierung dieses Prozesses bedeutete, dass alle Blöcke nahezu identisch waren, bei einer Beschädigung leicht ausgetauscht werden konnten und in großen Mengen hergestellt werden konnten.
Und jetzt stellen Sie sich vor, Brunel müsste diese Arbeit für 20 verschiedene Modelltypen von Schiffen (Kubernetes-Versionen) und für fünf verschiedene Planeten mit völlig unterschiedlichen Meeresströmungen und Winden (Cloud-Anbieter) erledigen. Außerdem war es erforderlich, dass alle Schiffe (OpenShift-Cluster), unabhängig von den Planeten, auf denen sie navigieren, sich aus der Sicht der Kapitäne (Operatoren, die die Cluster verwalten) gleich verhalten. Um in der maritimen Analogie zu bleiben, ist es den Kapitänen völlig egal, welche Blocksysteme (CRI-O) auf ihren Schiffen verwendet werden – für sie ist wichtig, dass diese Blöcke robust und zuverlässig sind.
Vor OpenShift 4 steht eine sehr ähnliche geschäftliche Herausforderung als Cloud-Plattform. Neue Knoten müssen beim Erstellen des Clusters, bei einem Ausfall eines der Knoten oder beim Skalieren des Clusters erstellt werden. Bei der Erstellung und Initialisierung eines neuen Knotens müssen auch kritische Host-Komponenten wie CRI-O entsprechend konfiguriert werden. Wie in jeder Produktion muss zunächst „Rohmaterial“ bereitgestellt werden. Bei Schiffen sind Metall und Holz das Rohmaterial. Bei der Erstellung eines Hosts für die Bereitstellung von Containern im OpenShift 4-Cluster müssen jedoch Konfigurationsdateien und bereitgestellte API-Server vorhanden sein. Danach wird OpenShift das erforderliche Maß an Automatisierung während des gesamten Lebenszyklus gewährleisten und die notwendige Produktunterstützung für Endbenutzer bieten und so die Investitionen in die Plattform amortisieren.
OpenShift 4 wurde so entwickelt, dass es eine einfache Aktualisierung des Systems über den gesamten Lebenszyklus der Plattform (für Versionen 4.X) für alle großen Anbieter von Cloud-Computing, Virtualisierungsplattformen und sogar Bare-Metal-Systemen ermöglicht. Zu diesem Zweck müssen Knoten auf der Grundlage von interoperablen Komponenten erstellt werden. Wenn der Cluster eine neue Version von Kubernetes benötigt, erhält er auch die entsprechende Version von CRI-O auf CoreOS. Da die Version von CRI-O direkt an Kubernetes gebunden ist, vereinfacht dies weitgehend alle Umstellungen zum Testen, Debuggen oder Unterstützen. Darüber hinaus ermöglicht dieser Ansatz, die Kosten für Endbenutzer und Red Hat zu senken.
Dies ist ein grundsätzlich neuer Ansatz für Kubernetes-Cluster, der die Basis für die Planung neuer, sehr nützlicher und attraktiver Funktionen legt. CRI-O (Container Runtime Interface – Open Container Initiative, kurz CRI-OCI) hat sich als die beste Wahl für die Massenproduktion von Knoten erwiesen, die für die Arbeit mit OpenShift erforderlich ist. CRI-O ersetzt die zuvor verwendete Docker-Engine und bietet OpenShift-Benutzern. – ja, Sie haben richtig gehört – eine langweilige Container-Engine, die speziell für die Arbeit mit Kubernetes entwickelt wurde.
Die Welt der offenen Container
Die Welt bewegt sich schon seit langem in Richtung offener Container. Sei es in Kubernetes oder auf niedrigeren Ebenen, führt zu einem Ökosystem aus Innovationen auf jeder Ebene.
Alles begann mit der Gründung der Open Containers Initiative . In dieser frühen Phase wurden die Spezifikationen für Container und entwickelt. Dadurch wurde sichergestellt, dass Werkzeuge einen einheitlichen Standard und ein einheitliches Format haben, um damit zu arbeiten. Später wurden die Spezifikationen für hinzugefügt, was es den Nutzern erleichterte, .
Dann entwickelte die Kubernetes-Community einen einheitlichen Standard für die Anbindung, bekannt als . Dadurch konnten Kubernetes-Nutzer verschiedene Engines zur Arbeit mit Containern zusätzlich zu Docker anschließen.
Ingenieure von Red Hat und Google erkannten den Bedarf auf dem Markt an einer Container-Engine, die Anfragen von Kubelet über das CRI-Protokoll entgegennehmen konnte, und stellten Container vor, die mit den oben genannten OCI-Spezifikationen kompatibel waren. So Aber Moment, haben wir nicht gesagt, dass dieses Material CRI-O gewidmet ist? Tatsächlich ist das so, mit der Einführung von wurde das Projekt in CRI-O umbenannt.
Abb. 1.
Innovationen mit CRI-O und CoreOS
Mit dem Start der Plattform OpenShift 4 wurde die Standard-Container-Engine, die in der Plattform verwendet wird, von Docker auf CRI-O umgestellt, das eine wirtschaftliche, stabile, einfache und langweilige Umgebung zum Ausführen von Containern bietet, die parallel zu Kubernetes entwickelt wird. Dies vereinfacht die Unterstützung und Konfiguration des Clusters erheblich. Die Konfiguration und Verwaltung der Container-Engine und des Hosts wird im Rahmen von OpenShift 4 automatisiert. Ganz genau, mit der Einführung von OpenShift 4 ist es nun nicht mehr nötig, sich mit separaten Hosts zu verbinden, die Container-Engine zu installieren, den Speicher zu konfigurieren, Server für die Suche einzurichten oder das Netzwerk zu konfigurieren. Die Plattform OpenShift 4 wurde vollständig überarbeitet, um die
Стоп, как это?
benötigten Ressourcen effizient zu nutzen. nicht nur aus der Sicht der Endbenutzeranwendungen, sondern auch aus der Sicht der grundlegenden Operationen auf Plattformebene, wie z.B. das Bereitstellen von Images, das Konfigurieren von Systemen oder das Installieren von Updates.
Kubernetes hat es den Benutzern immer ermöglicht, Anwendungen zu verwalten, indem sie den gewünschten Zustand definieren und , um sicherzustellen, dass der Ist-Zustand dem angestrebten Zustand so weit wie möglich entspricht. Dieser eröffnet große Möglichkeiten sowohl für die Entwicklung als auch für die Operationen. Entwickler können den erforderlichen Zustand definieren, dem Operator in Form einer YAML- oder JSON-Datei übergeben, und dann kann der Operator in der Produktionsumgebung die erforderliche Instanz der Anwendung erstellen, wobei der Arbeitszustand dieser Instanz vollständig dem gewünschten Zustand entspricht.
Durch die Verwendung von Operatoren in der Plattform bringt OpenShift 4 diese neue Paradigmen (unter Verwendung des Konzepts des gewünschten und des Ist-Zustands) in das Management von RHEL CoreOS und CRI-O. Die Aufgaben zur Konfiguration und Versionsverwaltung des Betriebssystems und der Container-Engine werden durch den sogenannten automatisiert. Der MCO vereinfacht die Arbeit des Cluster-Administrators erheblich, indem er im Wesentlichen die letzten Phasen der Installation sowie die anschließenden Operationen nach der Installation (Day Two Operations) automatisiert. All dies macht OpenShift 4 zu einer echten Cloud-Plattform. Darauf werden wir später noch eingehen.
Container starten
Benutzer hatten die Möglichkeit, die CRI-O-Engine in der OpenShift-Plattform seit Version 3.7 im Status Tech Preview und seit Version 3.9 im Status Generally Available (derzeit unterstützt) zu verwenden. Darüber hinaus nutzt Red Hat massiv in OpenShift Online seit Version 3.10. All dies hat dem Team, das an CRI-O arbeitet, umfangreiche Erfahrungen im massenhaften Start von Containern in großen Kubernetes-Clustern verschafft. Um ein grundlegendes Verständnis dafür zu erhalten, wie Kubernetes CRI-O nutzt, schauen wir uns die folgende Abbildung an, die das Funktionsprinzip der Architektur zeigt.
Abb. 2. Wie Container in einem Kubernetes-Cluster funktionieren
CRI-O vereinfacht die Erstellung neuer Container-Hosts durch die Synchronisation der gesamten oberen Ebene bei der Initialisierung neuer Nodes sowie bei der Veröffentlichung neuer Versionen der OpenShift-Plattform. Die Gesamtrevision der Plattform ermöglicht transaktionale Updates/Rollbacks und vermeidet gegenseitige Blockaden in den Abhängigkeiten zwischen dem Kernel des Container-Hosts, der Container-Engine, den Nodes (Kubelets) und dem Kubernetes-Master. Durch die zentrale Verwaltung aller Komponenten der Plattform mit Versionierungs- und Kontrollmanagement kann immer ein klarer Pfad vom Zustand A zum Zustand B nachverfolgt werden. Dies vereinfacht den Aktualisierungsprozess, erhöht die Sicherheit, verbessert das Performance-Reporting und hilft, die Kosten für Updates und die Installation neuer Versionen zu senken.
Demonstration der Leistungsstärke von austauschbaren Komponenten
Wie bereits erwähnt, bietet die Verwendung des Machine Config Operator zur Verwaltung des Container-Hosts und der Container-Engine in OpenShift 4 ein neues Maß an Automatisierung, das auf der Kubernetes-Plattform zuvor nicht möglich war. Um die neuen Möglichkeiten zu demonstrieren, zeigen wir, wie Sie Änderungen an der Datei crio.conf vornehmen können. Um in der Terminologie nicht durcheinander zu kommen, konzentrieren Sie sich bitte auf die Ergebnisse.
Lassen Sie uns zunächst das erstellen, was als Container-Laufzeitkonfiguration bezeichnet wird – Container Runtime Config. Denken Sie daran, dass dies eine Art Kubernetes-Ressource ist, die die Konfiguration für CRI-O darstellt. Tatsächlich handelt es sich um eine spezialisierte Version von dem, was als MachineConfig bezeichnet wird, das jede Konfiguration darstellt, die auf einem RHEL CoreOS-Maschine im Rahmen des OpenShift-Clusters bereitgestellt wird.
Diese benutzerdefinierte Ressource, genannt ContainerRuntimeConfig, wurde entwickelt, um Cluster-Administratoren die Konfiguration von CRI-O zu erleichtern. Es ist ein leistungsstarkes Werkzeug, das nur auf bestimmten Nodes je nach Konfiguration des MachineConfigPool angewendet werden kann. Betrachten Sie dies als eine Gruppe von Maschinen, die dem gleichen Zweck dienen.
Bitte beachten Sie die letzten beiden Zeilen, die wir in der Datei /etc/crio/crio.conf ändern werden. Diese beiden Zeilen sind sehr ähnlich zu den Zeilen in der Datei crio.conf, nämlich:
vi ContainerRuntimeConfig.yaml
Ausgabe:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Jetzt senden wir diese Datei an das Kubernetes-Cluster und überprüfen, ob sie tatsächlich erstellt wurde. Beachten Sie, dass die Arbeit genau wie bei jeder anderen Kubernetes-Ressource erfolgt:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Ausgabe:
NAME AGE
set-log-and-pid 22h
Nachdem wir die ContainerRuntimeConfig erstellt haben, müssen wir einen der MachineConfigPools ändern, um Kubernetes zu verstehen, dass wir diese Konfiguration auf eine bestimmte Gruppe von Maschinen im Cluster anwenden möchten. In diesem Fall ändern wir den MachineConfigPool für die Master-Knoten:
oc edit MachineConfigPool/master
Ausgabe (zur Veranschaulichung bleibt der Hauptinhalt erhalten):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
An diesem Punkt beginnt der MCO, eine neue Datei crio.conf für das Cluster zu erstellen. Dabei kann die vollständige Konfigurationsdatei über die Kubernetes API eingesehen werden. Denken Sie daran, dass ContainerRuntimeConfig lediglich eine spezialisierte Version von MachineConfig ist, daher können wir das Ergebnis durch einen Blick auf die entsprechenden Zeilen in den MachineConfigs sehen:
oc get MachineConfigs | grep rendered
Ausgabe:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Beachten Sie, dass die erhaltene Konfigurationsdatei für die Master-Knoten eine neuere Version als die ursprünglichen Konfigurationen aufweist. Um sie anzuzeigen, führen Sie den folgenden Befehl aus. Bemerkenswert, dass dies möglicherweise eines der besten Einzeiler-Skripte in der Geschichte von Kubernetes ist:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Ausgabe:
pids_limit = 2048
Jetzt stellen wir sicher, dass die Konfiguration auf allen Master-Knoten angewendet wurde. Zuerst erhalten wir die Liste der Knoten im Cluster:
oc get node | grep master
Ausgabe:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Jetzt schauen wir die installierte Datei an. Sie werden sehen, dass die Datei mit den neuen Werten der Direktiven pid und debug aktualisiert wurde, die wir im ContainerRuntimeConfig-Ressourcen angegeben haben. Die Eleganz selbst:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Ausgabe:
...
pids_limit = 2048
...
log_level = "debug"
...
Alle diese Änderungen im Cluster wurden selbst ohne SSH-Start vorgenommen. Die gesamte Arbeit erfolgte durch Zugriff auf den Master-Knoten von Kubernetes. Das bedeutet, dass diese neuen Parameter nur auf den Master-Knoten konfiguriert wurden. Die Worker-Knoten blieben dabei unverändert, was die Vorteile der Kubernetes-Methodologie zeigt, die definierte und aktuelle Zustände in Bezug auf die Container-Hosts und Container-Engines mit austauschbaren Elementen nutzt.
Das obige Beispiel zeigt die Möglichkeit, Änderungen in einem kleinen OpenShift Container Platform 4-Cluster mit drei Worker-Nodes oder in einem großen Produktionscluster mit 3000 Nodes vorzunehmen. In jedem Fall wird der Arbeitsaufwand gleich bleiben – und ganz gering sein – es reicht aus, die ContainerRuntimeConfig-Datei zu konfigurieren und ein Label im MachineConfigPool zu ändern. Und Sie können dies mit jeder Version der verwendeten Kubernetes-Plattform OpenShift Container Platform 4.X während ihres gesamten Lebenszyklus tun.
Oft entwickeln sich Technologieunternehmen so schnell, dass wir nicht erklären können, warum wir bestimmte Technologien für die grundlegenden Komponenten auswählen. Container-Engines waren historisch gesehen die Komponente, mit der Benutzer direkt interagieren. Da die Popularität von Containern zwangsläufig mit dem Aufkommen von Container-Engines begann, zeigen Benutzer oft Interesse an ihnen. Dies ist ein weiterer Grund, warum Red Hat sich für CRI-O entschieden hat. Container entwickeln sich weiter, wobei heute der Schwerpunkt auf Orchestrierung liegt, und wir sind zu dem Schluss gekommen, dass CRI-O das beste Erlebnis in Kombination mit OpenShift 4 bietet.
Quelle: habr.com
