Container-to-Pipeline: CRI-O ist jetzt die Standardeinstellung in OpenShift Container Platform 4

Mit der Red Hat OpenShift Container Platform 4-Plattform können Sie die Erstellung von Hosts für die Bereitstellung von Containern streamen, einschließlich in der Infrastruktur von Cloud-Dienstanbietern, auf Virtualisierungsplattformen oder in Bare-Metal-Systemen. Um eine Cloud-Plattform im vollen Sinne zu schaffen, mussten wir alle verwendeten Elemente genau kontrollieren und damit die Zuverlässigkeit eines komplexen Automatisierungsprozesses erhöhen.



Die naheliegende Lösung bestand darin, Red Hat Enterprise Linux CoreOS (eine Variante von Red Hat Enterprise Linux) und CRI-O als Standard zu verwenden.

Da das Thema Navigation sehr erfolgreich ist, um Analogien zur Erklärung der Funktionsweise von Kubernetes und Containern zu finden, versuchen wir, am Beispiel der Erfindung von Brunel für die Herstellung von Rigging-Blöcken über die Geschäftsprobleme zu sprechen, die CoreOS und CRI-O lösen. Im Jahr 1803 wurde Mark Brunel beauftragt, 100.000 Takelageblöcke für die Bedürfnisse der wachsenden britischen Marine herzustellen. Ein Hebeblock ist eine Art Rig, mit dem Seile an Segeln befestigt werden. Bis zum Beginn des 19. Jahrhunderts wurden diese Blöcke von Hand hergestellt, aber Brunel konnte die Produktion automatisieren und begann, standardisierte Blöcke mit Maschinen herzustellen. Durch die Automatisierung dieses Prozesses waren alle Blöcke nahezu gleich, konnten im Falle eines Ausfalls leicht ausgetauscht und in großen Mengen hergestellt werden.

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) ausführen. Darüber hinaus war es erforderlich, dass sich alle Schiffe (OpenShift-Cluster) unabhängig von den navigierten Planeten aus Sicht der Kapitäne (Betreiber, die den Betrieb der Cluster steuern) identisch verhalten. In Fortsetzung der Marine-Analogie ist es Schiffskapitänen absolut egal, welche Rigging-Blöcke (CRI-O) auf ihren Schiffen verwendet werden - die Hauptsache für sie ist, dass diese Blöcke stark und zuverlässig sind.

OpenShift 4 als Cloud-Plattform steht vor einer sehr ähnlichen geschäftlichen Herausforderung. Neue Knoten müssen zum Zeitpunkt der Erstellung des Clusters, im Falle eines Fehlers in einem der Knoten oder bei der Skalierung des Clusters erstellt werden. Beim Erstellen und Initialisieren eines neuen Knotens müssen kritische Hostkomponenten, einschließlich CRI-O, entsprechend konfiguriert werden. Wie bei jeder anderen Produktion müssen zu Beginn „Rohstoffe“ geliefert werden. Bei Schiffen fungieren Metall und Holz als Rohstoffe. Wenn Sie jedoch einen Host für die Bereitstellung von Containern in einem OpenShift 4-Cluster erstellen, müssen an der Eingabe Konfigurationsdateien und API-Server bereitgestellt werden. Danach bietet OpenShift über den gesamten Lebenszyklus den erforderlichen Automatisierungsgrad, bietet den Endbenutzern den erforderlichen Produkt-Support und zahlt sich somit für Investitionen in die Plattform aus.

OpenShift 4 wurde so entwickelt, dass alle wichtigen Anbieter von Cloud Computing, Virtualisierungsplattformen und sogar Bare-Metal-Systemen das System während des gesamten Lebenszyklus der Plattform (für Version 4.X) bequem aktualisieren können. Dazu müssen Knoten auf Basis austauschbarer Elemente angelegt werden. Wenn ein Cluster eine neue Version von Kubernetes benötigt, erhält er auch die entsprechende CRI-O-Version unter CoreOS. Da die CRI-O-Version direkt an Kubernetes gebunden ist, vereinfacht dies alle Permutationen für Tests, Fehlerbehebung oder Support erheblich. Darüber hinaus reduziert dieser Ansatz die Kosten für Endbenutzer und Red Hat.

Dies ist ein grundlegend neuer Blick auf Kubernetes-Cluster, der die Grundlage für die Planung neuer äußerst nützlicher und attraktiver Funktionen bildet. CRI-O (Open Container-Projekt Container Runtime Interface - Open Container Initiative, abgekürzt CRI-OCI) war die erfolgreichste Wahl für die Massenerstellung von Knoten, die für die Arbeit mit OpenShift erforderlich ist. CRI-O wird die zuvor verwendete Docker-Engine ersetzen und OpenShift-Benutzern eine wirtschaftliche, stabile, einfache und langweilige - ja, Sie haben es richtig gehört - langweilige Container-Engine bieten, die speziell für die Arbeit mit Kubernetes entwickelt wurde.

Die Welt der offenen Container

