Red Hat OpenShift-Masterkomponenten

Machen Sie sich mit den folgenden Komponenten im von IBM verwalteten Master Ihres Red Hat OpenShift on IBM Cloud-Clusters vertraut.

Sie können diese Komponenten nicht ändern. IBM verwaltet die Komponenten und aktualisiert sie bei Master-Patchaktualisierungen automatisch.

In OpenShift Container Platform 4 werden viele Komponenten von einem entsprechenden Operator zwecks einer einfacheren Verwaltung konfiguriert. In der folgenden Tabelle werden diese Operatoren und Komponenten gemeinsam erläutert, um sich auf die Hauptfunktionalität zu konzentrieren, die die jeweilige Komponente dem Cluster bereitstellt.

Single-Tenant-Funktionalität

Der Master und alle Masterkomponenten sind ausschließlich für Sie dediziert und werden nicht mit anderen IBM Kunden gemeinsam genutzt.

Replikate

Masterkomponenten, einschließlich Red Hat OpenShift-API-Server und etcd-Datenspeicher, weisen drei Replikate auf und werden zur weiteren Verbesserung der Hochverfügbarkeit auf mehrere Zonen verteilt, sofern sie sich in einer Mehrzonenmetropole befinden.

cloud-controller-manager

Der Cloud-Controller-Manager verwaltet Cloud-Provider-spezifische Komponenten wie die IBM Cloud-Lastausgleichsfunktion.

cluster-health

Die Clusterzustandskomponente überwacht den Zustand des Clusters und integriert sich in die IBM Cloud-Überwachung und -Metriken für den Service.

cluster-policy-controller

Die cluster-policy-controller verwaltet die Richtlinienressourcen, die für die Erstellung von Pods innerhalb des Clusters erforderlich sind.

cluster-version-operator

Der Clusterversionsoperator (CVO) installiert und aktualisiert andere Operatoren, die in dem Cluster ausgeführt werden. Weitere Informationen finden Sie im Projekt „ GitHub “.

control-plane-operator

Der Steuerebenenoperator verwaltet die Installation und Aktualisierung von Steuerebenenkomponenten im Master.

etcd, etcd-molecule, etcd-operator

"etcd" ist ein hoch verfügbarer Schlüsselwertspeicher, in dem der Status aller Kubernetes-Ressourcen eines Clusters gespeichert ist, wie z. B. von Services, Implementierungen und Pods. Daten in "etcd" werden alle 8 Stunden in einer verschlüsselten Speicherinstanz gesichert, die von IBM verwaltet wird.

kube-controller-manager, openshift-controller-manager

Der „ Kubernetes “-Controller überwacht den Status von Objekten innerhalb des Clusters, wie beispielsweise das Replikatset einer Workload. Wenn sich der Zustand eines Objekts ändert, z. B. wenn ein Pod in einer Replikatgruppe inaktiv wird, leitet der Controller-Manager Korrekturmaßnahmen ein, um den erforderlichen Zustand zu erreichen. Der Red Hat OpenShift-Controller führt dieselbe Funktion für Objekte aus, die für die Red Hat OpenShift-API spezifisch sind, wie z. B. Projekte.

kube-scheduler

Der „ Kubernetes “-Scheduler überwacht neu erstellte Pods und entscheidet anhand von Kapazität, Leistungsanforderungen, Richtlinienbeschränkungen, Anti-Affinitäts-Spezifikationen und Workload-Anforderungen, wo diese bereitgestellt werden sollen. Wird kein Workerknoten gefunden, der mit den Anforderungen übereinstimmt, so wird der Pod nicht im Cluster bereitgestellt.

manifests-bootstrapper

Der Job „ manifests-boot-strapper “ richtet den Master mit den erforderlichen Zertifikaten ein, damit er als Master-Knoten dem Cluster beitreten kann.

oauth-openshift

