This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.6.4. Konfigurieren von Proxys
Für OpenShift Container Platform 4.1 und frühere Versionen müssen Sie, nachdem Sie den Migration Toolkit for Containers Operator installiert haben, Proxys im Manifest der Custom Resource (CR) MigrationController
konfigurieren, da diese Versionen kein clusterweites Proxy
-Objekt unterstützen.
Für OpenShift Container Platform 4.2 bis 4.10 erbt das Migration Toolkit for Containers (MTC) die clusterweiten Proxy-Einstellungen. Sie können die Proxy-Parameter ändern, wenn Sie die clusterweiten Proxy-Einstellungen außer Kraft setzen wollen.
Sie müssen die Proxys so konfigurieren, dass sie das SPDY-Protokoll zulassen und den Header Upgrade HTTP
an den API-Server weiterleiten. Andernfalls wird die Fehlermeldung Upgrade request required
angezeigt. Die CR MigrationController
verwendet SPDY, um Befehle in Remote-Pods auszuführen. Der Header Upgrade HTTP
ist erforderlich, um eine Websocket-Verbindung mit dem API-Server zu öffnen.
Direct Volume Migration
Wenn Sie eine Direct Volume Migration (DVM) von einem Quell-Cluster hinter einem Proxy durchführen, müssen Sie einen Stunnel-Proxy konfigurieren. Stunnel erstellt einen transparenten Tunnel zwischen dem Quell- und dem Ziel-Cluster für die TCP-Verbindung, ohne die Zertifikate zu ändern.
Die DVM unterstützt nur einen Proxy. Der Quell-Cluster kann nicht auf die Route des Ziel-Clusters zugreifen, wenn sich der Ziel-Cluster ebenfalls hinter einem Proxy befindet.
Voraussetzungen
-
Sie müssen auf allen Clustern als Benutzer mit
cluster-admin
-Privilegien angemeldet sein.
Vorgehensweise
Rufen Sie das CR-Manifest
MigrationController
ab:oc get migrationcontroller <migration_controller> -n openshift-migration
$ oc get migrationcontroller <migration_controller> -n openshift-migration
Copy to Clipboard Copied! Aktualisieren Sie die Proxy-Parameter:
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: <migration_controller> namespace: openshift-migration ... spec: stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> httpProxy: http://<username>:<password>@<ip>:<port> httpsProxy: http://<username>:<password>@<ip>:<port> noProxy: example.com
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: <migration_controller> namespace: openshift-migration ... spec: stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port>
1 httpProxy: http://<username>:<password>@<ip>:<port>
2 httpsProxy: http://<username>:<password>@<ip>:<port>
3 noProxy: example.com
4 Copy to Clipboard Copied! - 1
- Stunnel-Proxy-URL für die Direct Volume Migration.
- 2
- Proxy-URL für die Erstellung von HTTP-Verbindungen außerhalb des Clusters. Das URL-Schema muss
http
sein. - 3
- Proxy-URL für die Erstellung von HTTPS-Verbindungen außerhalb des Clusters. Wenn dies nicht angegeben wird, wird
httpProxy
sowohl für HTTP- als auch für HTTPS-Verbindungen verwendet. - 4
- Durch Kommata getrennte Liste von Zieldomain-Namen, Domains, IP-Adressen oder anderen Netzwerk-CIDRs zum Ausschluss von Proxying.
Stellen Sie einer Domain ein
.
voran, um nur Subdomains zu finden. Zum Beispiel gibt es bei.y.com
eine Übereinstimmung mitx.y.com
, aber nicht mity.com
. Verwenden Sie*
, um den Proxy für alle Ziele zu umgehen. Wenn Sie Worker hochskalieren, die nicht in dem durch das Installationskonfigurationsfeldnetworking.machineNetwork[].cidr
definierten Netzwerk enthalten sind, müssen Sie sie zu dieser Liste hinzufügen, um Verbindungsprobleme zu vermeiden.Dieses Feld wird ignoriert, wenn weder das Feld
httpProxy
noch das FeldhttpsProxy
konfiguriert ist.-
Speichern Sie das Manifest als
migration-controller.yaml
. Wenden Sie das aktualisierte Manifest an:
oc replace -f migration-controller.yaml -n openshift-migration
$ oc replace -f migration-controller.yaml -n openshift-migration
Copy to Clipboard Copied!
Weitere Informationen finden Sie unter Konfigurieren des clusterweiten Proxys.