Die Welt bewegt sich seit langem in Richtung offener Container. Ob bei Kubernetes oder auf niedrigeren Ebenen, die Entwicklung von Containerstandards führt zu einem Ökosystem der Innovation auf allen Ebenen.

Alles begann mit der Gründung der Open Containers Initiative im Juni 2015 . In diesem frühen Arbeitsstadium wurden Spezifikationen für das Container- Image (Image) und die Laufzeit erstellt . Dadurch konnte sichergestellt werden, dass die Tools einen einzigen Standard für Container-Images und ein einziges Format für die Arbeit mit ihnen verwenden können. Später wurden Verteilungsspezifikationen hinzugefügt, mit denen Benutzer Containerbilder problemlos austauschen konnten.

Die Kubernetes-Community entwickelte daraufhin einen einzigen steckbaren Schnittstellenstandard namens Container Runtime Interface (CRI) . Dank dessen konnten Kubernetes-Benutzer neben Docker verschiedene Engines für die Arbeit mit Containern verbinden.

Die Ingenieure von Red Hat und Google sahen eine Marktnachfrage nach einer Container-Engine, die Anfragen von Kubelet mithilfe des CRI-Protokolls annehmen konnte, und führten Container ein, die mit den oben genannten OCI-Spezifikationen kompatibel waren. Es gab also eine OCID . Aber entschuldigen Sie, weil wir gesagt haben, dass dieses Material CRI-O gewidmet sein wird? Tatsächlich wurde das Projekt erst mit der Veröffentlichung von Version 1.0 in CRI-O umbenannt.

Abb. 1.

Innovation mit CRI-O und CoreOS

Mit dem Start der OpenShift 4-Plattform wurde die in der Standardplattform verwendete Container-Engine geändert und Docker durch CRI-O ersetzt, das eine wirtschaftliche, stabile, einfache und langweilige Container-Startumgebung bietet, die sich parallel zu Kubernetes entwickelt. Dies vereinfacht die Clusterunterstützung und -konfiguration erheblich. Das Konfigurieren und Verwalten der Container-Engine und des Hosts wird in OpenShift 4 automatisiert.

Hör auf, wie ist es?

Mit dem Aufkommen von OpenShift 4 ist es jetzt nicht mehr erforderlich, eine Verbindung zu einzelnen Hosts herzustellen und eine Container-Engine zu installieren, Speicher zu konfigurieren, Server für die Suche zu konfigurieren oder ein Netzwerk zu konfigurieren. Die OpenShift 4-Plattform wurde komplett neu gestaltet, um das Operator Framework nicht nur in Bezug auf Endbenutzeranwendungen, sondern auch in Bezug auf grundlegende Vorgänge auf Plattformebene wie das Bereitstellen von Images, das Konfigurieren des Systems oder das Installieren von Updates zu verwenden.

Kubernetes hat es Benutzern immer ermöglicht, Anwendungen zu verwalten, indem der gewünschte Status ermittelt und mithilfe von Controllern sichergestellt wurde, dass der tatsächliche Status dem angegebenen Status so nahe wie möglich kommt. Dieser Ansatz unter Verwendung eines bestimmten Zustands und eines tatsächlichen Zustands eröffnet sowohl aus Sicht der Entwicklung als auch aus Sicht der Operationen große Chancen. Entwickler können den erforderlichen Status ermitteln, ihn in Form einer YAML- oder JSON-Datei an den Bediener übertragen und anschließend die erforderliche Anwendungsinstanz in der Betriebsumgebung erstellen, während der Betriebsstatus dieser Instanz vollständig dem angegebenen entspricht.

OpenShift 4 verwendet Operatoren in der Plattform und bringt dieses neue Paradigma (unter Verwendung des Konzepts von Set und Ist-Status) in die Verwaltung von RHEL CoreOS und CRI-O ein. Die Aufgaben der Konfiguration und Versionierung des Betriebssystems und der Container-Engine werden mithilfe des sogenannten Machine Config Operator (MCO) automatisiert. MCO vereinfacht die Arbeit des Clusteradministrators erheblich und automatisiert im Wesentlichen die letzten Installationsphasen sowie die nachfolgenden Vorgänge nach der Installation (Vorgänge am zweiten Tag). All dies macht OpenShift 4 zu einer echten Cloud-Plattform. Wir werden etwas später darauf eingehen.

Containerstart

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 Allgemein verfügbar (derzeit unterstützt) zu verwenden. Darüber hinaus nutzt Red Hat CRI-O seit Version 3.10 in großem Umfang , um Produktions-Workloads in OpenShift Online zu starten . All dies ermöglichte es dem Team, das an CRI-O arbeitete, umfangreiche Erfahrungen beim Massenstart von Containern in großen Kubernetes-Clustern zu sammeln. Um ein grundlegendes Verständnis der Verwendung von CRI-O durch Kubernetes zu erhalten, sehen wir uns die folgende Abbildung an, die die Funktionsweise der Architektur zeigt.

Abb. 2. Funktionsweise von Containern im Kubernetes-Cluster



CRI-O vereinfacht die Erstellung neuer Container-Hosts, indem die gesamte oberste Ebene beim Initialisieren neuer Knoten und beim Freigeben neuer Versionen der OpenShift-Plattform synchronisiert wird. Ein vollständiges Plattform-Audit ermöglicht Transaktionsaktualisierungen / Rollbacks und verhindert außerdem Deadlocks in Abhängigkeiten zwischen dem Container-Tail-Kernel, der Container-Engine, Kubelets und dem Kubernetes-Master. Mit der zentralen Verwaltung aller Plattformkomponenten sowie der Versionskontrolle und -verwaltung können Sie jederzeit einen eindeutigen Pfad von Status A zu Status B verfolgen. Dies vereinfacht den Aktualisierungsprozess, verbessert die Sicherheit, verbessert die Leistungsberichte und senkt die Kosten für die Aktualisierung und Installation neuer Versionen.

Demonstration der Kraft austauschbarer Elemente

Wie bereits erwähnt, bietet die Verwendung von Machine Config Operator zum Verwalten des Container-Hosts und der Container-Engine in OpenShift 4 einen neuen Automatisierungsgrad, der auf der Kubernetes-Plattform zuvor 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 die Terminologie nicht zu verwechseln.

Lassen Sie uns zunächst eine sogenannte Container-Laufzeitkonfiguration erstellen - die Container Runtime Config. Betrachten Sie dies als eine Kubernetes-Ressource, die die Konfiguration für CRI-O darstellt. In Wirklichkeit handelt es sich hierbei um eine spezielle Version von MachineConfig, bei der es sich um eine Konfiguration handelt, die auf einem RHEL CoreOS-Computer in einem OpenShift-Cluster bereitgestellt wird.

Diese benutzerdefinierte Ressource namens ContainerRuntimeConfig wurde erfunden, um Clusteradministratoren die Konfiguration von CRI-O zu erleichtern. Dies ist ein leistungsstarkes Tool, das abhängig von den Einstellungen von MachineConfigPool nur auf bestimmte Knoten angewendet werden kann. Betrachten Sie dies als eine Gruppe von Maschinen, die denselben Zweck erfüllen.

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. Dies sind:

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 

Senden Sie diese Datei nun an den Kubernetes-Cluster und überprüfen Sie, ob sie tatsächlich erstellt wurde. Bitte beachten Sie, dass der Vorgang wie bei jeder anderen Kubernetes-Ressource ausgeführt wird:

 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, damit Kubernetes versteht, dass wir diese Konfiguration auf eine bestimmte Gruppe von Computern im Cluster anwenden möchten. In diesem Fall ändern wir MachineConfigPool für die Masterknoten:

 oc edit MachineConfigPool/master 

Schlussfolgerung (aus Gründen der Klarheit bleibt der Hauptpunkt übrig):

 ... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ... 

Zu diesem Zeitpunkt beginnt MCO mit der Erstellung einer neuen crio.conf-Datei für den Cluster. In diesem Fall kann eine vollständig fertige Konfigurationsdatei mithilfe der Kubernetes-API angezeigt werden. Denken Sie daran, ContainerRuntimeConfig ist nur eine spezielle Version von MachineConfig, sodass wir das Ergebnis anhand der Zeilen in MachineConfigs sehen können:

 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. Führen Sie den folgenden Befehl aus, um es anzuzeigen. Nebenbei bemerken wir, dass dies wahrscheinlich 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 

Stellen Sie 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 Sie sich nun die installierte Datei an. Sie werden sehen, dass die Datei mit den neuen 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 im Cluster wurden auch ohne Start von SSH vorgenommen. Alle Arbeiten wurden durch Kontaktaufnahme mit dem Kuberentes-Masterknoten durchgeführt. Das heißt, diese neuen Parameter wurden nur auf den Masterknoten konfiguriert. Gleichzeitig haben sich die Arbeitsknoten nicht geändert, was die Vorteile der Kubernetes-Methodik unter Verwendung der festgelegten und aktuellen Zustände für Hosts von Containern und Container-Engines mit austauschbaren Elementen demonstriert.

Das obige Beispiel zeigt die Möglichkeit, Änderungen an einem kleinen OpenShift Container Platform 4-Cluster mit drei Arbeitsknoten oder an einem großen Produktionscluster mit 3000 Knoten vorzunehmen. In jedem Fall ist der Arbeitsaufwand gleich - und sehr gering - konfigurieren Sie einfach die ContainerRuntimeConfig-Datei und ändern Sie eine Bezeichnung in MachineConfigPool. Dies ist mit jeder Version der OpenShift Container Platform 4.X-Plattform möglich, die Kubernetes während seines gesamten Lebenszyklus verwendet.

Oft entwickeln sich Technologieunternehmen so schnell, dass wir nicht erklären können, warum wir bestimmte Technologien für die Basiskomponenten 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 Containermotoren begann, zeigen Benutzer häufig Interesse an ihnen. Dies 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 bei der Arbeit mit OpenShift 4 bietet.