19.2. OpenShift SDN クラスターネットワークプロバイダーからの移行


クラスター管理者は、OpenShift SDN CNI クラスターネットワークプロバイダーから OVN-Kubernetes Container Network Interface(CNI) クラスターネットワークプロバイダーに移行できます。

OVN-Kubernetes についての詳細は、OVN-Kubernetes ネットワークプロバイダーについて を参照してください。

19.2.1. OVN-Kubernetes ネットワークプロバイダーへの移行

OVN-Kubernetes Container Network Interface (CNI) クラスターネットワークプロバイダーへの移行は、クラスターに到達できなくなるダウンタイムも含まれる手動プロセスです。ロールバック手順が提供されますが、移行は一方向プロセスとなることが意図されています。

OVN-Kubernetes クラスターネットワークプロバイダーへの移行は、以下のプラットフォームでサポートされます。

  • ベアメタルハードウェア
  • Amazon Web Services (AWS)
  • Google Cloud Platform (GCP)
  • Microsoft Azure
  • Red Hat OpenStack Platform (RHOSP)
  • Red Hat Virtualization (RHV)
  • VMware vSphere
重要

OVN-Kubernetes ネットワークプラグインとの間の移行は、Red Hat OpenShift Dedicated、Azure Red Hat OpenShift (ARO)、Red Hat OpenShift Service on AWS (ROSA) などのマネージド OpenShift クラウドサービスではサポートされていません。

19.2.1.1. OVN-Kubernetes ネットワークプロバイダーへの移行についての考慮点

OpenShift Container Platform クラスターに 150 を超えるノードがある場合は、OVN-Kubernetes ネットワークプラグインへの移行について相談するサポートケースを開きます。

ノードに割り当てられたサブネット、および個々の Pod に割り当てられた IP アドレスは、移行時に保持されません。

OVN-Kubernetes ネットワークプロバイダーは OpenShift SDN ネットワークプロバイダーに存在する多くの機能を実装しますが、設定は同じではありません。

  • クラスターが以下の OpenShift SDN 機能のいずれかを使用する場合、OVN-Kubernetes で同じ機能を手動で設定する必要があります。

    • namespace の分離
    • Egress IP アドレス
    • Egress ネットワークポリシー
    • Egress ルーター Pod
    • マルチキャスト
  • クラスターが 100.64.0.0/16 IP アドレス範囲の一部を使用する場合、この IP アドレス範囲は内部で使用されるため、OVN-Kubernetes に移行することはできません。

以下のセクションでは、OVN-Kubernetes と OpenShift SDN の上記の機能間の設定の違いについて説明します。

namespace の分離

OVN-Kubernetes はネットワークポリシーの分離モードのみをサポートします。

重要

クラスターがマルチテナントまたはサブネットの分離モードのいずれかで設定された OpenShift SDN を使用する場合、OVN-Kubernetes ネットワークプロバイダーに移行することはできません。

Egress IP アドレス

OVN-Kubernetes と OpenShift SDN との間に egress IP アドレスを設定する際の相違点は、以下の表で説明されています。

Expand
表19.2 egress IP アドレス設定の違い
OVN-KubernetesOpenShift SDN
  • EgressIPs オブジェクトを作成します。
  • アノテーションを Node オブジェクトに追加します。
  • NetNamespace オブジェクトにパッチを適用します。
  • HostSubnet オブジェクトにパッチを適用します。

OVN-Kubernetes で egress IP アドレスを使用する方法についての詳細は、egress IP アドレスの設定について参照してください。

Egress ネットワークポリシー

OVN-Kubernetes と OpenShift SDN との間に egress ファイアウォールとしても知られる egress ネットワークポリシーの設定についての相違点は、以下の表に記載されています。

Expand
表19.3 egress ネットワークポリシー設定の相違点
OVN-KubernetesOpenShift SDN
  • EgressFirewall オブジェクトを namespace に作成します。
  • EgressNetworkPolicy オブジェクトを namespace に作成します。

OVN-Kubernetes で egress ファイアウォールを使用する方法についての詳細は、プロジェクトの egress ファイアウォールの設定について参照してください。

Egress ルーター Pod

OVN-Kubernetes は、リダイレクトモードで Egress ルーター Pod をサポートします。OVN-Kubernetes は、HTTP プロキシーモードまたは DNS プロキシーモードでは Egress ルーター Pod をサポートしません。

Cluster Network Operator で Egress ルーターをデプロイする場合、ノードセレクターを指定して、Egress ルーター Pod のホストに使用するノードを制御することはできません。

マルチキャスト

OVN-Kubernetes と OpenShift SDN でマルチキャストトラフィックを有効にする方法についての相違点は、以下の表で説明されています。

Expand
表19.4 マルチキャスト設定の相違点
OVN-KubernetesOpenShift SDN
  • アノテーションを Namespace オブジェクトに追加します。
  • アノテーションを NetNamespace オブジェクトに追加します。

