Einschränkungen und Kontingente der Dienste

Informieren Sie sich über die für Cluster geltenden Servicebeschränkungen und Kontingente und erfahren Sie, welche Grenzwerte bei Bedarf angepasst werden können.

Wenn zu erwarten ist, dass eine der folgenden Red Hat OpenShift on IBM Cloud-Einschränkungen erreicht wird, wenden Sie sich an den IBM Support und geben Sie in Ihrem Support-Ticket die Cluster-ID, den neuen Kontingentgrenzwert und die Region an.

Service- und Kontingenteinschränkungen

Für Red Hat OpenShift on IBM Cloud gelten die folgenden Serviceeinschränkungen und Kontingente, die sich auf alle Cluster beziehen, unabhängig davon, welchen Infrastrukturprovider Sie verwenden möchten. Vergessen Sie dabei nicht, dass auch die Einschränkungen für klassische Cluster und VPC-Cluster zu berücksichtigen sind.

Zum Anzeigen der Kontingenteinschränkungen in Ihrem IBM Cloud-Konto können Sie den Befehl ibmcloud oc quota ls verwenden.

Red Hat OpenShift on IBM Cloud Einschränkungen
Kategorie	Beschreibung
Begrenzungen bei der API-Rate	200 Anforderungen an die Red Hat OpenShift on IBM Cloud-API pro 10 Sekunden von jeder eindeutigen Quellen-IP-Adresse.
App-Bereitstellung	Die Apps, die Sie in Ihrem Cluster bereitstellen, und die Services, die Sie in Ihren Cluster integrieren, müssen unter dem Betriebssystem der Workerknoten ausgeführt werden können.
Calico-Netz-Plug-in	Das Ändern des Calico-Plug-ins, der Komponenten oder der Calico-Standardeinstellungen wird nicht unterstützt. Implementieren Sie beispielsweise keine neue Calico-Plug-in-Version oder die Dämongruppen oder Implementierungen für die Calico-Komponenten, Standardressourcen `IPPool` oder Calico-Knoten ändern. Stattdessen können Sie die Anweisungen in der Dokumentation zum Erstellen einer Netzrichtlinie (`NetworkPolicy`) oder einer globalen Netzrichtlinie (`GlobalNetworkPolicy`) für Calico befolgen, um die Calico-MTU zu ändern oder das Plug-in für die Portzuordnung für die Calico-CNI zu inaktivieren.
Clusterkontingent	Sie dürfen 100 Cluster pro Region und pro Infrastrukturprovider nicht überschreiten. Ab dem 01. Januar 2024 werden die Quoten jedoch schrittweise erhöht, bevor sie 100 erreichen. Wenden Sie sich an den IBM Support, falls Sie mehr von der Ressource benötigen. Geben Sie im Support-Fall die neue Kontingentgrenze für die gewünschte Region und den gewünschten Infrastrukturanbieter an. Führen Sie `ibmcloud quota ls` aus, um Kontingente aufzulisten.
Kubernetes	Bitte beachten Sie unbedingt die Einschränkungen des Kubernetes-Projekts.
KMS-Provider	Die Anpassung der IP-Adressen, die eine Verbindung zu Ihrer Instanz von IBM® Key Protect for IBM Cloud® herstellen dürfen, wird nicht unterstützt.
Red Hat OpenShift	Bitte beachten Sie unbedingt die Einschränkungen der OpenShift Container Platform für Ihre Version.
Kubernetes-Podprotokolle	Zum Überprüfen der Protokolle für einzelne App-Pods können Sie die Befehlszeile verwenden, um `oc logs <pod name>` auszuführen. Verwenden Sie das Kubernetes-Dashboard nicht, um Protokolle für Ihre Pods zu streamen, da dies Ihren Zugriff auf das Kubernetes-Dashboard beeinträchtigen könnte.
Monitoring	-Da IBM Ihren Cluster-Master verwaltet, ist die Ereignisalertfunktion für den Master inaktiviert. IBM überwacht Ihren Cluster-Master und behebt Probleme, sobald sie erkannt werden. Aus diesem Grund wird in der Administratorperspektive von Red Hat OpenShift möglicherweise die Nachricht `Not available` für den Status der Steuerebene angezeigt. Der integrierte Prometheus-Alert-Manager enthält zwei Regeln, die als aktive Alerts im Status `FIRING` angezeigt werden: `KubeControllerManagerDown` und `KubeSchedulerDown`. Diese Komponenten sind Teil des von IBM verwalteten Cluster-Masters, sodass Sie diese Alerts ignorieren können.
Betriebssystem	Workerknoten müssen eines der unterstützten Betriebssysteme ausführen. Sie können keinen Cluster mit Workerknoten erstellen, auf denen verschiedene Betriebssystemtypen ausgeführt werden. Weitere Informationen finden Sie in den Versionsinformationen zuRed Hat OpenShift on IBM Cloud.
OperatorHub-Katalog	Informationen zur Verwendung des Katalogs OperatorHub in privaten Clustern finden Sie unter OperatorHub und Quellenimages des Katalogs in `icr.io` spiegeln.
Podinstanzen	Sie können 110 Pods pro Workerknoten ausführen. Bei Workerknoten, die mit 11 CPU-Kernen oder mehr bereitgestellt sind, können 10 Pods pro Kern bis zu einem Limit von insgesamt 250 Pods pro Workerknoten unterstützt werden. Die Anzahl der Pods schließt `kube-system`- und `ibm-system`-Pods ein, die auf dem Workerknoten ausgeführt werden. Zur Leistungsverbesserung sollten Sie die Anzahl der Pods, die Sie pro Rechenkern ausführen, begrenzen, damit Sie den Workerknoten nicht übermäßig gebrauchen. Auf einem Workerknoten des Typs `b3c.4x16` beispielsweise können Sie 10 Pods pro Kern ausführen, die maximal 75 % der Gesamtkapazität des Workerknotens verwenden.
Veraltet Zeitbasierter Einmalkenncode (TOTP)	Stellen Sie zur Verwendung von TOTP sicher, dass die Mehrfaktorauthentifizierung (MFA) für Ihr gesamtes IBM Cloud-Konto aktiviert wurde. Wenn MFA nur für einige Benutzer aktiviert ist, aber nicht auf Kontoebene, können Authentifizierungsfehler auftreten.
Workerknotenquote	Maximal 500 Arbeitsknoten für alle Konten, die vor dem 01. Januar 2024 eingerichtet werden. Für Konten, die an oder nach diesem Datum eingerichtet werden, beträgt die maximale Quote 200, nachdem die Quoten zuvor gesenkt worden waren. Kontingente gelten pro Cluster Infrastrukturprovider. Wenden Sie sich an den IBM Support, falls Sie mehr von der Ressource benötigen. Geben Sie im Support-Fall die neue Kontingentgrenze für die gewünschte Region und den gewünschten Infrastrukturanbieter an. Um die aktuellen Kontingente aufzulisten, führen Sie folgenden Befehl aus: `ibmcloud ks quota ls`.
Größe des Workerpools	Ihr Cluster muss immer mindestens 2 Knoten umfassen. Aufgrund der Kontingentbegrenzung bei Workerknoten gelten Einschränkungen hinsichtlich der Anzahl der Worker-Pools pro Cluster und der Anzahl von Workerknoten pro Worker-Pool. Beispielsweise könnten Sie mit den Standardkontingent von 500 Workerknoten pro Region bis zu 500 Worker-Pools mit jeweils 1 Workerknoten in jeweils einer Region mit nur einem Cluster haben. Sie könnten aber auch über einen 1 Worker-Pool mit bis zu 500 Workerknoten in einer Region mit nur 1 Cluster verfügen.
Red Hat Enterprise Linux CoreOS-Workerknoten	Einem Cluster können maximal 12 Zonen hinzugefügt werden. So werden beispielsweise 3 RHCOS-Arbeiterpools mit jeweils 3 Zonen 9/12 des Kontingents für diesen Cluster beanspruchen.
Anzahl der Workerknoten	Cluster können bis zu 500 Arbeitsknoten umfassen.
Clusterbenennung	Um sicherzustellen, dass die Ingress-Unterdomäne und das Zertifikat ordnungsgemäß registriert werden, müssen die ersten 24 Zeichen der Clusternamen unterschiedlich sein. Wenn Sie innerhalb von 7 Tagen 5 Mal oder öfter Cluster mit demselben Namen oder Namen mit denselben ersten 24 Zeichen erstellen und löschen, z. B. zu Automatisierungs- oder Testzwecken, erreichen Sie möglicherweise die Let's Encrypt-Ratenbegrenzung für doppelte Zertifikate.
Ressourcengruppen	Ein Cluster kann in nur einer Ressourcengruppe erstellt werden; eine Änderung ist danach nicht mehr möglich. Wenn Sie einen Cluster in der falschen Ressourcengruppe erstellen, müssen Sie den Cluster löschen und in der richtigen Ressourcengruppe erneut erstellen. Wenn Sie außerdem den Befehl `ibmcloud oc cluster service bind` verwenden müssen, um eine Integration mit einem IBM Cloud-Service durchzuführen, muss sich dieser Service in derselben Ressourcengruppe befinden wie der Cluster. Dienste, die keine Ressourcengruppen verwenden, wie z. B. IBM Cloud Container Registry, oder die keine Dienstbindung benötigen, wie z. B. IBM Cloud Logs, funktionieren auch dann, wenn sich der Cluster in einer anderen Ressourcengruppe befindet.

