Was ist Kubernetes?

Kubernetes ist eine Open-Source-Plattform für die Verwaltung containerisierter Workloads und Services über mehrere Hosts hinweg und bietet Verwaltungstools für die Bereitstellung, Automatisierung, Überwachung und Skalierung containerisierter Apps mit geringer bis gar keiner manuellen Intervention. Alle Container, aus denen sich Ihr Microservice zusammensetzt, werden in Pods gruppiert, einer logischen Einheit zur Sicherstellung einer einfachen Verwaltung und Erkennung. Diese Pods werden auf Datenverarbeitungshosts ausgeführt, die in einem portierbaren, erweiterbaren und im Störfall selbst-heilenden Kubernetes-Cluster verwaltet werden.

Weitere Informationen zu Kubernetesfinden Sie in der Dokumentation zuKubernetes.

Wie erstelle ich einen Red Hat OpenShift on IBM Cloud-Cluster?

Zum Erstellen eines Red Hat OpenShift on IBM Cloud-Clusters müssen Sie zuerst entscheiden, ob Sie ein Lernprogramm für eine grundlegende Clusterkonfiguration ausführen oder eine eigene Clusterumgebung entwerfen möchten.

Ich möchte einem Lernprogramm folgen

Lesen Sie zunächst das Dokument Erste Schritte und wählen Sie dann eines der verfügbaren Lernprogramme aus.

Ich möchte meine eigene Clusterumgebung entwerfen

Lesen Sie zunächst das Dokument Erste Schritte und erstellen Sie dann Ihre Clusterumgebungsstrategie.

Wie funktioniert Red Hat OpenShift on IBM Cloud?

Mit Red Hat OpenShift on IBM Cloud können Sie eigene Red Hat OpenShift-Cluster erstellen, um containerisierte Apps in IBM Cloud bereitzustellen und zu verwalten. Ihre containerisierten Apps werden auf Datenverarbeitungshosts der IBM Cloud-Infrastruktur gehostet, die als Workerknoten bezeichnet werden. Sie können Ihre Rechenhosts entweder als virtuelle Maschinen mit gemeinsam genutzten oder dedizierten Ressourcen bereitstellen oder als Bare-Metal-Maschinen, die für die Nutzung von GPUs und softwaredefiniertem Speicher (SDS) optimiert werden können. Ihre Workerknoten werden von einem hoch verfügbaren Red Hat OpenShift-Master gesteuert, der von IBM konfiguriert, überwacht und verwaltet wird. Sie können die IBM Cloud Kubernetes Service-API oder -CLI verwenden, um mit Ihren Clusterinfrastrukturressourcen zu arbeiten, und die Kubernetes-API oder -CLI, um Ihre Bereitstellungen und Services zu verwalten.

Weitere Informationen zur Konfiguration Ihrer Clusterressourcen finden Sie unter Servicearchitektur. Eine Liste mit Funktionen und Vorteilen finden Sie unter Vorteile und Serviceangebote.

Warum sollte ich Red Hat OpenShift on IBM Cloud verwenden?

Red Hat OpenShift on IBM Cloud ist ein verwaltetes Red Hat OpenShift-Angebot, das leistungsfähige Tools, eine intuitive Benutzererfahrung und integrierte Sicherheit für die schnelle Bereitstellung von Apps zur Verfügung stellt, die Sie an IBM Watson®, KI, Internet der Dinge, DevOps, Sicherheit und Datenanalyse binden können. Als zertifizierter Kubernetes-Anbieter unterstützt Red Hat OpenShift on IBM Cloud intelligente Planung, Selbstheilung, horizontale Skalierung, Service-Erkennung und Lastenausgleich, automatisierte Rollouts und Rollbacks sowie die Verwaltung von Geheimnissen und Konfigurationen. Der Service bietet außerdem erweiterte Funktionen für vereinfachtes Cluster-Management, Containersicherheit und Isolationsrichtlinien, die Möglichkeit, einen eigenen Cluster zu entwerfen, und integrierte operationale Tools für Konsistenz in der Bereitstellung.

Eine detaillierte Übersicht über die Funktionen und Vorteile finden Sie unter Vorteile durch die Verwendung des Service.

Welche Containerplattformen stehen für meinen Cluster zur Verfügung?

Mit IBM Cloud können Sie Cluster für Ihre containerisierten Workloads auf zwei verschiedenen Container-Management-Plattformen auswählen: IBM Version von Community-Kubernetes und Red Hat OpenShift on IBM Cloud. Die von Ihnen ausgewählte Containerplattform wird auf Ihrem Cluster-Master und den Workerknoten installiert. Später können Sie die Version aktualisieren, aber Sie können kein Rollback auf eine Vorgängerversion durchführen oder zu einer anderen Containerplattform wechseln. Wenn Sie mehrere Containerplattformen verwenden möchten, erstellen Sie für jede der Plattformen einen separaten Cluster.

Weitere Informationen enthält der Vergleich zwischen Red Hat OpenShift- und Community-Kubernetes-Clustern.

Kubernetes

Kubernetes ist eine produktionsreife Open-Source-Plattform zur Container-Orchestrierung, mit der Sie Ihre containerisierten Anwendungen, die auf einem Betriebssystem der Ubuntu laufen, automatisieren, skalieren und verwalten können. Mit der IBM Cloud Kubernetes Service-Version erhalten Sie Zugriff auf die Funktionen der Community-Kubernetes-API, die in der Community als Betaversion oder höher eingestuft werden. Kubernetes-Alpha-Funktionen, für die Änderungen vorbehalten sind, werden im Allgemeinen nicht standardmäßig aktiviert. Mit Kubernetes können Sie verschiedene Ressourcen (z. B. geheime Schlüssel, Bereitstellungen und Services) kombinieren, um hochverfügbare, containerisierte Apps sicher zu erstellen und zu verwalten.

Red Hat OpenShift