Der integrierte OAuth-Server ist automatisch für die Integration mit IBM Cloud Identity and Access Management (IAM) eingerichtet. Sie können dem Cluster keine weiteren unterstützten Identitätsprovider hinzufügen. Weitere Informationen zur Vorgehensweise bei der Authentifizierung mit dem Cluster über IAM finden Sie unter Auf Red Hat OpenShift-Cluster zugreifen.

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

Der API-Server ist der Haupteinstiegspunkt für alle Cluster-Management-Anforderungen vom Workerknoten bis zum Master. Der API-Server validiert und verarbeitet Anforderungen, die den Status von Kubernetes-Objekten, z. B. Pods und Services, oder von Red Hat OpenShift-Objekten, z. B. Projekte und Benutzer, ändern. Anschließend speichert der API-Server diesen Status im etcd-Datenspeicher.

konnectivity-server, konnectivity-operator

Der Konnectivity-Server arbeitet mit dem Konnectivity-Agenten zusammen, um den Master sicher mit dem Worker-Knoten zu verbinden. Diese Verbindung unterstützt apiserver proxy-Aufrufe an Ihre Pods und Services, oc exec-, attach- und logs-Aufrufe an 'kubelet' sowie das Ändern und Validieren von Webhooks.

Zugangscontroller

Zugangscontroller werden für bestimmte Funktionen in Red Hat OpenShift on IBM Cloud-Clustern implementiert. Mit den Zugangscontrollern können Sie Richtlinien in Ihrem Cluster definieren, die festlegen, ob eine bestimmte Aktion im Cluster zulässig ist. In der Richtlinie können Sie Bedingungen angeben, unter denen ein Benutzer eine Aktion nicht ausführen kann, selbst wenn diese Aktion Teil der allgemeinen Berechtigungen ist, die Sie dem Benutzer mithilfe von RBAC zugewiesen haben. Daher können Zugangscontroller eine zusätzliche Sicherheitsebene für Ihren Cluster bereitstellen, bevor eine API-Anforderung vom Red Hat OpenShift-API-Server verarbeitet wird. Wenn Sie einen „ Red Hat OpenShift “-Cluster erstellen, werden die folgenden „ Kubernetes “-Admission-Controller automatisch in der angegebenen Reihenfolge auf dem „ Red Hat OpenShift “-Master installiert; diese Reihenfolge kann vom Benutzer nicht geändert werden:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

Sie können eigene Zulassungscontroller im Cluster installieren oder aus den optionalen Zulassungscontrollern wählen, die Red Hat OpenShift on IBM Cloud bereitstellt. Sicherheitsmaßnahmen für Container-Images: Installieren Sie Portieris, um die Bereitstellung von Containern aus nicht signierten Images zu blockieren.

Wenn Sie Zugangscontroller manuell installiert haben und diese nicht mehr verwenden wollen, müssen Sie sie vollständig entfernen. Wenn Zugangscontroller nicht vollständig entfernt werden, blockieren sie möglicherweise alle Aktionen, die Sie auf dem Cluster ausführen wollen.

Red Hat OpenShift Komponenten eines Worker-Knotens

Machen Sie sich mit den folgenden Komponenten der vom Kunden verwalteten Workerknoten des Red Hat OpenShift on IBM Cloud-Clusters vertraut.

Diese Komponenten werden auf Ihren Workerknoten ausgeführt, da Sie sie mit den Workloads verwenden können, die Sie in Ihrem Cluster bereitstellen. Ihre Apps können zum Beispiel einen Operator aus dem OperatorHub verwenden, der einen Container aus einem Image in der internen Registry ausführt. Für die Nutzung dieser Komponenten sind Sie verantwortlich. IBM stellt jedoch Updates für diese Komponenten in den Patchaktualisierungen für Workerknoten bereit, die Sie wahlweise anwenden.

In „ OpenShift Container Platform “ werden viele Komponenten zur Vereinfachung der Verwaltung durch einen entsprechenden Operator konfiguriert. In der folgenden Tabelle werden diese Operatoren und Komponenten gemeinsam erläutert, um sich auf die Hauptfunktionalität zu konzentrieren, die die jeweilige Komponente dem Cluster bereitstellt.