OVN-Kubernetes でのマルチキャストの使用についての詳細は、プロジェクトのマルチキャストの有効化を参照してください。

ネットワークポリシー

OVN-Kubernetes は、networking.k8s.io/v1 API グループで Kubernetes NetworkPolicy API を完全にサポートします。OpenShift SDN から移行する際に、ネットワークポリシーで変更を加える必要はありません。

19.2.1.2. 移行プロセスの仕組み

以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。

Expand
表19.5 OpenShift SDN から OVN-Kubernetes への移行
ユーザーが開始する手順移行アクティビティー

cluster という名前の Network.operator.openshift.io カスタムリソース (CR) の migration フィールドを OVNKubernetes に設定します。migration フィールドを値に設定する前に null であることを確認します。

Cluster Network Operator (CNO)
cluster という名前の Network.config.openshift.io CR のステータスを更新します。
Machine Config Operator (MCO)
OVN-Kubernetes に必要な systemd 設定への更新をロールアウトします。MCO はデフォルトで 1 度にプールごとに単一のマシンを更新します。これにより、移行にかかる合計時間がクラスターのサイズと共に増加します。

Network.config.openshift.io CR の networkType フィールドを更新します。

CNO

以下のアクションを実行します。

  • OpenShift SDN コントロールプレーン Pod を破棄します。
  • OVN-Kubernetes コントロールプレーン Pod をデプロイします。
  • 新しいクラスターネットワークプロバイダーを反映するように Multus オブジェクトを更新します。

クラスターの各ノードを再起動します。

クラスター
ノードの再起動時に、クラスターは OVN-Kubernetes クラスターネットワークの Pod に IP アドレスを割り当てます。

OpenShift SDN へのロールバックが必要な場合、以下の表がプロセスについて説明します。

Expand
表19.6 OpenShift SDN へのロールバックの実行
ユーザーが開始する手順移行アクティビティー

MCO を一時停止し、移行が中断されないようにします。

MCO が停止します。

cluster という名前の Network.operator.openshift.io カスタムリソース (CR) の migration フィールドを OpenShiftSDN に設定します。migration フィールドを値に設定する前に null であることを確認します。

CNO
cluster という名前の Network.config.openshift.io CR のステータスを更新します。

networkType フィールドを更新します。

CNO

以下のアクションを実行します。

  • OVN-Kubernetes コントロールプレーン Pod を破棄します。
  • OpenShift SDN コントロールプレーン Pod をデプロイします。
  • 新しいクラスターネットワークプロバイダーを反映するように Multus オブジェクトを更新します。

クラスターの各ノードを再起動します。

クラスター
ノードがリブートすると、クラスターは Openshift-SDN ネットワーク上の Pod に IP アドレスを割り当てます。

クラスターのすべてのノードが再起動した後に MCO を有効にします。

MCO
OpenShift SDN に必要な systemd 設定への更新をロールアウトします。MCO はデフォルトで 1 度にプールごとに単一のマシンを更新します。これにより、移行にかかる合計時間がクラスターのサイズと共に増加します。

19.2.2. OVN-Kubernetes デフォルト CNI ネットワークプロバイダーへの移行

クラスター管理者は、クラスターのデフォルトの Container Network Interface (CNI) ネットワークプロバイダーを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。

重要

移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。

前提条件

  • ネットワークポリシーの分離モードで OpenShift SDN CNI クラスターネットワークプロバイダーで設定されたクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd データベースの最新のバックアップが利用可能である。
  • 再起動は、ノードごとに手動でトリガーできます。
  • クラスターは既知の正常な状態にあり、エラーがないこと。
  • ソフトウェア更新後のクラウドプラットフォームでは、すべてのノードに対してポート 6081 で UDP パケットを許可するセキュリティーグループルールを設定する必要があります。