Red Hat OpenShift on IBM Cloud ist eine auf Kubernetes basierende Plattform, die speziell darauf ausgelegt ist, Ihre Bereitstellungsprozesse für containerisierte Anwendungen zu beschleunigen, die auf einem Red Hat Enterprise Linux-Betriebssystem laufen. Sie können vorhandene Red Hat OpenShift-Workloads über lokale und ferne Clouds hinweg orchestrieren und skalieren, um eine portierbare Hybridlösung bereitzustellen, die auch in Multi-Cloud-Szenarios auf dieselbe Weise eingesetzt werden kann. Zum Einstieg können Sie sich im Lernprogramm für Red Hat OpenShift on IBM Cloud mit dem Produkt vertraut machen.

Beinhaltet der Service einen verwalteten Red Hat OpenShift-Masterknoten sowie Workerknoten?

Jeder Cluster in Red Hat OpenShift on IBM Cloud wird von einem dedizierten Red Hat OpenShift-Master gesteuert, der von IBM in einem IBM Cloud-Infrastrukturkonto verwaltet wird, dessen Eigner IBM ist. Der Red Hat OpenShift-Master, einschließlich aller Masterkomponenten, Rechen- und Netzbetriebs- und Speicherressourcen wird von IBM Site Reliability Engineers (SREs) kontinuierlich überwacht. Von SREs werden die neuesten Sicherheitsstandards angewendet, böswillige Aktivitäten ermittelt und korrigiert und somit die Zuverlässigkeit und Verfügbarkeit von Red Hat OpenShift on IBM Cloud sichergestellt.

Red Hat OpenShift gibt regelmäßig Hauptversionen, Nebenversionen oder Patches als Aktualisierungen heraus. Diese Aktualisierungen können die API-Serverversion von Red Hat OpenShift oder andere Komponenten in Ihrem Red Hat OpenShift-Master betreffen. IBM aktualisiert die Patchversionen automatisch, aber Sie müssen die Haupt- und Nebenversionen des Masters aktualisieren. Weitere Informationen finden Sie unter Master aktualisieren.

Workerknoten in Standardclustern werden in Ihrem Konto der IBM Cloud-Infrastruktur bereitgestellt. Die Workerknoten sind Ihrem Konto zugeordnet und es liegt in Ihrer Verantwortung, zeitnahe Aktualisierungen für die Workerknoten anzufordern, um sicherzustellen, dass das Betriebssystem der Workerknoten und die Red Hat OpenShift on IBM Cloud-Komponenten die neuesten Sicherheitsupdates und Patches anwenden. Sicherheitspatches und -aktualisierungen von Sicherheitsinformationen werden von IBM Site Reliability Engineers (SREs) zur Verfügung gestellt, die das Linux-Image kontinuierlich überwachen, das auf Ihren Workerknoten installiert ist, um Sicherheitslücken und Probleme bei der Einhaltung von Sicherheitsbestimmungen zu ermitteln. Weitere Informationen finden Sie unter Workerknoten aktualisieren.

Welche Arten von Workloads kann ich nach Red Hat OpenShift on IBM Cloudverschieben?

Beispiele für die Arten von Workloads, die Benutzer typischerweise in die verschiedenen Cloud-Typen verlagern, finden Sie unter „ Verlagern Ihrer Workloads in die IBM Cloud “. Sie können auch einen Hybrid-Ansatz wählen, bei dem die Cluster in beiden Umgebungen ausgeführt werden.

Kann ich meine Infrastrukturbereitstellungen automatisieren?

Wenn Sie Ihre App in mehreren Clustern, öffentlichen und privaten Umgebungen oder sogar mit mehreren Cloud-Providern ausführen möchten, fragen Sie sich vielleicht, wie Sie in solchen Umgebungen Ihre Bereitstellungsstrategie gestalten können.

Sie können das Open-Source-Tool Terraform verwenden, um die Bereitstellung der IBM Cloud-Infrastruktur, einschließlich Kubernetes-Clustern, zu automatisieren. Folgen Sie diesem Lernprogramm, um Kubernetes-und OpenShift-Cluster mit einer oder mehreren Zonen zu erstellen. Nachdem Sie einen Cluster erstellt haben, können Sie auch den Red Hat OpenShift on IBM Cloud-Cluster-Autoscaler so konfigurieren, dass für Ihren Workerpool in Abhängigkeit von den Ressourcenanforderungen Ihrer Workload ein Scale-up oder Scale-down durchgeführt wird.

Welche Art von Apps kann ich ausführen? Kann ich vorhandene Apps weiter verwenden oder muss ich neue Apps entwickeln?

Ihre containerisierte App muss unter einem der unterstützten Betriebssysteme für Ihre Clusterversion ausgeführt werden können. Sie sollten auch den Status Ihrer App berücksichtigen. Weitere Informationen zu den Arten von Apps, die unter Red Hat OpenShift on IBM Cloud ausgeführt werden können, finden Sie unter App-Bereitstellungen planen.

Wenn Sie bereits über eine App verfügen, können Sie diese App auf Red Hat OpenShift on IBM Cloud migrieren. Wenn Sie eine neue App entwickeln möchten, lesen Sie die Informationen unter Richtlinien für die Entwicklung statusunabhängiger, cloudnativer Apps.

Was ist mit serverunabhängigen Apps?

Sie können serverunabhängige Apps und Jobs über den IBM Cloud Code Engine-Service ausführen. Code Engine kann Ihre Images auch für Sie erstellen.

Über welche Kenntnisse muss ich verfügen, bevor ich meine Apps in einen Cluster verschiebe?

Red Hat OpenShift ist für die Bereitstellung von Funktionen für zwei Hauptpersonengruppen konzipiert. Dies sind Clusteradministratoren und Anwendungsentwickler. Jeder, der eine dieser Rollen ausübt, setzt andere technische Kenntnisse ein, um Apps in einem Cluster erfolgreich bereitzustellen und auszuführen.

Was sind die Hauptaufgaben und welche technischen Kenntnisse benötigt ein Cluster-Administrator?

Als Clusteradministrator sind Sie dafür verantwortlich, die IBM Cloud-Infrastruktur Ihres Clusters einzurichten, zu betreiben, zu schützen und zu verwalten. Zu den typischen Tasks gehören folgende:

• Clustergröße anpassen, um genügend Kapazität für Ihre Workloads bereitzustellen.
• Einen Cluster entwerfen, der die Hochverfügbarkeits-, Disaster-Recovery- und Compliance-Standards Ihres Unternehmens erfüllt.
• Den Cluster durch Konfigurieren von Benutzerberechtigungen und Begrenzen von Aktionen innerhalb des Clusters zum Schutz der Datenverarbeitungsressourcen, Ihres Netzes und der Daten sichern.
• Netzkommunikation zwischen Infrastrukturkomponenten planen und verwalten, um Netzsicherheit, -segmentierung und -compliance sicherzustellen.
• Optionen für persistenten Speicher planen, um Anforderungen hinsichtlich der Datenspeicherorte und des Datenschutzes zu erfüllen.

Ein Clusteradministrator muss zur Ausübung seiner Rolle hinsichtlich Verarbeitung, Netz, Speicher, Sicherheit und Compliance über ein umfangreiches Wissen verfügen. In einem Standardunternehmen ist dieses Wissen auf mehrere Spezialisten verteilt, wie zum Beispiel Systemingenieure, Systemadministratoren, Netzingenieure, Netzarchitekten, Netzarchitekten, IT-Manager oder Sicherheits- und Compliance-Spezialisten. Ziehen Sie die Zuordnung der Clusteradministratorrolle zu mehreren Personen in Ihrem Unternehmen in Betracht, sodass Sie über die für den erfolgreichen Betrieb des Clusters erforderlichen Kenntnisse verfügen.

Was sind die Hauptaufgaben und technischen Fähigkeiten eines App-Entwicklers?

Als Entwickler sind Sie für das Entwerfen, Erstellen, Sichern, Bereitstellen, Testen, Ausführen und Überwachen cloudnativer, containerisierter Apps in einem Red Hat OpenShift-Cluster zuständig. Um diese Apps zu erstellen und auszuführen, müssen Sie mit dem Konzept der Microservices, den 12-Faktor-App-Richtlinien, den Prinzipien von Docker und der Containerisierung sowie den verfügbaren Bereitstellungsoptionen für Red Hat OpenShift vertraut sein.

Red Hat OpenShift und Red Hat OpenShift on IBM Cloud bieten mehrere Optionen zum Bereitstellen einer App und Definieren einer App als privat, zum Hinzufügen von persistentem Speicher, zum Integrieren anderer Services und zum Schützen Ihrer Workloads und der sensiblen Daten. Bevor Sie Ihre App auf einen Cluster in Red Hat OpenShift on IBM Cloud verlagern, stellen Sie sicher, dass Sie Ihre App als containerisierte App auf dem unterstützten Betriebssystem ausführen können und dass Red Hat OpenShift und Red Hat OpenShift on IBM Cloud die Funktionen bereitstellen, die Ihre Workload benötigt.

Arbeiten Cluster-Administratoren und Entwickler zusammen?

Ja. Clusteradministratoren und Entwickler müssen regelmäßig miteinander interagieren, damit Clusteradministratoren verstehen, welche Workloadanforderungen für die Bereitstellung einer bestimmten Funktionalität im Cluster gelten, und damit Entwickler über bestehende Einschränkungen, Integrationen und Sicherheitsprinzipien informiert sind, die sie beim Entwickeln der App berücksichtigen müssen.

Welche Möglichkeiten habe ich, meinen Cluster zu sichern?

Sie können integrierte Sicherheitsfeatures in Red Hat OpenShift on IBM Cloud verwenden, um die Komponenten in Ihrem Cluster, Ihre Daten und App-Bereitstellungen zu schützen und so die Einhaltung von Sicherheitsbestimmungen und die Datenintegrität zu gewährleisten. Verwenden Sie diese Features, um Ihren Red Hat OpenShift-API-Server, den etcd-Datenspeicher, Workerknoten, das Netz, den Speicher, die Images und die Bereitstellungen vor böswilligen Angriffen zu schützen. Sie können auch integrierte Protokollierungs- und Überwachungstools nutzen, um böswillige Angriffe und verdächtige Verwendungsmuster zu erkennen.

Weitere Informationen zu den Komponenten Ihres Clusters und dazu, wie Sie Sicherheitsstandards für die einzelnen Komponenten einhalten können, finden Sie unter Sicherheit für Red Hat OpenShift on IBM Cloud.

Welche Zugriffsrichtlinien erteile ich meinen Clusterbenutzern?

Red Hat OpenShift on IBM Cloud verwendet Cloud Identity and Access Management (IAM), um Zugriff auf Clusterressourcen über Zugriffsrollen der IAM-Plattform und Kubernetes-RBAC-Richtlinien (RBAC = Role-Based Acces Control) über IAM-Servicezugriffsrollen zu erteilen. Weitere Informationen zu den verschiedenen Arten von Zugriffsrichtlinien finden Sie unter Wählen Sie die richtige Zugriffsrichtlinie und Rolle für Ihre Benutzer aus.

Wie rotiere ich den Cluster-API-Schlüssel, wenn es ein Leck gibt?

Anleitungen zur Erneuerung Ihres API-Schlüssels finden Sie unter Wie kann ich den Cluster-API-Schlüssel erneuern, wenn es ein Leck gibt?

Wo finde ich eine Liste der Sicherheitsbulletins, die meinen Cluster betreffen?

Wenn Sicherheitslücken in Red Hat OpenShift gefunden werden, gibt Red Hat OpenShift CVEs in Sicherheitsbulletins frei, um Benutzer zu informieren und die Aktionen zu beschreiben, die Benutzer ausführen müssen, um die Sicherheitslücken zu beheben. Red Hat OpenShift-Sicherheitsbulletins, die Red Hat OpenShift on IBM Cloud-Benutzer oder die IBM Cloud-Plattform betreffen, werden im IBM Cloud-Sicherheitsbulletin veröffentlicht.