Single-Tenant-Funktionalität

Der Workerknoten und alle Workerknotenkomponenten sind ausschließlich für Sie dediziert und werden nicht mit anderen IBM Kunden gemeinsam genutzt. Wenn Sie jedoch virtuelle Maschinen als Worker-Knoten verwenden, wird die zugrunde liegende Hardware je nach dem von Ihnen gewählten Grad der Hardware-Isolation möglicherweise mit anderen „ IBM “-Kunden gemeinsam genutzt.

Betriebssystem

Eine Liste der unterstützten Betriebssysteme nach Clusterversion finden Sie in den Versionsinformationen.

CRI-O-Containerlaufzeit

Auf Ihren Worker-Knoten ist CRI-O als Container-Laufzeit-Schnittstelle installiert. Weitere Informationen finden Sie unter Containerlaufzeit.

Projekte

Red Hat OpenShift organisiert Ihre Ressourcen in Projekten, bei denen es sich um Kubernetes-Namensbereiche mit Annotationen handelt, und enthält mehr Komponenten als ein Community-Kubernetes-Cluster, um Red Hat OpenShift-Features wie den Katalog auszuführen. Ausgewählte Komponenten der Projekte werden in den folgenden Zeilen beschrieben. Weitere Informationen finden Sie unter Arbeiten an einem Projekt.

calico-system, tigera-operator

Calico verwaltet Netzrichtlinien für Ihren Cluster und enthält einige Komponenten zum Verwalten der Containernetzkonnektivität, der IP-Adresszuordnung und der Netzverkehrssteuerung. Der Tigera-Operator installiert und verwaltet den Lebenszyklus der Calico-Komponenten.

default

Dieses Projekt wird verwendet, wenn Sie kein Projekt angeben und kein Projekt für Ihre Kubernetes-Ressourcen erstellen.

ibm-system

Dieses Projekt enthält die ibm-cloud-provider-ip-Bereitstellung, die mit keepalived arbeitet, um Statusprüfung und Layer 4-Lastausgleich für Anforderungen an App-Pods bereitzustellen.

kube-system

Dieses Projekt enthält viele Komponenten, die für die Ausführung von Kubernetes auf dem Workerknoten verwendet werden.

• ibm-master-proxy: ibm-master-proxy ist eine Dämongruppe, die Anforderungen vom Workerknoten an die IP-Adressen der hoch verfügbaren Masterreplikate weiterleitet. In Einzelzonenclustern verfügt der Master über drei Replikate auf separaten Hosts. Für Cluster in einer mehrzonenfähigen Zone verfügt der Master über drei Replikate, die über Zonen verteilt sind. Eine hoch verfügbare Lastausgleichsfunktion leitet Anforderungen an den Masterdomänennamen an die Masterreplikate weiter.
• kubelet: Das Kubelet ist ein Workerknotenagent, der auf jedem Workerknoten ausgeführt wird und für die Überwachung des Zustands von Pods, die auf dem Workerknoten ausgeführt werden, sowie für die Überwachung der Ereignisse verantwortlich ist, die der API-Server sendet. Das "kubelet" erstellt oder entfernt auf der Basis der Ereignisse Pods, stellt Aktivitäts- und Bereitschaftsprüfungen sicher und meldet dem API-Server den Zustand der Pods.
• vpn: Der Konnectivity-Agent arbeitet mit dem Konnectivity-Server zusammen, um den Master sicher mit dem Worker-Knoten zu verbinden. Diese Verbindung unterstützt apiserver proxy-Aufrufe für Ihre Pods und Services sowie oc exec-, attach- und logs-Aufrufe für "kubelet".
• Weitere Komponenten: Das kube-system-Projekt enthält auch Komponenten zur Verwaltung der von IBM bereitgestellten Ressourcen, wie z. B. Speicher-Plug-ins für Datei- und Blockspeicher, Ingress Application Load Balancer (ALB) und keepalived.