Einschränkungen für Red Hat OpenShift on IBM Cloud-Cluster

Informieren Sie sich über die spezifischen Einschränkungen von Red Hat OpenShift-Clustern. Beachten Sie hierbei, dass auch die Einschränkungen für den Service, den klassischen Cluster oder den VPC-Cluster gelten.

Einschränkungen fürOpenShift Container Platform-Cluster
Kategorie	Beschreibung
Automatische Clusterskalierung	Der Cluster-Autoscaler Red Hat OpenShift über die Konsole Red Hat OpenShift-Verwaltung > Cluster-Einstellungen oder das entsprechende Objekt `ClusterAutoscaler` über die API `autoscaling.openshift.io/v1` wird nicht unterstützt. Verwenden Sie stattdessen das Helm-Plug-in `ibm-iks-cluster-autoscaler`.
Clusteraktualisierungen	Sie müssen Ihren Cluster aktualisieren, indem Sie die Tools der Red Hat OpenShift on IBM Cloud-API, -CLI oder -Konsole verwenden. Sie können Ihre Clusterversion nicht über OpenShift Container Platform-Tools wie die Red Hat OpenShift-Webkonsole aktualisieren.
Containerprotokolle	Wenn Sie einen Containerprotokollierungsoperator wie Fluentd verwenden, um Protokolle an einen ElasticSearch-Stack zu senden, müssen Sie die Bereitstellung der Clusterprotokollierung aktualisieren, um die Speicherklasse `ibmc-block-gold` zu verwenden.
Private Cluster	Abhängig vom Infrastrukturprovider sind Ihre Optionen für private Cluster begrenzt. VPC: Wenn Sie Ihren VPC-Cluster in der IBM Cloud-Konsole erstellen, verfügt Ihr Cluster sowohl über einen öffentlichen als auch einen privaten Cloud-Serviceendpunkt. Wenn Sie nur einen Endpunkt für einen Private-Cloud-Dienst wünschen, müssen Sie den Cluster stattdessen über die CLI erstellen und die Option `--disable-public-service-endpoint` angeben. Wenn Sie diese Option auswählen, wird Ihr Cluster standardmäßig mit Routern und Ingress-Controllern erstellt, die Ihre Anwendungen ausschließlich im privaten Netzwerk verfügbar machen. Wenn Sie Apps später in einem öffentlichen Netz zugänglich machen möchten, müssen Sie manuell öffentliche Router und Ingress-Controller erstellen. Klassisch: Sie können nur den öffentlichen und privaten Cloud-Serviceendpunkt oder den öffentlichen Cloud-Serviceendpunkt aktivieren, aber nicht nur den privaten Cloud-Serviceendpunkt. Nach der Clustererstellung können Sie die Serviceendpunkte später nicht mehr ändern.
Protokollierung	Informationen zum Einrichten eines Stacks aus OpenShift Container Platform(Elasticsearch), Fluentd und Kibana(EFK) finden Sie unter Installieren des Cluster Logging Operators.
Service Catalog	Der Servicekatalog wird nicht unterstützt. Verwenden Sie stattdessen Operatoren. Verwenden Sie nicht den OperatorHub für die Installation des Servicekatalogs.
Servicenetz	Das von Istio verwaltete Add-on wird nicht unterstützt. Verwenden Sie stattdessen den Red Hat service mesh operator. Hinweis: Die standardmäßige IBM Cloud-Konfiguration für Router ermöglicht einen Hostnetzbetrieb, der nicht mit der Netzrichtlinie für das Servicenetz kompatibel ist. Damit der Service-Mesh-Ingress funktioniert, müssen Sie eine Netzwerkrichtlinie anwenden.

Einschränkungen für klassische Cluster

Cluster der klassischen Infrastruktur in Red Hat OpenShift on IBM Cloud werden mit den folgenden Einschränkungen zur Verfügung gestellt.