Einige CVEs erfordern die neueste Patchaktualisierung für eine Version, die Sie als Teil des regulären Clusteraktualisierungsprozesses in Red Hat OpenShift on IBM Cloud installieren können. Stellen Sie sicher, dass Sie Sicherheitspatches zeitgerecht anwenden, um Ihren Cluster gegen böswillige Angriffe zu schützen. Weitere Informationen zum Inhalt eines Sicherheitspatches finden Sie im Versionsänderungsprotokoll.

Bietet der Service Unterstützung für Bare-Metal und GPU?

Bestimmte VPC-Workerknotentypen bieten GPU-Unterstützung. Weitere Informationen finden Sie unter VPC-Versionen.

Ja, Sie können Ihre Workerknoten als physischen Single-Tenant-Server bereitstellen, der auch als Bare-Metal-Server bezeichnet wird. Bare-Metal-Server bieten den Vorteil hoher Leistung für Workloads wie beispielsweise für Daten, GPUs (Graphics Processing Unit) und künstliche Intelligenz (Artificial Intelligence, AI). Außerdem sind alle Hardwareressourcen für Ihre Workloads dediziert, sodass Sie sich keine Sorgen um Leistungsbeeinträchtigungen machen brauchen, weil Sie Ressourcen mit anderen teilen.

Weitere Informationen zu den verfügbaren Bare-Metal-Varianten und den Unterschieden zwischen Bare-Metal-Systemen und virtuellen Maschinen finden Sie in den Planungshinweisen.

Was ist die kleinste Clustergröße, die ich erstellen kann?

Beachten Sie, dass der Betrieb eines Minimal-Clusters nicht dem Service Level Agreement (SLA) entspricht, um Support zu erhalten. Beachten Sie auch, dass einige Services, wie z. B. Ingress, hoch verfügbare Workerknotenkonfigurationen erfordern. Möglicherweise können Sie diese Services oder Ihre Apps nicht in Clustern mit nur zwei Knoten in einem Worker-Pool ausführen. Weitere Informationen finden Sie unter Cluster für Hochverfügbarkeit planen.

Klassische Cluster oder VPC-Cluster

Cluster müssen immer mindestens zwei Workerknoten haben. Beachten Sie, dass ein Cluster nicht aus 0 Worker-Knoten bestehen kann und dass Sie die Abrechnung für Ihre Worker-Knoten weder deaktivieren noch aussetzen können.

Satellite-Cluster

Cluster können mit der Einzelreplikattopologie erstellt werden, d. h. nur 1 Workerknoten. Beachten Sie, dass Sie Workerknoten später nicht hinzufügen können, wenn Sie einen Satellite-Cluster mit einer Einzelreplikattopologie erstellen.

Welche Versionen werden von dem Dienst unterstützt?

Red Hat OpenShift on IBM Cloud unterstützt gleichzeitig mehrere Versionen von Red Hat OpenShift. Wenn eine neue Version (n) veröffentlicht wird, werden die bis zu zwei älteren Versionen ( n-2 ) unterstützt. Versionen, die mehr als zwei Versionen älter sind, als die aktuellsten Version (n-3) werden zuerst nicht mehr verwendet und dann nicht weiter unterstützt.

Weitere Informationen zu den unterstützten Versionen und den erforderlichen Aktualisierungsschritten für den Wechsel von einer Version zur anderen finden Sie in den Versionsinformationen zu Red Hat OpenShift on IBM Cloud.

Welche Betriebssysteme für Workerknoten unterstützt der Service?

Eine Liste der unterstützten Workerknotensysteme nach Clusterversion finden Sie in den Informationen zur Version vonRed Hat OpenShift on IBM Cloud.

Wo ist der Service verfügbar?

Red Hat OpenShift on IBM Cloud ist weltweit verfügbar. Sie können Cluster in jeder unterstützten Red Hat OpenShift on IBM Cloud-Region erstellen.

Weitere Informationen zu unterstützten Regionen finden Sie unter Standorte.

Ist der Service hoch verfügbar?

Ja. Standardmäßig werden in Red Hat OpenShift on IBM Cloud zahlreiche Komponenten eingerichtet (z. B. der Cluster-Master mit Replikaten, die Anti-Affinität und weitere Optionen), um die Hochverfügbarkeit (High Availability, HA) des Service zu optimieren. Sie können die Redundanz und Fehlertoleranz Ihrer Cluster-Workerknoten, -speicher, -netze und -Workloads verbessern, indem Sie sie in einer hoch verfügbaren Architektur konfigurieren. Einen Überblick über das Standard-Setup und Ihre Optionen zur Verbesserung von HA finden Sie unter Erstellung einer hochverfügbaren Cluster-Strategie.

Informationen zu den Bedingungen des aktuellen HA-Service-Level-Agreements finden Sie in den IBM Cloud-Servicebedingungen. Im Allgemeinen erfordern die SLA-Verfügbarkeitsbedingungen, dass Ihre Infrastrukturressourcen beim Konfigurieren in einer HA-Architektur gleichmäßig auf drei verschiedene Verfügbarkeitszonen verteilt werden müssen. Um beispielsweise eine vollständige HA-Abdeckung gemäß den SLA-Bedingungen zu erhalten, müssen Sie einen Cluster mit mehreren Zonen mit insgesamt mindestens 6 Workerknoten einrichten, zwei Workerknoten pro Zone, die gleichmäßig auf drei Zonen verteilt sind.

Wie funktionieren Multizonen-Cluster?

Was muss ich tun, wenn ich mehrere Cluster regionenübergreifend einrichten möchte?

Sie können mehrere Cluster in verschiedenen Regionen eines geografischen Standortes (wie 'Vereinigte Staaten (Süden)' und 'Vereinigte Staaten (Osten)') oder über geografische Standorte hinweg ('Vereinigte Staaten (Süden)' und 'Mitteleuropa') einrichten. Beide Setups bieten das gleiche Maß an Verfügbarkeit für Ihre App, sind aber bei der gemeinsamen Nutzung von Daten und der Datenreplikation komplexer als andere Lösungen. In den meisten Fällen reicht es aus, am selben geografischen Standort zu bleiben. Wenn Sie aber Benutzer auf der ganzen Welt haben, ist es vielleicht besser, einen Cluster dort einzurichten, wo sich Ihre Benutzer aufhalten, sodass Ihre Benutzer keine langen Wartezeiten in Kauf nehmen müssen, wenn sie eine Anfrage an Ihre App senden.

