4.4. プロキシー設定
OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy
オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController
カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。
OpenShift Container Platform 4.2 から 4.9 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。
4.4.1. ボリュームの直接移行
MTC 1.4.2 で、ボリュームの直接移行 (DVM) が導入されました。DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。
プロキシーの背後にあるソースクラスターから DVM を実行する場合には、トランスポート層で機能する TCP プロキシーを設定して、SSL 接続を独自の SSL 証明書で復号化および再暗号化せずに透過的に転送する必要があります。Stunnel プロキシーは、このようなプロキシーの例です。
4.4.1.1. DVM の TCP プロキシー設定
TCP プロキシー経由でソースとターゲットクラスターの間に直接接続を設定し、プロキシーを使用できるように MigrationController
CR の stunnel_tcp_proxy
変数を設定できます。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] stunnel_tcp_proxy: http://username:password@ip:port
ボリュームの直接移行 (DVM) は、プロキシーの Basic 認証のみをサポートします。さらに、DVM は、TCP 接続を透過的にトンネルできるプロキシーの背後でのみ機能します。中間者モードの HTTP/HTTPS プロキシーは機能しません。既存のクラスター全体にわたるプロキシーはこの動作をサポートしない可能性があります。その結果、DVM のプロキシー設定は、MTC の通常のプロキシー設定とは異なる状態に保たれます。
4.4.1.2. HTTP/HTTPS プロキシーの代わりに TCP プロキシーを使用する理由
DVM を有効にするには、OpenShift ルートを介してソースおよびターゲットクラスター間で Rsync を実行します。トラフィックは、TCP プロキシーである Stunnel を使用して暗号化されます。ソースクラスターで実行している Stunnel は、ターゲット Stunnel との TLS 接続を開始し、暗号化されたチャネルでデータを転送します。
OpenShift のクラスター全体の HTTP/HTTPS プロキシーは通常、外部サーバーで独自の TLS セッションをネゴシエートする中間者モードで設定されます。ただし、これは Stunnel では機能しません。Stunnel では、プロキシーによって TLS セッションが変更されないようにする必要があります。基本的には、プロキシーを透過的なトンネルにし、単純に TCP 接続をそのまま転送する必要があります。したがって、TCP プロキシーを使用する必要があります。
4.4.1.3. 既知の問題
移行が Upgrade request required
エラーで失敗する
移行コントローラーは SPDY プロトコルを使用してリモート Pod 内でコマンドを実行します。リモートクラスターがプロキシーまたは、SPDY プロトコルをサポートしないファイアウォールの背後にある場合には、移行コントローラーはリモートコマンドの実行に失敗します。移行に失敗し、Upgrade request required
というエラーメッセージが表示されます。回避策: SPDY プロトコルをサポートするプロキシーを使用します。
SPDY プロトコルのサポートに加えて、このプロキシーまたはファイアウォールでは、Upgrade
HTTP ヘッダーを API サーバーに渡す必要もあります。クライアントはこのヘッダーを使用して API サーバーと Websocket 接続を開きます。Upgrade
ヘッダーがプロキシーまたはファイアウォールでブロックされると、移行に失敗し、Upgrade request required
というエラーメッセージが表示されます。回避策: プロキシーで Upgrade
ヘッダーが転送されるようにしてください。
4.4.2. 移行用のネットワークポリシーのチューニング
OpenShift は、クラスターで使用されるネットワークプラグインに基づいて NetworkPolicy または EgressFirewalls を使用した Pod との間のトラフィックの制限をサポートします。移行に関連するソース namespace のいずれかがこのようなメカニズムを使用して Pod へのネットワークトラフィックを制限する場合には、この制限により移行時に Rsync Pod へのトラフィックが誤って停止される可能性があります。
ソースおよびターゲットクラスターの両方で実行される Rsync Pod は OpenShift Route 経由で相互に接続する必要があります。既存の NetworkPolicy または EgressNetworkPolicy オブジェクトは、これらのトラフィックの制限が課されないように Rsync Pod を自動的に取り除くように設定できます。
4.4.2.1. NetworkPolicy の設定
4.4.2.1.1. Rsync Pod からの egress トラフィック
Rsync Pod の一意のラベルを使用し、同期元または同期先 namespace の NetworkPolicy
設定がこのタイプのトラフィックをブロックする場合に egress トラフィックがそれらを通過することを許可できます。以下のポリシーは、namespace の Rsync Pod からの 全 egress トラフィックを許可します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer egress: - {} policyTypes: - Egress
4.4.2.1.2. Rsync Pod への ingress トラフィック
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer ingress: - {} policyTypes: - Ingress
4.4.2.2. EgressNetworkPolicy 設定
EgressNetworkPolicy
オブジェクトまたは Egress ファイアウォール は、egress トラフィックをクラスターからブロックするために設計された OpenShift コンストラクトです。
NetworkPolicy
オブジェクトとは異なり、Egress ファイアウォールは namespace のすべての Pod に適用されるためにプロジェクトレベルで機能します。そのため、Rsync Pod の一意のラベルを使用すると、この制限から除外するのは Rsync Pod だけではありません。ただし、ソースおよびターゲットクラスターの CIDR 範囲をポリシーの Allow ルールに追加して、2 つのクラスター間で直接接続を設定できます。
Egress ファイアウォールが存在するクラスターに基づいて、他のクラスターの CIDR 範囲を追加して、2 つの間の egress トラフィックを許可できます。
apiVersion: network.openshift.io/v1 kind: EgressNetworkPolicy metadata: name: test-egress-policy namespace: <namespace> spec: egress: - to: cidrSelector: <cidr_of_source_or_target_cluster> type: Deny
4.4.2.3. データ転送用の代替エンドポイントの選択
デフォルトでは、DVM は OpenShift Container Platform ルートをエンドポイントとして使用して、PV データを宛先クラスターに転送します。クラスタートポロジーで許可されている場合は、サポートされている別の種類のエンドポイントを選択できます。
クラスターごとに、MigrationController
CR で適切な 宛先 クラスターに rsync_endpoint_type
変数を設定することで、エンドポイントを設定できます。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] rsync_endpoint_type: [NodePort|ClusterIP|Route]
4.4.2.4. RsyncPod の補足グループの設定
PVC が共有ストレージを使用する場合、Pod がアクセスを許可するように RsyncPod 定義に補足グループを追加して、そのストレージへのアクセスを設定できます。
変数 | タイプ | デフォルト | 説明 |
---|---|---|---|
| 文字列 | 設定されていません | ソース Rsync Pod の補足グループのコンマ区切りリスト |
| 文字列 | 設定されていません | ターゲット Rsync Pod の補足グループのコンマ区切りリスト |
使用例
MigrationController
CR を更新して、これらの補足グループの値を設定できます。
spec: src_supplemental_groups: "1000,2000" target_supplemental_groups: "2000,3000"
4.4.3. プロキシーの設定
前提条件
-
cluster-admin
権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
手順
MigrationController
CR マニフェストを取得します。$ oc get migrationcontroller <migration_controller> -n openshift-migration
プロキシーパラメーターを更新します。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: <migration_controller> namespace: openshift-migration ... spec: stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1 noProxy: example.com 2
サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。インストール設定でnetworking.machineNetwork[].cidr
フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。httpProxy
またはhttpsProxy
フィールドのいずれも設定されていない場合、このフィールドは無視されます。-
マニフェストを
migration-controller.yaml
として保存します。 更新したマニフェストを適用します。
$ oc replace -f migration-controller.yaml -n openshift-migration
詳細は、Configuring the cluster-wide proxy を参照してください。