|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * migrating_from_ocp_3_to_4/installing-3-4.adoc |
| 4 | +// * migrating_from_ocp_3_to_4/installing-restricted-3-4.adoc |
| 5 | +// * migration_toolkit_for_containers/installing-mtc.adoc |
| 6 | +// * migration_toolkit_for_containers/installing-mtc-restricted.adoc |
| 7 | + |
| 8 | +:_content-type: CONCEPT |
| 9 | +[id="migration-about-configuring-proxies_{context}"] |
| 10 | += Proxy configuration |
| 11 | + |
| 12 | +For {product-title} 4.1 and earlier versions, you must configure proxies in the `MigrationController` custom resource (CR) manifest after you install the {mtc-full} Operator because these versions do not support a cluster-wide `proxy` object. |
| 13 | + |
| 14 | +For {product-title} 4.2 to {product-version}, the {mtc-full} ({mtc-short}) inherits the cluster-wide proxy settings. You can change the proxy parameters if you want to override the cluster-wide proxy settings. |
| 15 | + |
| 16 | +[id="direct-volume-migration_{context}"] |
| 17 | +== Direct volume migration |
| 18 | + |
| 19 | +Direct Volume Migration (DVM) was introduced in MTC 1.4.2. DVM supports only one proxy. The source cluster cannot access the route of the target cluster if the target cluster is also behind a proxy. |
| 20 | + |
| 21 | +If you want to perform a DVM from a source cluster behind a proxy, you must configure a TCP proxy that works at the transport layer and forwards the SSL connections transparently without decrypting and re-encrypting them with their own SSL certificates. A Stunnel proxy is an example of such a proxy. |
| 22 | + |
| 23 | +[id="tcp-proxy-setup-for-dvm_{context}"] |
| 24 | +=== TCP proxy setup for DVM |
| 25 | + |
| 26 | +You can set up a direct connection between the source and the target cluster through a TCP proxy and configure the `stunnel_tcp_proxy` variable in the `MigrationController` CR to use the proxy: |
| 27 | + |
| 28 | +[source, yaml] |
| 29 | +---- |
| 30 | +apiVersion: migration.openshift.io/v1alpha1 |
| 31 | +kind: MigrationController |
| 32 | +metadata: |
| 33 | + name: migration-controller |
| 34 | + namespace: openshift-migration |
| 35 | +spec: |
| 36 | + [...] |
| 37 | + stunnel_tcp_proxy: http://username:password@ip:port |
| 38 | +---- |
| 39 | + |
| 40 | +Direct volume migration (DVM) supports only basic authentication for the proxy. Moreover, DVM works only from behind proxies that can tunnel a TCP connection transparently. HTTP/HTTPS proxies in man-in-the-middle mode do not work. The existing cluster-wide proxies might not support this behavior. As a result, the proxy settings for DVM are intentionally kept different from the usual proxy configuration in {mtc-short}. |
| 41 | + |
| 42 | +[id="why-tcp-proxy-instead-of-an-http-https-proxy_{context}"] |
| 43 | +=== Why use a TCP proxy instead of an HTTP/HTTPS proxy? |
| 44 | + |
| 45 | +You can enable DVM by running Rsync between the source and the target cluster over an OpenShift route. Traffic is encrypted using Stunnel, a TCP proxy. The Stunnel running on the source cluster initiates a TLS connection with the target Stunnel and transfers data over an encrypted channel. |
| 46 | + |
| 47 | +Cluster-wide HTTP/HTTPS proxies in OpenShift are usually configured in man-in-the-middle mode where they negotiate their own TLS session with the outside servers. However, this does not work with Stunnel. Stunnel requires that its TLS session be untouched by the proxy, essentially making the proxy a transparent tunnel which simply forwards the TCP connection as-is. Therefore, you must use a TCP proxy. |
| 48 | + |
| 49 | +[id="dvm-known-issues_{context}"] |
| 50 | +=== Known issue |
| 51 | + |
| 52 | +.Migration fails with error `Upgrade request required` |
| 53 | + |
| 54 | +The migration Controller uses the SPDY protocol to execute commands within remote pods. If the remote cluster is behind a proxy or a firewall that does not support the SPDY protocol, the migration controller fails to execute remote commands. The migration fails with the error message `Upgrade request required`. |
| 55 | +Workaround: Use a proxy that supports the SPDY protocol. |
| 56 | + |
| 57 | +In addition to supporting the SPDY protocol, the proxy or firewall also must pass the `Upgrade` HTTP header to the API server. The client uses this header to open a websocket connection with the API server. If the `Upgrade` header is blocked by the proxy or firewall, the migration fails with the error message `Upgrade request required`. |
| 58 | +Workaround: Ensure that the proxy forwards the `Upgrade` header. |
| 59 | + |
| 60 | +[id="tuning-network-policies-for-migrations_{context}"] |
| 61 | +== Tuning network policies for migrations |
| 62 | + |
| 63 | +OpenShift supports restricting traffic to or from pods using _NetworkPolicy_ or _EgressFirewalls_ based on the network plugin used by the cluster. If any of the source namespaces involved in a migration use such mechanisms to restrict network traffic to pods, the restrictions might inadvertently stop traffic to Rsync pods during migration. |
| 64 | + |
| 65 | +Rsync pods running on both the source and the target clusters must connect to each other over an OpenShift Route. Existing _NetworkPolicy_ or _EgressNetworkPolicy_ objects can be configured to automatically exempt Rsync pods from these traffic restrictions. |
| 66 | + |
| 67 | +[id="dvm-network-policy-configuration_{context}"] |
| 68 | +=== NetworkPolicy configuration |
| 69 | + |
| 70 | +[id="egress-traffic-from-rsync-pods_{context}"] |
| 71 | +==== Egress traffic from Rsync pods |
| 72 | + |
| 73 | +You can use the unique labels of Rsync pods to allow egress traffic to pass from them if the `NetworkPolicy` configuration in the source or destination namespaces blocks this type of traffic. The following policy allows *all* egress traffic from Rsync pods in the namespace: |
| 74 | + |
| 75 | +[source, yaml] |
| 76 | +---- |
| 77 | +apiVersion: networking.k8s.io/v1 |
| 78 | +kind: NetworkPolicy |
| 79 | +metadata: |
| 80 | + name: allow-all-egress-from-rsync-pods |
| 81 | +spec: |
| 82 | + podSelector: |
| 83 | + matchLabels: |
| 84 | + owner: directvolumemigration |
| 85 | + app: directvolumemigration-rsync-transfer |
| 86 | + egress: |
| 87 | + - {} |
| 88 | + policyTypes: |
| 89 | + - Egress |
| 90 | +---- |
| 91 | + |
| 92 | +[id="ingress-traffic-to-rsync-pods_{context}"] |
| 93 | +==== Ingress traffic to Rsync pods |
| 94 | + |
| 95 | +[source, yaml] |
| 96 | +---- |
| 97 | +apiVersion: networking.k8s.io/v1 |
| 98 | +kind: NetworkPolicy |
| 99 | +metadata: |
| 100 | + name: allow-all-egress-from-rsync-pods |
| 101 | +spec: |
| 102 | + podSelector: |
| 103 | + matchLabels: |
| 104 | + owner: directvolumemigration |
| 105 | + app: directvolumemigration-rsync-transfer |
| 106 | + ingress: |
| 107 | + - {} |
| 108 | + policyTypes: |
| 109 | + - Ingress |
| 110 | +---- |
| 111 | + |
| 112 | +[id="egressnetworkpolicy-config_{context}"] |
| 113 | +=== EgressNetworkPolicy configuration |
| 114 | + |
| 115 | +The `EgressNetworkPolicy` object or _Egress Firewalls_ are OpenShift constructs designed to block egress traffic leaving the cluster. |
| 116 | + |
| 117 | +Unlike the `NetworkPolicy` object, the Egress Firewall works at a project level because it applies to all pods in the namespace. Therefore, the unique labels of Rsync pods do not exempt only Rsync pods from the restrictions. However, you can add the CIDR ranges of the source or target cluster to the _Allow_ rule of the policy so that a direct connection can be setup between two clusters. |
| 118 | + |
| 119 | +Based on which cluster the Egress Firewall is present in, you can add the CIDR range of the other cluster to allow egress traffic between the two: |
| 120 | + |
| 121 | +[source, yaml] |
| 122 | +---- |
| 123 | +apiVersion: network.openshift.io/v1 |
| 124 | +kind: EgressNetworkPolicy |
| 125 | +metadata: |
| 126 | + name: test-egress-policy |
| 127 | + namespace: <namespace> |
| 128 | +spec: |
| 129 | + egress: |
| 130 | + - to: |
| 131 | + cidrSelector: <cidr_of_source_or_target_cluster> |
| 132 | + type: Deny |
| 133 | +---- |
0 commit comments