Welche Möglichkeiten habe ich, um Workloads über mehrere Cluster hinweg auszugleichen?

Um eine gleichmäßige Lastverteilung Ihrer Workloads über mehrere Cluster hinweg zu erzielen, müssen Sie Ihre Apps über Ingress, Router oder Netzlastausgleichsfunktionen im öffentlichen Netz zugänglich machen. Den Router-Services und NLBs wird eine öffentliche IP-Adresse zugewiesen, mit der Sie auf Ihre Apps zugreifen können.

Um eine gleichmäßige Lastverteilung Ihrer Workloads über Ihre Apps hinweg zu erzielen, fügen Sie die öffentlichen IP-Adressen Ihrer Router-Services und NLBs zu einer globale CIS-Lastausgleichsfunktion oder zu Ihrer eigenen globalen Lastausgleichsfunktion hinzu.

Was muss ich tun, wenn ich Workloads im privaten Netzwerk ausgleichen möchte?

IBM Cloud bietet keinen globalen Lastausgleichsservice im privaten Netz an. Sie können Ihren Cluster jedoch unter Verwendung einer der unterstützten VPN-Optionen mit einer privaten Lastausgleichsfunktion verbinden, die Sie in Ihrem lokalen (On-Premises-) Netz per Hosting bereitstellen. Sie müssen Ihre Apps mithilfe von Ingress, Routern oder Netzlastausgleichsfunktionen im privaten Netz zugänglich machen und die IP-Adresse in Ihren VPN-Einstellungen verwenden, um Ihre App mit dem lokalen Netz zu verbinden.

Sind die Masterknoten und Workerknoten hoch verfügbar?

Die Red Hat OpenShift on IBM Cloud-Architektur und -Infrastruktur wurde konzipiert, um eine hohe Zuverlässigkeit, eine geringe Latenzzeit bei der Verarbeitung und eine maximale Betriebszeit des Service zu gewährleisten. Standardmäßig wird jeder Cluster in Red Hat OpenShift on IBM Cloud mit mehreren Red Hat OpenShift-Masterinstanzen konfiguriert, um die Verfügbarkeit und den Zugriff auf die Clusterressourcen zu gewährleistens, selbst wenn einzelne oder mehrere Instanzen Ihres Red Hat OpenShift-Masters nicht verfügbar sind.

Sie können die Hochverfügbarkeit Ihres Clusters weiter steigern und Ihre App vor Ausfallzeiten schützen, indem Sie Ihre Workloads über mehrere Workerknoten in mehreren Zonen einer Region verteilen. Diese Konfiguration wird als Multizonen-Cluster bezeichnet und stellt sicher, dass Ihre App auch dann erreichbar ist, wenn ein Worker-Knoten oder eine gesamte Zone nicht verfügbar ist.

Um sich gegen einen Ausfall einer gesamten Region abzusichern, erstellen Sie mehrere Cluster und verteilen Sie diese auf verschiedene Regionen v IBM Cloud. Indem Sie eine Netzlastausgleichsfunktion (NLB) für Ihre Cluster konfigurieren, können Sie einen regionsübergreifenden Lastausgleich und Netzbetrieb für Ihre Cluster erzielen.

Wenn Sie Daten haben, die auch bei einem Ausfall verfügbar sein müssen, müssen Sie sicherstellen, dass Ihre Daten in einem persistenten Speicher gesichert sind.

Weitere Informationen dazu, wie Sie die Hochverfügbarkeit für Ihren Cluster erzielen, finden Sie unter Hochverfügbarkeit für Red Hat OpenShift on IBM Cloud.

Werden meine Apps automatisch über verschiedene Zonen verteilt?

Es hängt davon ab, wie Sie die App einrichten. Weitere Informationen finden Sie unter Bereitstellungen mit Hochverfügbarkeit planen und Persistenten Hochverfügbarkeitsspeicher planen.

Sind die Worker-Knoten verschlüsselt?

Die sekundäre Platte des Workerknotens ist verschlüsselt. Weitere Informationen finden Sie unter Übersicht über die Clusterverschlüsselung. Nach dem Erstellen eines Worker-Pools bemerken Sie möglicherweise, dass im Namen des Workerknotentyps .encrypted vorhanden ist, wie z. B. b3c.4x16.encrypted.

Welche Konformitätsstandards erfüllt der Service?

Bei der Erstellung von IBM Cloud werden eine Vielzahl von Daten-, Finanz-, Gesundheits-, Versicherungs-, Datenschutz-, Sicherheits- und Technologiestandards sowie weitere internationale Compliance-Standards eingehalten. Weitere Informationen finden Sie unter Compliance von IBM Cloud.

Um detaillierte Systemanforderungen anzuzeigen, können Sie einen Kompatibilitätsbericht für Red Hat OpenShift on IBM Cloud erstellen. Beachten Sie, dass die Konformität vom zugrunde liegenden Infrastrukturanbieter für die Cluster-Workerknoten und die Netz- und Speicherressourcen abhängt.

Klassische Infrastruktur: Red Hat OpenShift on IBM Cloud setzt Kontrollmaßnahmen um, die den folgenden Sicherheitsstandards entsprechen:

• EU-US Privacy Shield und Swiss-US Privacy Shield Framework
• Health Insurance Portability and Accountability Act (HIPAA)
• Service Organization Control Standards (SOC 1 Typ 2, SOC 2 Typ 2)
• International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
• International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)
• Payment Card Industry Data Security Standard (PCI DSS)

VPC-Infrastruktur: Red Hat OpenShift on IBM Cloud setzt Kontrollmaßnahmen um, die den folgenden Sicherheitsstandards entsprechen:

• EU-US Privacy Shield und Swiss-US Privacy Shield Framework
• Health Insurance Portability and Accountability Act (HIPAA)
• International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization

Satellite: Siehe die Dokumentation zu IBM Cloud Satellite.

Kann ich andere IBM Cloud-Services mit meinem Cluster verwenden?

Sie können IBM Cloud-Plattform- und -Infrastrukturservices sowie Services von Drittanbietern zu Ihrem Red Hat OpenShift on IBM Cloud-Cluster hinzufügen, um die Automatisierung zu aktivieren, die Sicherheit zu verbessern oder Ihre Überwachungs- und Protokollierungsfunktionen im Cluster zu erweitern.

Eine Liste der unterstützten Services finden Sie unter Services integrieren.

Wie installiere ich einen Cloud Pak in meinem Cluster?

Cloud Paks sind im IBM Cloud-Katalog integriert, so dass Sie alle Cloud Pak-Komponenten in einem vorhandenen oder neuen Red Hat OpenShift-Cluster schnell konfigurieren und installieren können. Wenn Sie die Cloud Pak installieren, wird die Cloud Pak mit Schematics bereitgestellt und ein Schematics-Arbeitsbereich für Sie erstellt. In dem Arbeitsbereich können Sie später auf Informationen zu Ihrer Cloud Pak-Installation zugreifen. Für den Zugriff auf Ihre Cloud Pak-Services verwenden Sie die Cloud Pak-URL. Weitere Informationen finden Sie in der Cloud Pak.

Kann die mit dem Cloud Pak für den Cluster gelieferte Red Hat OpenShift-Berechtigung verwendet werden?

Ja, falls Ihr Cloud Pak eine Berechtigung für die Ausführung bestimmter Workerknotentypen beinhaltet, die mit OpenShift Container Platform installiert werden. Um Ihre Berechtigungen einzusehen, besuchen Sie IBM Passport Advantage. Beachten Sie, dass Ihre IBM Cloud-ID mit Ihrer IBM Passport Advantage-ID übereinstimmen muss.

Sie können den Cluster oder den Worker-Pool innerhalb eines bestehenden Clusters mit der Berechtigung Cloud Pak in der Konsole oder mithilfe der Option --entitlement ocp_entitled in den ibmcloud oc worker-pool create classic CLI-Befehlen ibmcloud oc cluster create classic oder erstellen. Achten Sie darauf, die richtige Anzahl und den korrekten Typ der Workerknoten anzugeben, zu deren Verwendung Sie berechtigt sind.

Überschreiten Sie Ihre Berechtigung nicht. Beachten Sie, dass Ihre OpenShift Container Platform-Berechtigungen zusammen mit anderen Cloud-Providern oder in anderen Umgebungen verwendet werden können. Um spätere Abrechnungsprobleme zu vermeiden, achten Sie darauf, nur das zu verwenden, wofür Sie berechtigt sind. Beispiel: Sie haben eine Berechtigung für die OCP-Lizenzen für zwei Workerknoten von 4 CPU und 16 GB Speicher und Sie erstellen diesen Worker-Pool mit zwei Workerknoten von 4 CPU und 16 GB Speicher. Sie haben Ihre gesamte Berechtigung verwendet und Sie können nicht dieselbe Berechtigung für andere Workerpools, Cloud-Provider oder Umgebungen verwenden.

Kann ich mehrere Cloud Paks in demselben Cluster mit Red Hat OpenShift on IBM Cloud installieren?

Ja, aber Sie müssen möglicherweise weitere Workerknoten hinzufügen, damit jedes Cloud Pak über genügend Rechenressourcen für die Ausführung verfügt. Darüber hinaus können Sie nur eine Instanz desselben Cloud Pak pro Cluster installieren, z. B. Cloud Pak for Data, oder mehrere Instanzen in verschiedenen Projekten in demselben Cluster, z. B. Cloud Pak for Automation. Informationen zur Dimensionierung finden Sie in der Dokumentation zuCloud Pak.

Was enthält ein Cloud Pak?

Cloud Paks sind in einem Paket gebündelte containerisierte Lizenzsoftwarekomponenten, deren Zusammenarbeit für Unternehmensanwendungsfälle optimiert ist, wozu beispielsweise konsistente Bereitstellung, Zugriffssteuerung und Abrechnung gehören. Sie können Teile der Cloud Paks flexibel nach Bedarf nutzen, indem Sie die richtige Kombination aus virtuellen Prozessorkernen der Software wählen, die zu Ihren Workloads passt. Sie können die Kombination der virtuellen Prozessorkerne auch der Entwicklung Ihrer Workloads entsprechend ändern.

Ja nach Cloud Pak erhalten Sie IBM Lizenzsoftware und Open-Source-Software in einem einheitlichen Managementpaket mit Protokollierungs-, Überwachungs-, Sicherheits- und Zugriffssteuerungsfunktionen.

• IBM Produkte: Cloud Paks erweitern lizenzierte IBM-Software und Middleware aus dem IBM Marketplace und integrieren diese Produkte in Ihren Cluster, um Hybrid-Cloud-Workloads zu modernisieren, zu optimieren und auszuführen.
• Open-Source-Software: Cloud Paks können auch Open-Source-Komponenten für cloudnative und portierbare Hybrid Cloud-Lösungen enthalten. Open-Source-Software wird in der Regel nicht verwaltet. Daher sind Sie selbst dafür verantwortlich, dass Ihre Komponenten aktuell und sicher bleiben. Bei Cloud Paks erhalten Sie allerdings Unterstützung bei der konsistenten Verwaltung des gesamten Lebenszyklus der Cloud Pak-Komponenten und der mit ihnen ausgeführten Workloads. Da die Open-Source-Software im Paket mit der Cloud Pak bereitgestellt wird, profitieren Sie von den Vorteilen des IBM-Supports und der Integration mit ausgewählten Funktionen der IBM Cloud, wie beispielsweise Zugriffskontrolle und Abrechnung.