手順

  1. クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
    Copy to Clipboard Toggle word wrap
  2. 移行のすべてのノードを準備するには、以下のコマンドを入力して Cluster Network Operator 設定オブジェクトに migration フィールドを設定します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": {"networkType": "OVNKubernetes" } } }'
    Copy to Clipboard Toggle word wrap
    注記

    この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、migration フィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。

  3. オプション: ネットワークインフラストラクチャーの要件を満たすように OVN-Kubernetes の以下の設定をカスタマイズできます。

    • Maximum transmission unit (MTU)
    • Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークポート

    以前の設定のいずれかをカスタマイズするには、以下のコマンドを入力してカスタマイズします。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>
        }}}}'
    Copy to Clipboard Toggle word wrap
    mtu
    Geneve オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 100 小さく設定する必要があります。
    port
    Geneve オーバーレイネットワークの UDP ポート。値が指定されない場合、デフォルトは 6081 になります。ポートは、OpenShift SDN で使用される VXLAN ポートと同じにすることはできません。VXLAN ポートのデフォルト値は 4789 です。

    mtu フィールドを更新するパッチコマンドの例

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'
    Copy to Clipboard Toggle word wrap

  4. MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    正常に更新されたノードには、UPDATED=trueUPDATING=falseDEGRADED=false のステータスがあります。

    注記

    デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。

  5. ホスト上の新規マシン設定のステータスを確認します。

    1. マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。

      $ oc describe node | egrep "hostname|machineconfig"
      Copy to Clipboard Toggle word wrap

      出力例

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done
      Copy to Clipboard Toggle word wrap

      以下のステートメントが true であることを確認します。

      • machineconfiguration.openshift.io/state フィールドの値は Done です。
      • machineconfiguration.openshift.io/currentConfig フィールドの値は、machineconfiguration.openshift.io/desiredConfig フィールドの値と等しくなります。
    2. マシン設定が正しいことを確認するには、以下のコマンドを入力します。

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart
      Copy to Clipboard Toggle word wrap

      <config_name>machineconfiguration.openshift.io/currentConfig フィールドのマシン設定の名前です。

      マシン設定には、systemd 設定に以下の更新を含める必要があります。

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
      Copy to Clipboard Toggle word wrap
    3. ノードが NotReady 状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。

      1. Pod をリスト表示するには、以下のコマンドを入力します。

        $ oc get pod -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        出力例

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h
        Copy to Clipboard Toggle word wrap

        設定デーモン Pod の名前は、machine-config-daemon-<seq> という形式になります。<seq> 値は、ランダムな 5 文字の英数字シーケンスになります。

      2. 以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。

        $ oc logs <pod> -n openshift-machine-config-operator
        Copy to Clipboard Toggle word wrap

        ここで、pod はマシン設定デーモン Pod の名前になります。

      3. 直前のコマンドの出力で示されるログ内のエラーを解決します。
  6. 移行を開始するには、以下のコマンドのいずれかを使用して、OVN-Kubernetes クラスターネットワークプロバイダーを設定します。

    • クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
      Copy to Clipboard Toggle word wrap
    • 別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'
      Copy to Clipboard Toggle word wrap

      ここで、cidr は CIDR ブロックであり、prefix はクラスター内の各ノードに割り当てられる CIDR ブロックのスライスです。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16 CIDR ブロックと重複する CIDR ブロックは使用できません。

      重要

      移行時に、サービスネットワークのアドレスブロックを変更することはできません。

  7. Multus デーモンセットのロールアウトが完了したことを確認してから、後続の手順を続行します。

    $ oc -n openshift-multus rollout status daemonset/multus
    Copy to Clipboard Toggle word wrap

    Multus Pod の名前の形式は multus-<xxxxx> です。ここで、 <xxxxx> は文字のランダムなシーケンスになります。Pod が再起動するまでにしばらく時間がかかる可能性があります。

    出力例

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out
    Copy to Clipboard Toggle word wrap

  8. 移行を完了するには、クラスター内の各ノードを再起動します。たとえば、以下のような bash スクリプトを使用できます。このスクリプトは、ssh を使用して各ホストに接続でき、sudo がパスワードを要求しないように設定されていることを前提としています。

    #!/bin/bash
    
    for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
    do
       echo "reboot node $ip"
       ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
    done
    Copy to Clipboard Toggle word wrap

    ssh アクセスが使用できない場合、インフラストラクチャープロバイダーの管理ポータルから各ノードを再起動できる場合があります。

  9. 移行が正常に完了したことを確認します。

    1. CNI ネットワークプロバイダーが OVN-Kubernetes であることを確認するには、以下のコマンドを入力します。status.networkType の値は OVNKubernetes である必要があります。

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
      Copy to Clipboard Toggle word wrap
    2. クラスターノードが Ready 状態にあることを確認するには、以下のコマンドを実行します。

      $ oc get nodes
      Copy to Clipboard Toggle word wrap
    3. Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
      Copy to Clipboard Toggle word wrap

      ノードの Pod がエラー状態にある場合は、そのノードを再起動します。

    4. すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。

      $ oc get co
      Copy to Clipboard Toggle word wrap

      すべてのクラスター Operator のステータスは、AVAILABLE="True"PROGRESSING="False"DEGRADED="False" になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。

  10. 以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。

    1. CNO 設定オブジェクトから移行設定を削除するには、以下のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
      Copy to Clipboard Toggle word wrap
    2. OpenShift SDN ネットワークプロバイダーのカスタム設定を削除するには、以下のコマンドを入力します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
      Copy to Clipboard Toggle word wrap
    3. OpenShift SDN ネットワークプロバイダー namespace を削除するには、以下のコマンドを入力します。

      $ oc delete namespace openshift-sdn
      Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat