Plattform ermöglicht es Ihnen, die Erstellung zu optimieren , unter anderem in der Infrastruktur von Cloud-Dienstanbietern, auf Virtualisierungsplattformen oder in Bare-Metal-Systemen. Um eine wirklich cloudbasierte Plattform zu schaffen, mussten wir alle verwendeten Elemente streng kontrollieren und so die Zuverlässigkeit eines komplexen Automatisierungsprozesses erhöhen.
Die offensichtliche Lösung bestand darin, Red Hat Enterprise Linux CoreOS (eine Variante von Red Hat Enterprise Linux) und CRI-O als Standard zu verwenden, und hier ist der Grund …
Da das Thema Segeln sehr gut geeignet ist, um Analogien zur Erläuterung der Arbeit von Kubernetes und Containern zu finden, versuchen wir, anhand eines Beispiels über die Geschäftsprobleme zu sprechen, die CoreOS und CRI-O lösen . Im Jahr 1803 wurde Marc Brunel mit der Produktion von 100 Takelageblöcken für den Bedarf der wachsenden britischen Marine beauftragt. Ein Takelageblock ist eine Art Takelage, mit der Seile an Segeln befestigt werden. Bis Anfang des 19. Jahrhunderts wurden diese Blöcke von Hand hergestellt, doch Brunel gelang es, die Produktion zu automatisieren und begann, standardisierte Blöcke mithilfe von Werkzeugmaschinen herzustellen. Die Automatisierung dieses Prozesses bedeutete, dass die resultierenden Blöcke im Wesentlichen identisch waren, bei Bruch leicht ersetzt werden konnten und in großen Mengen hergestellt werden konnten.
Stellen Sie sich nun vor, Brunel müsste diese Arbeit für 20 verschiedene Schiffsmodelle (Kubernetes-Versionen) und für fünf verschiedene Planeten mit völlig unterschiedlichen Meeresströmungen und Winden (Cloud-Anbieter) durchführen. Darüber hinaus wurde gefordert, dass sich alle Schiffe (OpenShift-Cluster), unabhängig von den Planeten, auf denen die Navigation durchgeführt wird, aus Sicht der Kapitäne (Betreiber, die den Betrieb der Cluster verwalten) gleich verhalten. Um die maritime Analogie fortzusetzen: Schiffskapitänen ist es völlig egal, welche Art von Takelageblöcken (CRI-O) auf ihren Schiffen verwendet werden – das Wichtigste für sie ist, dass diese Blöcke stark und zuverlässig sind.
OpenShift 4 steht als Cloud-Plattform vor einer ganz ähnlichen geschäftlichen Herausforderung. Neue Knoten müssen zum Zeitpunkt der Clustererstellung, im Falle eines Fehlers in einem der Knoten oder bei der Skalierung des Clusters erstellt werden. Wenn ein neuer Knoten erstellt und initialisiert wird, müssen wichtige Hostkomponenten, einschließlich CRI-O, entsprechend konfiguriert werden. Wie bei jeder anderen Produktion müssen „Rohstoffe“ zu Beginn bereitgestellt werden. Bei Schiffen sind die Rohstoffe Metall und Holz. Wenn Sie jedoch einen Host für die Bereitstellung von Containern in einem OpenShift 4-Cluster erstellen, benötigen Sie Konfigurationsdateien und von der API bereitgestellte Server als Eingabe. OpenShift sorgt dann über den gesamten Lebenszyklus hinweg für den erforderlichen Automatisierungsgrad, bietet den Endbenutzern den notwendigen Produktsupport und amortisiert so die Investition in die Plattform.
OpenShift 4 wurde so konzipiert, dass es die Möglichkeit bietet, das System über den gesamten Lebenszyklus der Plattform (für Versionen 4.X) für alle großen Cloud-Computing-Anbieter, Virtualisierungsplattformen und sogar Bare-Metal-Systeme bequem zu aktualisieren. Dazu müssen Knoten auf Basis austauschbarer Elemente erstellt werden. Wenn ein Cluster eine neue Version von Kubernetes benötigt, erhält er auch die entsprechende Version von CRI-O auf CoreOS. Da die CRI-O-Version direkt an Kubernetes gebunden ist, vereinfacht dies alle Permutationen für Test-, Fehlerbehebungs- oder Supportzwecke erheblich. Darüber hinaus reduziert dieser Ansatz die Kosten für Endbenutzer und Red Hat.
Dies ist eine grundlegend neue Denkweise über Kubernetes-Cluster und legt den Grundstein für die Planung einiger sehr nützlicher und überzeugender neuer Funktionen. CRI-O (Container Runtime Interface – Open Container Initiative, abgekürzt CRI-OCI) erwies sich als die erfolgreichste Wahl für die Massenerstellung von Knoten, die für die Arbeit mit OpenShift erforderlich sind. CRI-O wird die bisher verwendete Docker-Engine ersetzen und OpenShift-Benutzern anbieten – Ja, Sie haben richtig gehört – eine langweilige Container-Engine, die speziell für die Arbeit mit Kubernetes entwickelt wurde.
Die Welt der offenen Behälter
Die Welt bewegt sich schon lange in Richtung offener Container. Ob in Kubernetes oder auf niedrigeren Ebenen, führt zu einem Ökosystem der Innovation auf allen Ebenen.
Alles begann mit der Gründung der Open Containers Initiative . In diesem frühen Arbeitsstadium wurden Containerspezifikationen erstellt и . Dadurch wurde sichergestellt, dass die Tools einen einzigen Standard verwenden konnten und ein einheitliches Format für die Arbeit mit ihnen. Spezifikationen wurden später hinzugefügt , sodass Benutzer problemlos Inhalte teilen können .
Die Kubernetes-Community entwickelte daraufhin einen einzigen Standard für eine steckbare Schnittstelle namens . Dadurch konnten Kubernetes-Benutzer neben Docker auch verschiedene Engines anbinden, um mit Containern zu arbeiten.
Ingenieure von Red Hat und Google erkannten einen Marktbedarf für eine Container-Engine, die Kubelet-Anfragen über das CRI-Protokoll akzeptieren konnte, und führten Container ein, die mit den oben genannten OCI-Spezifikationen kompatibel waren. Also . Aber entschuldigen Sie, haben wir nicht gesagt, dass dieses Material CRI-O gewidmet sein würde? Tatsächlich ist es so, nur mit der Veröffentlichung Das Projekt wurde in CRI-O umbenannt.
Fig. 1.
Innovation mit CRI-O und CoreOS
Mit der Einführung der OpenShift 4-Plattform wurde dies geändert , standardmäßig in der Plattform verwendet, und Docker wurde durch CRI-O ersetzt und bietet eine kostengünstige, stabile, einfache und langweilige Umgebung für die Ausführung eines Containers, der parallel zu Kubernetes entwickelt wird. Dies vereinfacht die Clusterunterstützung und -konfiguration erheblich. Die Konfiguration der Container-Engine und des Hosts sowie deren Verwaltung wird in OpenShift 4 automatisiert.
Moment, wie ist das?
Richtig, mit der Einführung von OpenShift 4 besteht keine Notwendigkeit mehr, sich mit einzelnen Hosts zu verbinden und eine Container-Engine zu installieren, Speicher zu konfigurieren, Suchserver zu konfigurieren oder ein Netzwerk zu konfigurieren. Die OpenShift 4-Plattform wurde komplett neu gestaltet, um die zu verwenden nicht nur im Hinblick auf Endbenutzeranwendungen, sondern auch im Hinblick auf grundlegende Vorgänge auf Plattformebene wie die Bereitstellung von Images, die Konfiguration des Systems oder die Installation von Updates.
Kubernetes hat es Benutzern schon immer ermöglicht, Anwendungen zu verwalten, indem sie den gewünschten Status definieren und verwenden , um sicherzustellen, dass der Ist-Zustand möglichst genau mit dem Soll-Zustand übereinstimmt. Das eröffnet großartige Möglichkeiten sowohl aus entwicklungstechnischer als auch betrieblicher Sicht. Entwickler können den erforderlichen Status definieren dem Betreiber in Form einer YAML- oder JSON-Datei übermittelt, und dann kann der Betreiber die erforderliche Anwendungsinstanz in der Produktionsumgebung erstellen, und der Betriebszustand dieser Instanz entspricht vollständig dem angegebenen.
Durch die Verwendung von Operatoren in der Plattform bringt OpenShift 4 dieses neue Paradigma (unter Verwendung des Konzepts von Soll- und Ist-Zustand) in die Verwaltung von RHEL CoreOS und CRI-O ein. Die Aufgaben der Konfiguration und Verwaltung von Versionen des Betriebssystems und der Container-Engine werden mithilfe der sogenannten automatisiert . MCO vereinfacht die Arbeit des Cluster-Administrators erheblich, indem es im Wesentlichen die letzten Phasen der Installation sowie die nachfolgenden Vorgänge nach der Installation (Vorgänge am zweiten Tag) automatisiert. All dies macht OpenShift 4 zu einer echten Cloud-Plattform. Wir werden etwas später darauf eingehen.
Laufende Container
Benutzer haben seit Version 3.7 im Tech Preview-Status und ab Version 3.9 im Generally Available-Status (derzeit unterstützt) die Möglichkeit, die CRI-O-Engine in der OpenShift-Plattform zu nutzen. Darüber hinaus nutzt Red Hat massiv in OpenShift Online seit Version 3.10. All dies ermöglichte es dem Team, das an CRI-O arbeitete, umfangreiche Erfahrungen beim Massenstart von Containern auf großen Kubernetes-Clustern zu sammeln. Um ein grundlegendes Verständnis dafür zu erhalten, wie Kubernetes CRI-O verwendet, schauen wir uns die folgende Abbildung an, die zeigt, wie die Architektur funktioniert.
Reis. 2. Wie Container in einem Kubernetes-Cluster funktionieren
CRI-O vereinfacht die Erstellung neuer Container-Hosts durch die Synchronisierung der gesamten obersten Ebene bei der Initialisierung neuer Knoten und bei der Veröffentlichung neuer Versionen der OpenShift-Plattform. Die Überarbeitung der gesamten Plattform ermöglicht Transaktionsaktualisierungen/Rollbacks und verhindert außerdem Deadlocks in Abhängigkeiten zwischen dem Container-Tail-Kern, der Container-Engine, den Knoten (Kubelets) und dem Kubernetes-Master-Knoten. Durch die zentrale Verwaltung aller Plattformkomponenten mit Kontrolle und Versionierung gibt es immer einen klaren Pfad von Zustand A zu Zustand B. Dies vereinfacht den Aktualisierungsprozess, verbessert die Sicherheit, verbessert die Leistungsberichte und trägt dazu bei, die Kosten für Aktualisierungen und Installationen neuer Versionen zu senken .
Demonstration der Leistungsfähigkeit von Ersatzelementen
Wie bereits erwähnt, bietet die Verwendung des Machine Config Operators zur Verwaltung des Container-Hosts und der Container-Engine in OpenShift 4 einen neuen Automatisierungsgrad, der zuvor auf der Kubernetes-Plattform nicht möglich war. Um die neuen Funktionen zu demonstrieren, zeigen wir, wie Sie Änderungen an der Datei crio.conf vornehmen können. Versuchen Sie, sich auf die Ergebnisse zu konzentrieren, um Verwirrung durch die Terminologie zu vermeiden.
Erstellen wir zunächst eine sogenannte Container-Laufzeitkonfiguration – Container Runtime Config. Betrachten Sie es als eine Kubernetes-Ressource, die die Konfiguration für CRI-O darstellt. In Wirklichkeit handelt es sich um eine spezielle Version von etwas namens MachineConfig, bei dem es sich um jede Konfiguration handelt, die auf einer RHEL CoreOS-Maschine als Teil eines OpenShift-Clusters bereitgestellt wird.
Diese benutzerdefinierte Ressource namens ContainerRuntimeConfig wurde erstellt, um Clusteradministratoren die Konfiguration von CRI-O zu erleichtern. Dieses Tool ist so leistungsstark, dass es abhängig von den MachineConfigPool-Einstellungen nur auf bestimmte Knoten angewendet werden kann. Betrachten Sie es 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 den Zeilen in der Datei crio.conf sehr ähnlich:
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
Lassen Sie uns nun diese Datei in den Kubernetes-Cluster übertragen und überprüfen, ob sie tatsächlich erstellt wurde. Bitte beachten Sie, dass der Vorgang genau der gleiche ist wie bei jeder anderen Kubernetes-Ressource:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Fazit:
NAME AGE
set-log-and-pid 22h
Nachdem wir die ContainerRuntimeConfig erstellt haben, müssen wir einen der MachineConfigPools ändern, um Kubernetes zu signalisieren, 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 Masterknoten:
oc edit MachineConfigPool/master
Fazit (der Übersichtlichkeit halber bleibt das Wesentliche übrig):
...
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 MCO mit der Erstellung einer neuen crio.conf-Datei für den Cluster. In diesem Fall kann die vollständig fertige Konfigurationsdatei über die Kubernetes-API eingesehen werden. Denken Sie daran, dass ContainerRuntimeConfig nur eine spezielle Version von MachineConfig ist. Wir können das Ergebnis also sehen, indem wir uns die relevanten Zeilen in MachineConfigs ansehen:
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 resultierende Konfigurationsdatei für die Masterknoten eine neuere Version als die ursprünglichen Konfigurationen war. Um es anzuzeigen, führen Sie den folgenden Befehl aus. Nebenbei stellen wir fest, dass dies vielleicht einer der besten Einzeiler 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
Stellen wir nun sicher, dass die Konfiguration auf alle Masterknoten angewendet wurde. Zuerst erhalten wir eine Liste der Knoten im Cluster:
oc get node | grep master
Output:
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
Schauen wir uns nun die installierte Datei an. Sie werden sehen, dass die Datei mit den neuen Werten für die PID- und Debug-Anweisungen aktualisiert wurde, die wir in der ContainerRuntimeConfig-Ressource angegeben haben. 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 am Cluster wurden vorgenommen, ohne dass SSH ausgeführt wurde. Die gesamte Arbeit wurde durch Zugriff auf den Kuberentes-Masterknoten erledigt. Das heißt, diese neuen Parameter wurden nur auf Masterknoten konfiguriert. Die Worker-Knoten haben sich nicht geändert, was die Vorteile der Kubernetes-Methodik der Verwendung spezifizierter und tatsächlicher Zustände in Bezug auf Container-Hosts und Container-Engines mit austauschbaren Elementen zeigt.
Das obige Beispiel zeigt die Möglichkeit, Änderungen an einem kleinen OpenShift Container Platform 4-Cluster mit drei Produktionsknoten oder einem großen Produktionscluster mit 3000 Knoten vorzunehmen. In jedem Fall ist der Arbeitsaufwand gleich – und sehr gering – Sie müssen lediglich die ContainerRuntimeConfig-Datei konfigurieren und eine Bezeichnung in MachineConfigPool ändern. Und Sie können dies mit jeder Version der OpenShift Container Platform 4.X tun, auf der während des gesamten Lebenszyklus Kubernetes ausgeführt wird.
Technologieunternehmen entwickeln sich oft so schnell, dass wir nicht erklären können, warum wir bestimmte Technologien für die zugrunde liegenden Komponenten auswählen. Container-Engines waren in der Vergangenheit die Komponente, mit der Benutzer direkt interagieren. Da die Popularität von Containern natürlich mit dem Aufkommen von Container-Engines begann, zeigen Benutzer häufig Interesse an ihnen. Dies ist ein weiterer Grund, warum Red Hat sich für CRI-O entschieden hat. Container entwickeln sich weiter, wobei der Schwerpunkt jetzt auf der Orchestrierung liegt, und wir haben festgestellt, dass CRI-O das beste Erlebnis bei der Arbeit mit OpenShift 4 bietet.
Source: habr.com