Informationen zu den Komponenten der einzelnen Cloud Pak finden Sie in der Dokumentation Cloud Pak.

Was muss ich noch wissen, wenn ich Cloud Paks verwenden will?

Beim Einrichten Ihres Cloud Paks müssen Sie unter Umständen mit Red Hat OpenShift-spezifischen Ressourcen arbeiten, z. B. mit Sicherheitskontexteinschränkungen. Stellen Sie sicher, dass Sie die oc-Befehlszeilenschnittstelle oder die Befehlszeilenschnittstelle von kubectl Version 1.12 für die Interaktion mit diesen Ressourcen verwenden (Beispiel: oc get scc). Die CLI-Version 1.11 von kubectl weist einen Fehler auf, der bei Befehlen für Red Hat OpenShift-spezifische Ressourcen, z. B. kubectl get scc, zu einem Fehler führt.

Unterstützt IBM Tools von anderen Anbietern und Open-Source-Tools, die ich mit meinem Cluster verwendet?

Siehe die Richtlinie zu Open-Source-Software und Drittanbieter-Software von IBM.

Welche Gebühren werden berechnet? Kann ich die für meinen Cluster anfallenden Kosten kalkulieren und steuern?

Weitere Informationen finden Sie unter Informationen zu den Kosten für Ihre Cluster.

Kann ich für meinen Cluster ein Downgrade auf eine Vorgängerversion durchführen?

Nein, Sie können für Ihren Cluster kein Downgrade auf eine frühere Version durchführen.

Kann ich meinen aktuellen Cluster auf ein anderes Konto verschieben?

Nein, Sie können den Cluster nicht in ein anderes Konto verschieben als das, in dem er erstellt wurde.

Wie sorge ich dafür, dass mein Cluster unterstützt bleibt?

• Stellen Sie sicher, dass Ihr Cluster immer eine unterstützte Red Hat OpenShift-Version ausführt.
• Wenn eine neue Nebenversion von Red Hat OpenShift freigegeben wird, gilt eine ältere Version kurze Zeit später als veraltet und wird nicht weiter unterstützt.

Weitere Informationen hierzu finden Sie unter Master aktualisieren und Workerknoten.

Welche Operationen werden blockiert, wenn mein Cluster ein nicht unterstütztes Betriebssystem ausführt?

Die folgenden Operationen werden blockiert, wenn ein Betriebssystem nicht unterstützt wird:

• Worker erneut laden
• Worker ohne Aktualisierung ersetzen
• Worker durch Aktualisierung ersetzen
• Workeraktualisierung
• Worker-Pool erstellen (mit einem nicht unterstützten Betriebssystem)
• Neuausgleich des Worker-Pools
• Größe des Worker-Pools ändern (Scale-up)
• Worker-Pool-Zone hinzufügen
• Größe der Instanzgruppe ändern (Patch)
• Autoscaler remove worker (v2/autoscalerRemoveWorker)

Wie viel kosten die vertraulichen Container?

IBM erhebt keine zusätzlichen Gebühren für vertrauliche Behälter. Die Kosten für Service und Standard-VSI-Gebühren für jede vertrauliche Kapsel, die als VSI zum Standardtarif IBM Cloud startet, bleiben gleich.

Kann ich mein eigenes CVM (podvm) für vertrauliche Container bauen?

Ja. Die ConfigMap kann so konfiguriert werden, dass sie auf eine von Ihnen konfigurierte Confidential Virtual Machine (CVM) verweist. IBM bietet keine Unterstützung für den Aufbau eigener Systeme. Wenn Sie selbst ein Image erstellen, können Probleme auftreten, bei denen der IBM Support nicht helfen kann.

Was sollte ich als Treuhänder für vertrauliche Container verwenden?

Für die Entwicklung ist es ausreichend, einen einfachen Treuhänder in Docker / Podman auf VM laufen zu lassen. Diese Container können auch direkt in OpenShift konfiguriert werden. Da der Treuhänder jedoch für die Sicherheit der Umgebung verantwortlich ist, sollten Sie keinen Treuhänder innerhalb des OpenShift Clusters verwenden, der nicht vertrauenswürdig sein soll.

Verwenden Sie für die Produktion die Intel Trust Authority und konfigurieren Sie INITDATA für die Verwendung der Intel Trust Authority. Sie müssen Ihrem Cluster erlauben, mit Intel zu kommunizieren, z. B. Sicherheitsgruppen, sichere Standardberechtigungen OpenShift usw.

Wo erhalte ich Unterstützung für vertrauliche Container?

OpenShift Sandboxed Containers Operator auf Red Hat OpenShift on IBM Cloud wird sowohl von Red Hat als auch von IBM unterstützt. Nutzen Sie die Standard-Supportkanäle für beide Dienste. Wenn Ihr OpenShift über IBM Cloud lizenziert ist, wenden Sie sich an IBM. Wenn Sie Ihre eigenen OpenShift Lizenzen von Red Hat mitbringen, können Sie sich an Red Hat wenden.

Wie viele Peer-Pods kann ich pro Arbeitsknoten ausführen?

Die Anzahl der Peer-Pods, die Sie pro Arbeitsknoten ausführen können, wird durch mehrere Grenzwerte gesteuert:

1. PEERPODS_LIMIT_PER_NODE einstellung: Dieser konfigurierbare Grenzwert auf peer-pods-cm ConfigMap steuert die maximale Anzahl von Peer-Pod-VSI, die pro Arbeitsknoten geplant werden können. Der Standardwert ist 10. Sie können diesen Wert erhöhen, müssen aber auch die anderen unten aufgeführten Einschränkungen berücksichtigen.

2. Kubernetes pod-Limit: Kubernetes begrenzt die Gesamtzahl der Pods pro Knoten auf der Grundlage der Anzahl von vCPUs (10 Pods pro vCPU ). Zum Beispiel kann ein 16x64 Arbeitsknoten bis zu 110 Pods unterstützen. Da jeder Peer-Pod von einem Kubernetes Pod-Konstrukt auf dem Arbeitsknoten unterstützt wird, gilt diese Grenze auch dann, wenn der eigentliche Workload in einem separaten VSI läuft.

3. CPU und Arbeitsspeicher des Arbeitsknotens: Jeder Peer-Pod verbraucht etwa 250m CPU und 120Mi Speicher auf dem Arbeitsknoten für die Kubernetes Pod-Konstruktion. Sie müssen sicherstellen, dass Ihre Worker-Knoten über ausreichend CPU und Speicher verfügen, um die gewünschte Anzahl von Peer-Pods zu unterstützen.

Um den Wert PEERPODS_LIMIT_PER_NODE zu erhöhen:

1. Aktualisieren Sie die peer-pods-cm ConfigMap im Namensraum openshift-sandboxed-containers-operator. Weitere Informationen finden Sie unter Erstellen vertraulicher Container.

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'
   

2. Starten Sie den Cloud-API-Adapter-Dämonensatz neu.

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. Überprüfen Sie, ob der neue Grenzwert angewendet wird.

   oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
   

Bei der Berechnung des optimalen PEERPODS_LIMIT_PER_NODE Wertes sollten Sie das Profil Ihres Arbeitsknotens berücksichtigen. Bei einem Arbeiterknoten 16x64 (16 vCPUs ) beispielsweise würde das theoretische Maximum allein auf der Basis der CPU etwa 24 Peer-Pods pro Knoten betragen (unter der Annahme 250m CPU pro Peer-Pod und unter Berücksichtigung anderer Systemprozesse). Sie sind jedoch auch durch das Kubernetes Pod-Limit von 110 Pods pro Knoten eingeschränkt.

Was bedeutet der Fehler Unzureichend kata.peerpods.io/vm?

Wenn Sie bei der Planung von Peer-Pods eine Fehlermeldung wie die folgende erhalten:

Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.

Dieser Fehler zeigt an, dass Sie das Limit von PEERPODS_LIMIT_PER_NODE auf Ihren Worker Nodes erreicht haben. Die Ressource kata.peerpods.io/vm gibt die Anzahl der auf jedem Arbeitsknoten verfügbaren Peer-Pod-Slots an.

Gehen Sie wie folgt vor, um das Problem zu lösen:

1. Überprüfen Sie den aktuellen Grenzwert und die Zuweisung.

   oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}'
   

2. Prüfen Sie, wie viele Peer-Pods derzeit ausgeführt werden.

   oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l
   

3. Erhöhen Sie den Wert PEERPODS_LIMIT_PER_NODE wie in Wie viele Peer-Pods kann ich pro Arbeitsknoten ausführen? beschrieben.

4. Alternativ können Sie weitere Arbeitsknoten zu Ihrem Cluster hinzufügen, um die Gesamtkapazität zu erhöhen.

Können vertrauliche Container bestimmte Sicherheitsstandards erfüllen, wie z. B. NIST 800-53 R5?

Warum erhalte ich nach dem Upgrade auf den „ OpenShift Sandboxed Containers Operator“ 1.12.1 einen IAM-Authentifizierungsfehler?

OpenShift Nach dem Upgrade auf die Version „ 1.12.1 Sandboxed Containers Operator“ ( ) kann es vorkommen, dass in den Protokollen des Cloud API Adapters (CAA) ein Fehler ähnlich dem folgenden angezeigt wird:

cloud-api-adaptor: cluster error with:
 Unauthorized
further details:
 {
    "StatusCode": 401,
    "Result": {
        "code": "A0007",
        "description": "You do not have the correct permissions to perform this action..."
    }
}

Dieser Fehler tritt auf, weil mit der Version 1.12.1 eine neue Anforderung eingeführt wurde, wonach die Sicherheitsgruppe des Clusters automatisch über die IKS-Clusterdienst-API unter IBM Cloud abgerufen werden muss. Bei der Verwendung von „ IBMCLOUD_IAM_PROFILE_ID “ zur Authentifizierung (Identität der Rechenressource) verfügt das IAM-Profil möglicherweise nicht über die erforderlichen Berechtigungen, um die Cluster-Service-API abzufragen.

Um dieses Problem zu beheben, wählen Sie eine der folgenden Optionen:

1. Zusätzliche IAM-Berechtigungen erteilen (empfohlen): Aktualisieren Sie das IAM-Profil, um Berechtigungen für die IKS-Cluster-Service-API hinzuzufügen, insbesondere die Berechtigung zum Aufruf von GetClusterTypeSecurityGroups(). Wenden Sie sich an Ihren „ IBM Cloud “-Administrator, um die erforderlichen Berechtigungen hinzuzufügen.

2. Legen Sie die ID der Sicherheitsgruppe explizit fest: Konfigurieren Sie die Umgebungsvariable „ IBMCLOUD_VPC_SG_ID “ in der Datei „ peer-pods-cm “ ( ConfigMap ), um die automatische Suche nach der Cluster-Sicherheitsgruppe zu umgehen:

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'
   

   Starten Sie anschließend das Daemonset des Cloud-API-Adapters neu:

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. API-Schlüssel-Authentifizierung verwenden: Wechseln Sie von der Authentifizierung über IBMCLOUD_IAM_PROFILE_ID zur Authentifizierung über IBMCLOUD_API_KEY, die in der Regel umfassendere Berechtigungen bietet. Ersetzen Sie den „ peer-pods-secret “-Schlüssel durch Ihren API-Schlüssel, anstatt das IAM-Profil zu verwenden.

Weitere Informationen zu den Änderungen in Version 1.12.1 finden Sie im Upstream-Commit zu „cloud-api-adaptor“ unter dde66055.

Wenden Sie sich an Ihr IBM Team, um spezifische Sicherheitsinteressen zu besprechen.

Was ist die Standardzeitzone für meine VPC-Arbeitsknoten?

Ab der Patch-Version 4.16.56_1602, die am 27. Januar 2026 veröffentlicht wurde, setzen alle zukünftigen Patches für VPC-Cluster die Ortszeit der Arbeitsknoten auf UTC.