Private VPC-Cluster: Warum kann ich mich nicht mit der OpenShift-Konsole verbinden?
Behebung von Problemen bei der Verbindung mit der Konsole OpenShift auf einem Cluster, der nur über einen privaten Dienstendpunkt verfügt.
Die Informationen in diesem Leitfaden zur Fehlerbehebung beziehen sich auf VPC-Cluster mit nur einem privaten Service-Endpunkt.
1. Verständnis des Cluster-Verbindungsflusses
Das folgende Diagramm zeigt den Verbindungsfluss für einen VPC-Cluster mit privaten Dienstendpunkten zur Verbindung mit der Webkonsole OpenShift. In diesem Diagramm wird davon ausgegangen, dass der Cluster die Standardeinstellungen OAuth hat. Sehen Sie sich dieses Diagramm und die folgenden Beschreibungen an, um besser zu verstehen, welche Schritte zur Fehlerbehebung erforderlich sein könnten.
- Der Webbrowser stellt über das VPN eine Verbindung zum Cluster-Master-API-Server her. Ein signiertes Zertifikat wird ausgetauscht und eine Umleitung weist den Webbrowser an, stattdessen eine Verbindung zum Konsolen-Lastenausgleich OpenShift herzustellen.
- (a) Der Webbrowser verbindet sich über das VPN mit dem Konsolen-Load-Balancer OpenShift, der die Konsole OpenShift verfügbar macht. (b) Diese Anfrage wird an einen der beiden Openshift-Konsolen-Pods gesendet.
- Der openshift-console-Pod verbindet sich mit dem Server-Port des Cluster-Masters OAuth, um zu prüfen, ob die Verbindung bereits authentifiziert ist. Wenn die Anfrage bereits authentifiziert ist, ist die Verbindung zur Webkonsole OpenShift hergestellt und der Zugriff auf die Webkonsole ist möglich. Wenn die Anfrage nicht authentifiziert ist, wird der Benutzer an den Cluster OAuth Dienst auf dem Cluster-Master weitergeleitet.
- Der Webbrowser verbindet sich über das VPN mit dem Serverport des Clusters OAuth, der den Client an IAM weiterleitet.
- Der Webbrowser stellt über das öffentliche Netzwerk eine Verbindung zu IAM her. Der Benutzer gibt sein Passwort ein und, falls erforderlich, eine 2FA-Verifizierung. Wenn dieser Schritt erfolgreich ist, wird der Benutzer zurück zum OAuth Server des Clusters umgeleitet.
- Der Webbrowser verbindet sich über das VPN wieder mit dem Server-Port des Clusters OAuth. Die Verbindung wird zurück zum OpenShift console load balancer umgeleitet.
- Der Webbrowser stellt über das VPN eine Verbindung zum Konsolen-Lastenausgleich OpenShift her, der die Konsole OpenShift verfügbar macht. Diese Anfrage wird an einen der beiden openshift-console-Pods gesendet, die sich wiederum mit dem Server-Port des Cluster-Masters OAuth verbinden, um zu prüfen, ob die Verbindung bereits authentifiziert ist. Wenn der Benutzer sein Passwort und 2FA eingegeben hat, wird die Authentifizierung bestätigt und der Benutzer wird mit der Hauptwebseite der Konsole OpenShift verbunden.
2. Überprüfen Sie Ihre VPC- und Cluster-Konfiguration
Überprüfen Sie, ob Ihre VPC und Ihr Cluster richtig konfiguriert sind. Eine falsche Konfiguration kann dazu führen, dass Sie nicht auf die Webkonsole OpenShift zugreifen können.
-
Stellen Sie sicher, dass Ihr Webbrowser in einem Client-System ausgeführt wird, das sich entweder in derselben VPC wie Ihr Cluster befindet oder über eine VPN-Verbindung zu dieser VPC verfügt. Die OpenShift-Konsole wird von einem privaten VPC-Lastenausgleich bereitgestellt, der nur über das private Netzwerk der VPC zugänglich ist.
-
Stellen Sie sicher, dass das Client-System Zugriff auf die öffentlichen Service-Endpunkte für IAM hat, die über
iam.cloud.ibm.comundlogin.ibm.comzugänglich sind. -
Für Cluster, die mit Version 4.13:
- Wenn Ihr Cluster die Standard-OAuth-Konfiguration 4.13 verwendet oder Sie Ihren Cluster so eingestellt haben, dass er das VPE-Gateway für OAuth verwendet, stellen Sie sicher, dass Ihr Client das private DNS für die VPC verwendet und dass
dieser DNS-Datenverkehr über das VPN an die VPC weitergeleitet wird. Das private DNS lautet normalerweise
161.26.0.7und161.26.0.8, es sei denn, Sie verwenden einen benutzerdefinierten DNS-Resolver. Dies ist erforderlich, damit das VPE-Gateway fürapiserverundOauth, das in keinem öffentlichen DNS vorhanden ist, im privaten DNS der VPC gefunden werden kann.
- Wenn Ihr Cluster die Standard-OAuth-Konfiguration 4.13 verwendet oder Sie Ihren Cluster so eingestellt haben, dass er das VPE-Gateway für OAuth verwendet, stellen Sie sicher, dass Ihr Client das private DNS für die VPC verwendet und dass
dieser DNS-Datenverkehr über das VPN an die VPC weitergeleitet wird. Das private DNS lautet normalerweise
-
Für Cluster, die eine unterstützte Version außer 4.13:
- Wenn Sie die Standard-Oauth-Cluster-Einstellungen verwenden, stellen Sie sicher, dass in der VPN-Konfiguration Routen vorhanden sind, damit der gesamte
166.8.0.0/14-Datenverkehr entweder über dasselbe VPN oder ein anderes VPN, das eine Verbindung zu IBM Cloud herstellt, geleitet wird. Dies ist erforderlich, um eine Verbindung zum API-Server des Clusters und zu den Serverports von OAuth herzustellen.
- Wenn Sie die Standard-Oauth-Cluster-Einstellungen verwenden, stellen Sie sicher, dass in der VPN-Konfiguration Routen vorhanden sind, damit der gesamte
3. Sammeln von Clusterdaten
Befolgen Sie diese Schritte, um die für die Fehlerbehebung erforderlichen Clusterinformationen zu sammeln. Die mit diesen Befehlen gesammelten Ergebnisse werden in späteren Schritten verwendet.
-
Suchen Sie den Cluster-API-Server URL. In späteren Befehlen wird diese URL als
${CLUSTER_APISERVER_URL}bezeichnet.- Führen Sie den Befehl
ibmcloud ks cluster get -c CLUSTER_IDaus.
ibmcloud oc cluster get -c CLUSTER_ID ``` 2. Suchen Sie im Abschnitt " `Master` " der Ausgabe nach " `URL` ". Die URL sollte das folgende Format haben: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<YYYYY>`. - Führen Sie den Befehl
-
Suchen Sie den Cluster OAuth URL. In späteren Befehlen wird diese URL als
${CLUSTER_OAUTH_URL}bezeichnet.- Führen Sie den Befehl
kubectl get --raw /.well-known/oauth-authorization-server | grep issueraus. Verwenden Sie nichtibmcloud oc cluster get -c CLUSTER_ID, da dieser Befehl möglicherweise eine andere URL zurückgibt.
kubectl get --raw /.well-known/oauth-authorization-server | grep issuer ``` 2. Suchen Sie in der Ausgabe nach URL in einem der folgenden Formate. - Wenn das VPE-Gateway nicht für OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>` verwendet wird. - Wenn das VPE-Gateway für OAuth: `https://<CLUSTERID>.vpe.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>` verwendet wird. - Führen Sie den Befehl
-
Suchen Sie die Subdomain Ingress. In späteren Befehlen wird diese Subdomain als
${CONSOLE_LOAD_BALANCER}bezeichnet.- Führen Sie den Befehl
ibmcloud oc cluster get -c CLUSTER_IDaus.
ibmcloud oc cluster get -c CLUSTER_ID ``` 2. Suchen Sie in der Ausgabe die Subdomain, die dem folgenden Format entspricht: `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`. Beachten Sie, dass das Format stattdessen Ihrer benutzerdefinierten Konfiguration entspricht, wenn Sie eine benutzerdefinierte Ingress-Subdomain konfiguriert haben. - Führen Sie den Befehl
4. Verbindungen überprüfen und Fehler beheben
Führen Sie die folgenden Schritte aus, um die im Verbindungsfluss beschriebenen Verbindungen zu überprüfen. Wenn Sie ein Verbindungsproblem feststellen, verwenden Sie die Informationen, um das Problem zu beheben.
-
Überprüfen Sie, ob Ingress und die Router- und Konsolen-Pods fehlerfrei funktionieren.
- Führen Sie die Befehle aus.
ibmcloud oc cluster get -c CLUSTERID ibmcloud oc ingress status-report get -c CLUSTERID ``` 2. Wenn die Ausgabe einen Fehlerstatus anzeigt, verwenden Sie [die Dokumentation zur Fehlerbehebung bei Ingress](/docs/openshift?topic=openshift-ingress-status), um das Problem zu beheben. -
Überprüfen Sie, ob die OpenShift-Cluster-Betreiber fehlerfrei funktionieren.
- Führen Sie den folgenden Befehl aus:
oc get clusteroperators ``` 2. Wenn die Ausgabe zeigt, dass einige Operatoren nicht fehlerfrei sind oder nicht mit der aktuellen Version ausgeführt werden, verwenden Sie [die Dokumentation zur Fehlerbehebung für die Cluster-Version von OpenShift](/docs/openshift?topic=openshift-ts-cluster-version-downlevel), um das Problem zu beheben. Sie können auch die Dokumentation unter IBM und Red Hat nach bestimmten Fehlern durchsuchen. 3. Wenn der Konsolenbediener nicht in Ordnung ist, überprüfen Sie die Pod-Protokolle `openshift-console/console...` und `openshift-console-operator/console-operator...`, um festzustellen, ob eine Sicherheitsgruppe, ACL oder DNS-Anpassung die Pods daran hindert, sich mit dem Anschluss OAuth oder der Konsole OpenShift zu verbinden URL. Eine Sicherheitsgruppe, ACL oder DNS könnte so konfiguriert sein, dass die Verbindung verhindert wird. -
Überprüfen Sie, ob die Verbindung zum Cluster-Master-API-Server erfolgreich hergestellt wurde.
- Führen Sie den folgenden Befehl aus: Geben Sie den Cluster-Apiserver URL an, den Sie in den vorherigen Schritten gefunden haben.
curl -k -vvv ${CLUSTER_APISERVER_URL}/version ``` 2. Wenn die Verbindung nicht erfolgreich hergestellt werden kann, führen Sie die folgenden Überprüfungen durch und beheben Sie alle gefundenen Probleme. 1. Überprüfen Sie, ob der Cluster-Master fehlerfrei funktioniert, indem Sie den Befehl `ibmcloud oc cluster get -c <CLUSTER-ID>` ausführen. Informationen zur Lösung von Problemen mit Cluster-Mastern finden Sie unter ["Überprüfung des Master-Gesundheitszustands](/docs/openshift?topic=openshift-debug_master) ". 2. Überprüfen Sie, ob der Hostname-Teil von URL über DNS aufgelöst wird. Verwenden Sie den Befehl `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` und geben Sie den Cluster-API-Server URL an. 3. Überprüfen Sie, ob es eine Route durch Ihr VPN gibt, die eine Verbindung zum Cluster-API-Server URL herstellt. 4. Wenn der Cluster-Apiserver URL Ihre Cluster-ID enthält (was darauf hinweist, dass der Cluster das VPE-Gateway für die Verbindung zum Cluster-Apiserver verwendet), überprüfen Sie, ob die VPE-Gateway-Sicherheitsgruppe für den Cluster-Master den Datenverkehr von Ihrem VPN-Client-Subnetz zulässt. Führen Sie die Schritte unter [Zugriff auf die Konsole OpenShift aus, wenn der Zugriff auf OAuth auf VPE-Gateway eingestellt ist](/docs/openshift?topic=openshift-console-apiserver-oauthvpe). 5. Überprüfen Sie, ob Sicherheitsgruppen, ACLs oder benutzerdefinierte VPC-Routen, die auf das VPN angewendet werden, den Datenverkehr zwischen dem VPN und dem Cluster-API-Server verhindern. Sie können dies testen, indem Sie vorübergehend den gesamten ein- und ausgehenden Datenverkehr über die VPN-Sicherheitsgruppe und die ACL zulassen und dann prüfen, ob das Problem dadurch behoben wird. Wenn dies der Fall ist, nehmen Sie die erforderlichen Änderungen an Ihren Sicherheitsgruppen, ACLs oder benutzerdefinierten Routen vor, um den Datenverkehr zuzulassen. 6. Überprüfen Sie, ob Regeln für kontextbasierte Einschränkungen (CBR) auf dem Cluster den Client daran hindern, eine Verbindung zum Cluster-API-Server herzustellen. Sie können dies testen, indem Sie Ihrer CBR-Regel vorübergehend eine Netzwerkzone hinzufügen, die alle IPs und Subnetze zulässt. Wenn diese vorübergehende Änderung das Problem behebt, nehmen Sie die erforderlichen Änderungen an der Regel vor, um den Datenverkehr zuzulassen. -
Überprüfen Sie, ob die Verbindung zum Cluster-Lastenausgleich, der die OpenShift-Konsole verfügbar macht, erfolgreich ist.
- Führen Sie den folgenden Befehl aus: Geben Sie die Ingress-Subdomain an, die Sie in den vorherigen Schritten gefunden haben.
curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/ ``` 2. Wenn die Verbindung nicht erfolgreich hergestellt werden kann, führen Sie die folgenden Überprüfungen durch und beheben Sie alle gefundenen Probleme. 1. Überprüfen Sie, ob der Hostname-Teil der Subdomain über DNS aufgelöst wird. Verwenden Sie den Befehl `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}`. 2. Überprüfen Sie, ob es eine Route durch Ihr VPN zu dieser Lastverteiler-Subdomain gibt. Überprüfen Sie, ob die Route alle IPs oder Subnetze enthält, die der Lastverteiler verwendet. Die Ausgabe für den Befehl `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` enthält die aktuellen IP-Adressen und Subnetze des Lastenausgleichs. Beachten Sie jedoch, dass sich diese ändern können, wenn der Lastenausgleich nach oben oder unten skaliert wird. 3. Wenn Sie Sicherheitsgruppen, ACLs oder benutzerdefinierte VPC-Routen geändert haben, die auf den Lastverteiler angewendet werden, überprüfen Sie, ob Änderungen oder Regeln, die Sie angewendet haben, die Verbindung verhindern. Wenn Sie keine dieser Komponenten geändert haben und sie die Standardwerte verwenden, können Sie diesen Schritt überspringen. 4. Überprüfen Sie, ob Sicherheitsgruppen, ACLs oder benutzerdefinierte VPC-Routen, die auf das VPN angewendet werden, den Datenverkehr zwischen dem VPN und dem Lastausgleichsdienst verhindern. Sie können dies testen, indem Sie vorübergehend den gesamten ein- und ausgehenden Datenverkehr über die VPN-Sicherheitsgruppe und die ACL zulassen und dann prüfen, ob das Problem dadurch behoben wird. Wenn dies der Fall ist, nehmen Sie die erforderlichen Änderungen an Ihren Sicherheitsgruppen, ACLs oder benutzerdefinierten Routen vor, um den Datenverkehr zuzulassen. -
Überprüfen Sie, ob die Verbindung zum Cluster OAuth erfolgreich ist.
- Führen Sie den folgenden Befehl aus: Geben Sie den Cluster OAuth URL an, den Sie in den vorherigen Schritten gefunden haben.
curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz ``` 2. Wenn die Verbindung nicht erfolgreich hergestellt werden kann, führen Sie die folgenden Überprüfungen durch und beheben Sie alle gefundenen Probleme. 1. Überprüfen Sie, ob Ihr Cluster-Master fehlerfrei funktioniert, indem Sie den Befehl `ibmcloud oc cluster get -c <CLUSTER-ID>` ausführen. Informationen zur Lösung von Problemen mit Cluster-Mastern finden Sie unter ["Überprüfung des Master-Gesundheitszustands](/docs/openshift?topic=openshift-debug_master) ". 2. Prüfen Sie, ob der Teil des Hostnamens des Clusters OAuth URL über DNS aufgelöst wird. Verwenden Sie die `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` und geben Sie den Cluster OAuth URL an. 3. Stellen Sie sicher, dass es eine Route durch Ihr VPN zum Cluster-Master gibt OAuth URL. 4. Überprüfen Sie, ob auf das VPN angewendete Sicherheitsgruppen, ACLs oder benutzerdefinierte VPC-Routen den Verkehr zwischen dem VPN und dem Cluster OAuth Server verhindern. Sie können dies testen, indem Sie vorübergehend den gesamten ein- und ausgehenden Datenverkehr über die VPN-Sicherheitsgruppe und die ACL zulassen und dann prüfen, ob das Problem dadurch behoben wird. Wenn dies der Fall ist, nehmen Sie die erforderlichen Änderungen an Ihren Sicherheitsgruppen, ACLs oder benutzerdefinierten Routen vor, um den Datenverkehr zuzulassen. 5. Überprüfen Sie, ob CBR-Regeln (Context Based Restriction) auf dem Cluster den Client daran hindern, eine Verbindung zum Cluster OAuth Server herzustellen. Sie können dies testen, indem Sie Ihrer CBR-Regel vorübergehend eine Netzwerkzone hinzufügen, die alle IPs und Subnetze zulässt. Wenn diese vorübergehende Änderung das Problem behebt, nehmen Sie die erforderlichen Änderungen an der Regel vor, um den Datenverkehr zuzulassen. -
Überprüfen Sie, ob die Verbindung zu IAM erfolgreich hergestellt wurde.
- Führen Sie die Befehle aus.
curl -vvv https://iam.cloud.ibm.com/healthz curl -vvv -o /dev/null -s https://login.ibm.com/ ``` 2. Wenn einer dieser Befehle fehlschlägt, überprüfen Sie, ob das Client-System in der Lage ist, diese URLs zuverlässig zu verbinden, und ob die URLs nicht durch Client- oder Unternehmens-Firewalls blockiert werden. Beachten Sie, dass diese URLs einen Zugang zum öffentlichen Internet erfordern.
5. Support kontaktieren
Wenn Sie alle oben genannten Schritte ausgeführt haben und das Problem nicht behoben wurde, wenden Sie sich an den Support. Öffnen Sie einen Supportfall. Fügen Sie in den Falldetails alle relevanten Protokolldateien, Fehlermeldungen oder Befehlsausgaben bei.