Plattform ermöglicht die Optimierung der Erstellung , 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 streng kontrollieren und dadurch die Zuverlässigkeit des komplexen Automatisierungsprozesses erhöhen.
Eine naheliegende Lösung war die Verwendung von Red Hat Enterprise Linux CoreOS (einer Variante von Red Hat Enterprise Linux) und CRI-O als Standard, und hier ist der Grund dafür …
Da das Thema Seefahrt sich hervorragend eignet, um Analogien zur Erklärung der Funktionsweise von Kubernetes und Containern zu ziehen, versuchen wir, die Geschäftsprobleme, die CoreOS und CRI-O lösen, anhand des Beispiels . Im Jahr 1803 stellte man Marcus Brunel die Aufgabe, 100.000 Takelblöcke für die wachsende Marineflotte Großbritanniens zu fertigen. Ein Takelblock ist eine Art von Ausrüstung, die verwendet wird, um Seile an Segeln zu befestigen. Bis zu Beginn des 19. Jahrhunderts wurden diese Blöcke von Hand hergestellt, doch Brunel gelang es, die Produktion zu automatisieren und standardisierte Blöcke mit Maschinen herzustellen. Die Automatisierung dieses Prozesses führte dazu, dass alle Blöcke praktisch identisch waren, im Falle eines Bruchs leicht ersetzt werden konnten und in großen Mengen gefertigt werden konnten.
Stellen Sie sich nun vor, dass Brünnel diese Arbeit für 20 verschiedene Schiffstypen (Kubernetes-Versionen) und fünf verschiedene Planeten mit völlig unterschiedlichen Strömungen und Winden (Cloud-Anbieter) erledigen müsste. Außerdem war es erforderlich, dass alle Schiffe (OpenShift-Cluster) unabhängig von den Planeten, auf denen sie sich befinden, für die Kapitäne (Betreiber, die die Cluster verwalten) gleich funktionieren. Um in der Seefahrtsmetapher zu bleiben: Den Kapitänen ist es völlig egal, welche Takelungsblöcke (CRI-O) auf ihren Schiffen verwendet werden – für sie ist wichtig, dass diese Blöcke stark und zuverlässig sind.
Vor OpenShift 4 steht eine sehr ähnliche geschäftliche Herausforderung. Neue Knoten müssen beim Erstellen des Clusters, bei einem Ausfall eines Knotens oder beim Skalieren des Clusters erstellt werden. Bei der Erstellung und Initialisierung eines neuen Knotens müssen auch die kritischen Host-Komponenten, einschließlich CRI-O, entsprechend konfiguriert werden. Wie in jeder anderen Produktion muss zu Beginn "Rohmaterial" bereitgestellt werden. Bei Schiffen sind dies Metall und Holz. Bei der Erstellung eines Hosts zur Bereitstellung von Containern im OpenShift 4 Cluster müssen jedoch Konfigurationsdateien und die bereitgestellten API-Server zur Verfügung stehen. Anschließend wird OpenShift das erforderliche Maß an Automatisierung während des gesamten Lebenszyklus gewährleisten und die notwendige Produktunterstützung für die Endbenutzer anbieten, wodurch die Investitionen in die Plattform amortisiert werden.
OpenShift 4 wurde so entwickelt, dass ein unkompliziertes Update der Systeme über den gesamten Lebenszyklus der Plattform (für Versionen 4.X) hinweg für alle großen Anbieter von Cloud-Computing, Virtualisierungsplattformen und sogar Bare-Metal-Systemen ermöglicht wird. Dazu müssen die Knoten auf der Basis austauschbarer Komponenten aufgebaut werden. Wenn ein Cluster eine neue Version von Kubernetes benötigt, erhält es auch die entsprechende Version von CRI-O auf CoreOS. Da die CRI-O-Version direkt an Kubernetes gebunden ist, vereinfacht dies in hohem Maße alle Anpassungen zu Test-, Debugging- oder Supportzwecken. Darüber hinaus trägt dieser Ansatz dazu bei, die Kosten für Endbenutzer und Red Hat zu senken.
Dies ist eine grundlegend neue Sicht auf Kubernetes-Cluster, die die Grundlage für die Planung neuer, sehr nützlicher und attraktiver Funktionen legt. CRI-O (Container Runtime Interface – Open Container Initiative) hat sich als die beste Wahl für die massenhafte Erstellung von Knoten erwiesen, die für die Arbeit mit OpenShift erforderlich sind. CRI-O wird den bisherigen Docker-Engine ersetzen und den OpenShift-Nutzern Vorteile bieten. – ja, Sie haben richtig gehört – eine unauffällige Container-Engine, die speziell für die Arbeit mit Kubernetes entwickelt wurde.
Die Welt der offenen Container
Die Welt geht schon lange in Richtung offener Container. Sei es in Kubernetes oder auf niedrigeren Ebenen, führt zu einem Ökosystem von Innovationen auf jeder Ebene.
Alles begann mit der Gründung der Open Containers Initiative . In dieser frühen Phase wurden die Spezifikationen für die Container- und . Dies gewährleistet, dass die Werkzeuge einen einheitlichen Standard verwenden können, und ein einheitliches Format für die Arbeit mit ihnen. Später wurden Spezifikationen hinzugefügt, , was es den Benutzern ermöglichte, mit Leichtigkeit auszutauschen .
Dann entwickelte die Kubernetes-Community einen einheitlichen Standard für pluggable Interfaces, genannt Dank dieser Möglichkeit konnten Kubernetes-Nutzer verschiedene Container-Engines zusätzlich zu Docker integrieren.
Ingenieure von Red Hat und Google erkannten den bestehenden Bedarf auf dem Markt an einer Container-Engine, die Anfragen vom Kubelet über das CRI-Protokoll entgegennehmen konnte, und entwickelten Container, die mit den oben genannten OCI-Spezifikationen kompatibel waren. So Aber Moment, wir haben doch gesagt, dass dieses Material CRI-O gewidmet ist? Tatsächlich ist es so, denn mit der Veröffentlichung von wurde das Projekt in CRI-O umbenannt.
Abb. 1.
Innovationen mit CRI-O und CoreOS.
Mit der Einführung der OpenShift 4-Plattform wurde der , der standardmäßig in der Plattform verwendet wird, wurde Docker durch CRI-O ersetzt, das eine kostengünstige, stabile, einfache und wenig aufregende Umgebung zum Ausführen von Containern bietet, die parallel zu Kubernetes weiterentwickelt wird. Dies vereinfacht erheblich die Wartung und Konfiguration des Clusters. Die Konfiguration des Container-Engines und des Hosts sowie deren Verwaltung werden im Rahmen von OpenShift 4 automatisiert.
Warte, wie das?
Genau so, mit dem Erscheinen von OpenShift 4 ist es nicht mehr notwendig, sich mit einzelnen Hosts zu verbinden und den Container-Engine zu installieren, Speicher zu konfigurieren, Server für die Suche einzurichten oder das Netzwerk zu konfigurieren. Die Plattform OpenShift 4 wurde vollständig neu gestaltet, um das nicht nur aus der Sicht der Endbenutzeranwendungen, sondern auch aus der Perspektive grundlegender Plattformoperationen wie dem Bereitstellen von Images, der Systemkonfiguration oder der Installation von Updates zu nutzen.
Kubernetes hat es den Benutzern immer ermöglicht, Anwendungen zu verwalten, indem sie den gewünschten Zustand definieren und , um sicherzustellen, dass der tatsächliche Zustand dem festgelegten Zustand bestmöglich entspricht. Dieses öffnet große Möglichkeiten sowohl aus der Entwicklungs- als auch aus der Betriebsperspektive. Entwickler können den erforderlichen Zustand definieren, dem Operator in Form einer YAML- oder JSON-Datei übergeben, und anschließend kann der Operator in der Produktionsumgebung die benötigte Instanz der Anwendung erstellen, wobei der Betriebszustand dieser Instanz vollständig dem festgelegten entsprechen wird.
Durch die Verwendung von Operatoren (Operators) in der Plattform bringt OpenShift 4 dieses neue Paradigma (unter Verwendung des Konzepts von festgelegtem und tatsächlichem Zustand) in die Verwaltung von RHEL CoreOS und CRI-O ein. Die Aufgaben zur Konfiguration und Versionsverwaltung des Betriebssystems und der Container-Engine werden automatisiert durch so genannte . MCO vereinfacht die Arbeit des Cluster-Administrators erheblich, indem es im Wesentlichen die letzten Phasen der Installation sowie die nachfolgenden Operationen (Day-Two-Operationen) automatisiert. All dies macht OpenShift 4 zu einer echten Cloud-Plattform. Darauf werden wir später näher eingehen.
Container starten
Benutzer hatten die Möglichkeit, die CRI-O-Engine in der OpenShift-Plattform ab Version 3.7 im Status Tech Preview und ab Version 3.9 im Status Generally Available (derzeit unterstützt) zu verwenden. Darüber hinaus wird CRI-O von Red Hat in großer Menge eingesetzt. in OpenShift Online ab Version 3.10. Dies hat dem Team hinter CRI-O ermöglicht, umfangreiche Erfahrung im massenhaften Start von Containern auf großen Kubernetes-Clustern zu sammeln. Um grundlegende Einblicke zu erhalten, wie Kubernetes CRI-O nutzt, betrachten wir die folgende Illustration, die das Funktionsprinzip der Architektur zeigt.
Abb. 2. So funktionieren Container in einem Kubernetes-Cluster
CRI-O vereinfacht die Erstellung neuer Container-Hosts durch die Synchronisierung der gesamten oberen Ebene bei der Initialisierung neuer Knoten und bei der Veröffentlichung neuer Versionen der OpenShift-Plattform. Die Überprüfung der gesamten Plattform ermöglicht transaktionale Aktualisierungen/Rollbacks und verhindert gegenseitige Blockierungen in den Abhängigkeiten zwischen dem Container-Host-Kernel, der Container-Engine, den Knoten (Kubelets) und dem Kubernetes-Master-Knoten. Durch die zentrale Verwaltung aller Komponenten der Plattform, mit Versionierungs- und Kontrollfunktionen, lässt sich stets ein klarer Pfad von Zustand A zu Zustand B nachverfolgen. Dies vereinfacht den Aktualisierungsprozess, erhöht die Sicherheit, verbessert das Reporting zur Leistung und hilft, die Kosten für Aktualisierungen und die Installation neuer Versionen zu senken.
Demonstration der Leistungsfähigkeit von austauschbaren Elementen
Wie bereits erwähnt, bietet der Einsatz des Machine Config Operators zur Verwaltung des Containerhosts und der Container-Engine in OpenShift 4 ein neues Automatisierungsniveau, das zuvor auf der Kubernetes-Plattform 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 nicht in der Terminologie verloren zu gehen, konzentrieren Sie sich auf die Ergebnisse.
Zunächst erstellen wir das, was als Container Runtime Config bezeichnet wird. Betrachten Sie dies als eine Art Kubernetes-Ressource, die die Konfiguration für CRI-O darstellt. Tatsächlich handelt es sich um eine spezialisierte Version dessen, was als MachineConfig bekannt ist, und zwar um jede Konfiguration, die auf einer RHEL CoreOS-Maschine im Rahmen des OpenShift-Clusters implementiert wird.
Diese benutzerdefinierte Ressource, die ContainerRuntimeConfig genannt wird, wurde geschaffen, um Clusteradministratoren die Konfiguration von CRI-O zu erleichtern. Es ist ein durchaus leistungsfähiges Werkzeug, das nur auf bestimmten Knoten in Abhängigkeit von den Einstellungen des MachineConfigPool angewendet werden kann. Betrachten Sie dies als eine Gruppe von Maschinen, die demselben Zweck dienen.
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
Fazit:
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 den Kubernetes-Cluster und überprüfen, ob sie tatsächlich erstellt wurde. Beachten Sie, dass dies genau wie bei jedem anderen Kubernetes-Ressource erfolgt:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Fazit:
NAME AGE
set-log-and-pid 22h
Nachdem wir ContainerRuntimeConfig erstellt haben, müssen wir einen der MachineConfigPools ändern, um Kubernetes mitzuteilen, 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 (die wesentlichen Informationen sind zur Veranschaulichung belassen worden):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
In diesem Moment beginnt MCO, eine neue Datei crio.conf für das Cluster zu erstellen. Dabei kann die vollständig vorbereitete Konfigurationsdatei über die Kubernetes API eingesehen werden. Denken Sie daran, dass ContainerRuntimeConfig nur eine spezialisierte Version von MachineConfig ist, sodass wir das Ergebnis sehen können, indem wir die entsprechenden Zeilen in den MachineConfigs betrachten:
oc get MachineConfigs | grep rendered
Fazit:
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
Bitte 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. Lassen Sie uns bemerken, dass dies möglicherweise eines der besten einzeiligen 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
Fazit:
pids_limit = 2048
Jetzt stellen wir sicher, dass die Konfiguration auf alle 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 Bereit master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Bereit master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Bereit master 23h v1.12.4+509916ce1
Nun betrachten wir die installierte Datei. Sie werden sehen, dass die Datei mit den neuen Werten für die Direktiven pid und debug aktualisiert wurde, die wir im ContainerRuntimeConfig-Ressourcendokument 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’
Fazit:
...
pids_limit = 2048
...
log_level = "debug"
...
Alle diese Änderungen im Cluster wurden durchgeführt, ohne SSH zu starten. Die gesamte Arbeit wurde durch die Ansprache des Master-Knotens von Kubernetes erledigt. Das bedeutet, dass diese neuen Parameter nur auf den Master-Knoten konfiguriert wurden. Die Arbeitsknoten blieben unverändert, was die Vorteile der Kubernetes-Methodologie mit vorgegebenen und aktuellen Zuständen für Container-Hosts und Container-Engines mit austauschbaren Komponenten zeigt.
Das obige Beispiel zeigt die Möglichkeit, Änderungen an einem kleinen OpenShift Container Platform 4 Cluster mit drei Worker-Nodes oder an einem großen Produktionscluster mit 3000 Nodes vorzunehmen. In beiden Fällen wird der Aufwand gleich sein – und sehr gering – es genügt, die Datei ContainerRuntimeConfig zu konfigurieren und ein Label im MachineConfigPool zu ändern. Und dies kann mit jeder Version der OpenShift Container Platform 4.X, die in Kubernetes verwendet wird, während ihres gesamten Lebenszyklus durchgeführt werden.
Technologische Unternehmen entwickeln sich oft so schnell, dass es uns schwerfällt zu erklären, warum wir bestimmte Technologien für grundlegende Komponenten auswählen. Container Engines waren historisch betrachtet die Komponente, mit der Benutzer direkt interagieren. Da die Beliebtheit von Containern mit dem Aufkommen von Container Engines begann, zeigen die Benutzer häufig Interesse daran. Das ist ein weiterer Grund, warum sich Red Hat für CRI-O entschieden hat. Container entwickeln sich weiter, wobei der Schwerpunkt heute auf der Orchestrierung liegt, und wir sind zu dem Schluss gekommen, dass CRI-O die beste Erfahrung mit OpenShift 4 bietet.
Quelle: habr.com
