3.4. プロキシー設定

OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。

OpenShift Container Platform 4.2 から 4.10 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。

3.4.1. ボリュームの直接移行

MTC 1.4.2 で、ボリュームの直接移行 (DVM) が導入されました。DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。

プロキシーの背後にあるソースクラスターから DVM を実行する場合には、トランスポート層で機能する TCP プロキシーを設定して、SSL 接続を独自の SSL 証明書で復号化および再暗号化せずに透過的に転送する必要があります。Stunnel プロキシーは、このようなプロキシーの例です。

3.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 の通常のプロキシー設定とは異なる状態に保たれます。

3.4.1.2. HTTP/HTTPS プロキシーの代わりに TCP プロキシーを使用する理由

DVM を有効にするには、OpenShift ルートを介してソースおよびターゲットクラスター間で Rsync を実行します。トラフィックは、TCP プロキシーである Stunnel を使用して暗号化されます。ソースクラスターで実行している Stunnel は、ターゲット Stunnel との TLS 接続を開始し、暗号化されたチャネルでデータを転送します。

OpenShift のクラスター全体の HTTP/HTTPS プロキシーは通常、外部サーバーで独自の TLS セッションをネゴシエートする中間者モードで設定されます。ただし、これは Stunnel では機能しません。Stunnel では、プロキシーによって TLS セッションが変更されないようにする必要があります。基本的には、プロキシーを透過的なトンネルにし、単純に TCP 接続をそのまま転送する必要があります。したがって、TCP プロキシーを使用する必要があります。

3.4.1.3. 既知の問題

移行が Upgrade request required エラーで失敗する

移行コントローラーは SPDY プロトコルを使用してリモート Pod 内でコマンドを実行します。リモートクラスターがプロキシーまたは、SPDY プロトコルをサポートしないファイアウォールの背後にある場合には、移行コントローラーはリモートコマンドの実行に失敗します。移行に失敗し、Upgrade request required というエラーメッセージが表示されます。回避策: SPDY プロトコルをサポートするプロキシーを使用します。

SPDY プロトコルのサポートに加えて、このプロキシーまたはファイアウォールでは、Upgrade HTTP ヘッダーを API サーバーに渡す必要もあります。クライアントはこのヘッダーを使用して API サーバーと Websocket 接続を開きます。Upgrade ヘッダーがプロキシーまたはファイアウォールでブロックされると、移行に失敗し、Upgrade request required というエラーメッセージが表示されます。回避策: プロキシーで Upgrade ヘッダーが転送されるようにしてください。

3.4.2. 移行用のネットワークポリシーのチューニング

OpenShift は、クラスターで使用されるネットワークプラグインに基づいて NetworkPolicy または EgressFirewalls を使用した Pod との間のトラフィックの制限をサポートします。移行に関連するソース namespace のいずれかがこのようなメカニズムを使用して Pod へのネットワークトラフィックを制限する場合には、この制限により移行時に Rsync Pod へのトラフィックが誤って停止される可能性があります。

ソースおよびターゲットクラスターの両方で実行される Rsync Pod は OpenShift Route 経由で相互に接続する必要があります。既存の NetworkPolicy または EgressNetworkPolicy オブジェクトは、これらのトラフィックの制限が課されないように Rsync Pod を自動的に取り除くように設定できます。

3.4.2.1. NetworkPolicy の設定

3.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
3.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

3.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

3.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]

3.4.2.4. RsyncPod の補足グループの設定

PVC が共有ストレージを使用する場合、Pod がアクセスを許可するように RsyncPod 定義に補足グループを追加して、そのストレージへのアクセスを設定できます。

表3.2 RsyncPod の補足グループ

変数タイプデフォルト説明

src_supplemental_groups

string

設定されていません

ソース Rsync Pod の補足グループのコンマ区切りリスト

target_supplemental_groups

string

設定されていません

ターゲット Rsync Pod の補足グループのコンマ区切りリスト

使用例

MigrationController CR を更新して、これらの補足グループの値を設定できます。

spec:
  src_supplemental_groups: "1000,2000"
  target_supplemental_groups: "2000,3000"

3.4.3. プロキシーの設定

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  1. MigrationController CR マニフェストを取得します。

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  2. プロキシーパラメーターを更新します。

    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
    1
    ボリュームの直接移行のための Stunnel プロキシー URL。
    2
    プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のコンマ区切りの一覧。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

    httpProxy または httpsProxy フィールドのいずれも設定されていない場合、このフィールドは無視されます。

  3. マニフェストを migration-controller.yaml として保存します。
  4. 更新したマニフェストを適用します。

    $ oc replace -f migration-controller.yaml -n openshift-migration

詳細は、Configuring the cluster-wide proxy を参照してください。