openshift-cloud-credential-operator

Der Cloud-Berechtigungsnachweisoperator verwaltet einen Controller für Red Hat OpenShift-Komponenten, die Berechtigungsnachweise für den Cloud-Provider anfordern. Der Controller stellt sicher, dass nur die Berechtigungsnachweise verwendet werden, die für die Operation erforderlich sind, und keine erweiterten Berechtigungen wie z. B. admin. Weitere Informationen finden Sie im Projekt „ GitHub “.

openshift-cluster-node-tuning-operator

IBM verwaltet den „Node Tuning Operator“, der auf jedem Worker-Knoten im Cluster ein Daemon-Set ausführt, um die Worker-Knoten zu optimieren.

openshift-cluster-samples-operator

Der „Samples“-Operator verwaltet ausgewählte Bildströme und Vorlagen, die standardmäßig im „ Red Hat OpenShift “-Cluster enthalten sind. Sie können diese Vorlagen über die Entwickler-Perspektive in der Red Hat OpenShift-Webkonsole bereitstellen.

openshift-cluster-storage-operator

Der Clusterspeicheroperator stellt sicher, dass eine Standardspeicherklasse festgelegt ist.

openshift-console, openshift-console-operator

Die Webkonsole „ Red Hat OpenShift “ ist eine webbasierte Benutzeroberfläche, über die Sie die in Ihrem Cluster ausgeführten Ressourcen „ Red Hat OpenShift “ und „ Kubernetes “ verwalten können. Sie können die Konsole auch verwenden, um ein oc login-Token für die Authentifizierung bei Ihrem Cluster über eine Befehlszeilenschnittstelle (CLI) anzuzeigen. Weitere Informationen finden Sie unter In der Red Hat OpenShift-Konsole navigieren.

openshift-dns, openshift-dns-operator

Das DNS-Projekt enthält die Komponenten zum Validieren des eingehenden Netzverkehrs anhand der iptables-Regeln, die auf dem Workerknoten eingerichtet sind, und fungiert als Proxy für Anforderungen, die im Cluster eingehen oder abgehen können.

openshift-image-registry

Red Hat OpenShift bietet eine interne Container-Image-Registrierung, mit der Sie Images lokal über die Konsole verwalten und anzeigen können. Alternativ können Sie die private IBM Cloud Container Registry einrichten oder Images aus der IBM Cloud Container Registry in die interne Registry importieren. Die interne Registry verfügt über ein „ File Storage for Classic “-Volume in Ihrem „ IBM Cloud “-Infrastrukturkonto, in dem die Registry-Images gespeichert werden. Der Dateispeicherdatenträger wird durch den Persistent Volume Claim (PVC) image-registry-storage bereitgestellt.

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift nutzt Routen, um den Dienst einer App direkt unter einem Hostnamen bereitzustellen, sodass externe Clients auf den Dienst zugreifen können. Zum Erstellen von Routen verwendet der Cluster den Ingress-Operator. Sie können Ingress auch verwenden, um Apps extern zugänglich zu machen und das Routing anzupassen. Ingress besteht aus drei Komponenten: dem Ingress-Operator, dem Ingress-Controller und den Routenressourcen. Der Ingress-Controller ordnet den Service dem Hostnamen zu. Standardmäßig schließt der Ingress-Controller zwei Replikate ein. Stellen Sie sicher, dass Ihr Cluster über mindestens zwei Workerknoten verfügt, sodass der Ingress-Controller auf separaten Rechenhosts für eine höhere Verfügbarkeit ausgeführt werden kann.

openshift-marketplace

Der Marktplatz umfasst die OperatorHub das standardmäßig im „ Red Hat OpenShift “-Cluster enthalten ist. Der OperatorHub enthält Operatoren von Red Hat und anderen Anbietern. Beachten Sie, dass diese Operatoren von der Community bereitgestellt werden. Sie lassen sich möglicherweise nicht in Ihren Cluster integrieren und werden von IBM nicht unterstützt. Das Aktivieren der Operatoren kann über den OperatorHub in der Red Hat OpenShift-Webkonsole erfolgen.

openshift-monitoring

OpenShift Container Platform umfasst einen integrierten Überwachungsstack für Ihren Cluster, der Funktionen zur Erfassung von Metriken und zur Verwaltung von Warnmeldungen enthält. Einen Vergleich des integrierten Überwachungsstacks und anderer Optionen wie IBM Cloud Monitoring finden Sie unter Erläuterungen zu den Optionen für Protokollierung und Überwachung.

openshift-multus

OpenShift Container Platform nutzt das Multus-CNI-Plugin (Container Network Interface), um mehrere Pod-Netzwerke zu ermöglichen. Sie können den Cluster jedoch nicht für die Verwendung mehrerer Podnetze konfigurieren. Red Hat OpenShift on IBM Cloud-Cluster unterstützen nur Calico, was standardmäßig für Ihren Cluster eingerichtet ist. Wenn diese Option aktiviert ist, verwendet Service Mesh das Multus-Plug-in.

openshift-network-operator

Der Cluster-Netzwerkbetreiber(CNO) verwaltet die standardmäßig eingerichteten Komponenten des Cluster-Netzwerks, wie beispielsweise das CNI-Pod-Netzwerk-Provider-Plugin und den DNS-Operator.

openshift-operator-lifecycle-manager

Der Operator-Lifecycle-Manager(OLM) verwaltet den Lebenszyklus aller im Cluster ausgeführten Operatoren und des Katalogs, einschließlich der Operatoren für die Standardkomponenten und aller von Ihnen hinzugefügten benutzerdefinierten Operatoren.

openshift-service-ca, openshift-service-ca-operator

Der Operator der Zertifizierungsstelle (CA) führt die Zertifikatssignierung aus und fügt Zertifikate in API-Serverressourcen und Konfigurationszuordnungen im Cluster ein. Weitere Informationen finden Sie im Projekt „ GitHub “.

Cluster mit öffentlichen und privaten Cloud-Serviceendpunkten

Das folgende Diagramm zeigt die Komponenten Ihrer Cluster und veranschaulicht, wie die Komponenten miteinander interagieren, wenn Public- und Private-Cloud-Serviceendpunkte aktiviert sind. Da beide Serviceendpunkte aktiviert sind, erstellt Ihre VPC für jeden Service eine öffentliche Lastausgleichsfunktion für eingehenden Datenverkehr.

Cluster nur mit privatem Cloud-Serviceendpunkt

Das folgende Diagramm zeigt die Komponenten Ihres Clusters und veranschaulicht, wie die Komponenten miteinander interagieren, wenn nur der Private-Cloud-Serviceendpunkt aktiviert ist. Da nur der Private-Cloud-Serviceendpunkt aktiviert ist, erstellt Ihre VPC für jeden Service eine private Lastausgleichsfunktion für eingehenden Datenverkehr.

Komponenten des VPC-Master- und Worker-Knotens

Master- und Worker-Knoten enthalten dieselben Komponenten, wie sie in der klassischen Cluster-Architektur für Cluster beschrieben sind. Weitere Informationen zur Architektur OpenShift Container Platform finden Sie in der Red Hat OpenShift Dokumentation.

Master

Masterkomponenten wie der API-Server und etcd haben drei Replikate und werden für eine noch bessere Verfügbarkeit auf die Zonen verteilt. Master-Knoten umfassen dieselben Komponenten wie in der Classic-Clusterarchitektur für Cluster beschrieben. Der Master und alle Masterkomponenten sind nur Ihnen vorbehalten und werden nicht mit anderen IBM Kunden gemeinsam genutzt.

Workerknoten

In Red Hat OpenShift on IBM Cloud stellen die von Ihrem Cluster verwalteten virtuellen Maschinen Instanzen dar, die als Workerknoten bezeichnet werden. Diese virtuellen Maschinen mit Workerknoten und alle Workerknotenkomponenten sind nur Ihnen vorbehalten und werden nicht mit anderen IBM Kunden gemeinsam genutzt. Die zugrunde liegende Hardware wird jedoch mit anderen IBM Kunden gemeinsam genutzt. Sie verwalten die Workerknoten mit den Automatisierungstools von Red Hat OpenShift on IBM Cloud, z. B. mit der API, der CLI oder der Konsole. Im Gegensatz zu klassischen Clustern werden VPC-Rechenworkerknoten nicht in Ihrem Infrastrukturportal oder in einer separaten Infrastrukturrechnung angezeigt, sondern Sie verwalten alle Wartungs- und Abrechnungsaktivitäten für die Workerknoten über Red Hat OpenShift on IBM Cloud.

Worker-Knoten enthalten dieselben Komponenten wie in der klassischen Cluster-Architektur beschrieben.

Wenn Sie oc get nodes ausführen, stellen Sie möglicherweise fest, dass die Rollen (ROLES) Ihrer Workerknoten als master,worker markiert sind. Diese Knoten sind Workerknoten in IBM Cloud und enthalten keine Masterkomponenten, die von IBM verwaltet werden. Stattdessen sind diese Knoten als master markiert, da sie OpenShift Container Platform-Komponenten ausführen, die für die Einrichtung und Verwaltung von Standardressourcen innerhalb des Clusters verantwortlich sind, z. B. die OperatorHub- und die interne Registry.

Clusternetzbetrieb

Ihre Workerknoten werden in einem VPC-Teilnetz in der Zone erstellt, die Sie angeben. Die Kommunikation zwischen dem Master und Workerknoten erfolgt über das private Netz. Wenn Sie einen Cluster erstellen, bei dem Public- und Private-Cloud-Serviceendpunkte aktiviert sind, können authentifizierte externer Benutzer über das öffentliches Netz mit dem Master kommunizieren sowie oc-Befehle ausführen. Wenn Sie einen Cluster erstellen, bei dem nur die Private-Cloud-Serviceendpunkte aktiviert sind, können authentifizierte externe Benutzer nur über das private Netzwerk mit dem Master kommunizieren. Sie können Ihr Cluster für die Kommunikation mit Ressourcen in lokalen Netzen, anderen VPCs oder klassischer Infrastruktur einrichten, indem Sie im privaten Netz ein VPC-VPN, IBM Cloud Direct Link oder IBM Cloud Transit Gateway einrichten.

App-Netzbetrieb

Für alle Netzwerkdienste, die Sie in Ihrem Cluster erstellen, werden in Ihrer VPC außerhalb des Clusters automatisch Load Balancer der Virtual Private Cloud angelegt. Eine VPC-Lastausgleichsfunktion macht beispielsweise standardmäßig die Routerservices in Ihrem Cluster zugänglich. Sie können auch einen Kubernetes-LoadBalancer-Service für Ihre Apps erstellen. Eine VPC-Lastausgleichsfunktion wird automatisch generiert. VPC-Lastausgleichsfunktionen sind Mehrzonen- und Weiterleitungsanforderungen für Ihre App über die privaten Knotenports, die automatisch auf Ihren Workerknoten geöffnet werden. Wenn die Public- und Private-Cloud-Serviceendpunkte aktiviert sind, werden die Router und VPC-Lastausgleichsfunktionen standardmäßig als öffentliche Router und VPC-Lastausgleichsfunktionen erstellt. Wenn nur der Private-Cloud-Serviceendpunkt aktiviert ist, werden die Router und VPC-Lastausgleichsfunktionen standardmäßig als private Router und VPC-Lastausgleichsfunktionen erstellt. Weitere Informationen finden Sie unter Öffentlicher oder Privater App-Netzbetrieb in VPC-Clustern. Calico wird als Struktur für Clusternetzrichtlinien verwendet.

Speicher

Sie können nur IBM Cloud Object Storage und Cloud Databases einrichten.