24.6. OpenShift SDN ネットワークプラグインからの移行


クラスター管理者は、OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインに移行できます。

オフライン移行方法を使用して、OpenShift SDN ネットワークプラグインから OVN-Kubernetes プラグインに移行できます。オフライン移行方法は、ダウンタイムを含む手動プロセスです。

24.6.1. OVN-Kubernetes ネットワークプラグインへの移行

OVN-Kubernetes ネットワークプラグインへの移行は、クラスターに到達できないダウンタイムを含む手動プロセスです。

重要

OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。

ロールバック手順が提供されますが、移行は一方向プロセスとなることが意図されています。

OVN-Kubernetes ネットワークプラグインへの移行は、次のプラットフォームでサポートされています。

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

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

OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへの移行は、Nutanix ではサポートされていません。

24.6.1.1. OVN-Kubernetes ネットワークプラグインへの移行についての考慮点

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

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

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

  • クラスターが次の OpenShift SDN ネットワークプラグイン機能のいずれかを使用する場合、OVN-Kubernetes ネットワークプラグインで同じ機能を手動で設定する必要があります。

    • namespace の分離
    • Egress ルーター Pod
  • OVN-Kubernetes に移行する前に、IP アドレス範囲が 100. 64.0.0/16、169.254.169.0/29、100.88.0. 0/16、fd98::/64、fd69::/125、および fd97:: /64 が使用されていないことを確認してください。OVN-Kubernetes はこれらの範囲を内部で使用します。これらの範囲については、クラスターまたはインフラストラクチャーの他の CIDR 定義に含めないでください。
  • Precision Time Protocol (PTP)を持つ openshift-sdn クラスターがハードウェアタイムスタンプに UDP (User Datagram Protocol)を使用し、OVN-Kubernetes プラグインに移行する場合、ハードウェアのタイムスタンプは Open vSwitch (OVS)ブリッジなどのプライマリーインターフェイスデバイスに適用できません。そのため、UDP バージョン 4 の設定は、br-ex インターフェイスでは機能しません。

以下のセクションでは、OVN-Kubernetes と OpenShift SDN ネットワークプラグインの前述の機能の設定の違いを強調しています。

プライマリーネットワークインターフェイス

OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。

プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、OVN-Kubernetes を使用すると、Kubernetes NMState はこの設定を管理できません。代わりに、configure-ovs.sh シェルスクリプトがプライマリーインターフェイスと、このインターフェイスに接続されている設定を管理します。

namespace の分離

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

重要

マルチテナントモードまたはサブネット分離モードのいずれかで設定されている OpenShift SDN を使用するクラスターの場合でも、OVN-Kubernetes ネットワークプラグインに移行できます。移行操作後、マルチテナント分離モードは削除されるため、Pod とサービスに対して同じプロジェクトレベルの分離を実現するには、ネットワークポリシーを手動で設定する必要があることに注意してください。

Egress IP アドレス

OpenShift SDN は、2 つの異なる Egress IP モードをサポートしています。

  • 自動的に割り当てる 方法では、Egress IP アドレス範囲はノードに割り当てられます。
  • 手動で割り当てる 方法では、1 つ以上の Egress IP アドレスの一覧がノードに割り当てられます。

移行プロセスでは、自動割り当てモードを使用する Egress IP 設定の移行がサポートされています。

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

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

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

Egress ネットワークポリシー

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

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

EgressFirewall オブジェクトの名前は default にしか設定できないため、移行後は、OpenShift SDN での名前に関係なく、移行されたすべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。

その後、OpenShift SDN にロールバックすると、以前の名前が失われるため、すべての EgressNetworkPolicy オブジェクトに default という名前が付けられます。

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

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

ネットワークポリシー

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

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

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

Expand
表24.7 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 へのロールバックが必要な場合は、以下の表がプロセスを説明します。

重要

ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。

Expand
表24.8 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 台のマシンを更新するため、移行にかかる合計時間はクラスターのサイズに応じて増加します。

24.6.1.3. Ansible Playbook を使用した OVN-Kubernetes ネットワークプラグインへの移行

クラスター管理者は、Ansible コレクション network.offline_migration_sdn_to_ovnk を使用して、OpenShift SDN Container Network Interface (CNI)ネットワークプラグインからクラスターの OVN-Kubernetes プラグインに移行できます。Ansible コレクションには、次の Playbook が含まれています。

  • playbooks/playbook-migration.yml: 各 Playbook が移行プロセスのステップを表すシーケンスで実行される Playbook が含まれます。
  • playbooks/playbook-rollback.yml: 各 Playbook がロールバックプロセスのステップを表すシーケンスで実行される Playbook が含まれます。

前提条件

  • python3 パッケージ(最小バージョン 3.10)をインストールしている。
  • jmespath パッケージおよび jq パッケージをインストールしました。
  • Red Hat Hybrid Cloud Console にログインし、Ansible Automation Platform Web コンソールを開いている。
  • すべてのクラウドプラットフォーム上のすべてのノードに対してポート 6081 上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。このタスクを実行しないと、クラスターが Pod のスケジュールに失敗する可能性があります。
  • クラスターがホストネットワークで静的ルートまたはルーティングポリシーを使用しているかどうかを確認します。

    • true の場合、後の手順では、playbooks/playbook-migration.yml ファイルの gatewayConfig セクションで、routingViaHost パラメーターを true に設定し、ipForwarding パラメーターを Global に設定する必要があります。
  • OpenShift-SDN プラグインが 100 .64.0.0/16 および 100. 88.0.0/16 アドレス範囲を使用する場合は、アドレス範囲にパッチを適用します。詳細については、関連情報 セクションの OVN-Kubernetes アドレス範囲の修正を参照して ください。

手順

  1. ansible-core パッケージをインストールします(最小バージョン 2.15)。以下のコマンド例は、Red Hat Enterprise Linux (RHEL)に ansible-core パッケージをインストールする方法を示しています。

    $ sudo dnf install -y ansible-core
    Copy to Clipboard Toggle word wrap
  2. ansible.cfg ファイルを作成し、以下の例のような情報をファイルに追加します。ansible-galaxy コマンドおよび Playbook が実行されるのと同じディレクトリーにファイルが存在することを確認します。

    $ cat << EOF >> ansible.cfg
    [galaxy]
    server_list = automation_hub, validated
    
    [galaxy_server.automation_hub]
    url=https://console.redhat.com/api/automation-hub/content/published/
    auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
    token=
    
    #[galaxy_server.release_galaxy]
    #url=https://galaxy.ansible.com/
    
    [galaxy_server.validated]
    url=https://console.redhat.com/api/automation-hub/content/validated/
    auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
    token=
    EOF
    Copy to Clipboard Toggle word wrap
  3. Ansible Automation Platform Web コンソールから、Connect to Hub ページに移動し、次の手順を実行します。

    1. ページの Offline token セクションで、Load token ボタンをクリックします。
    2. トークンがロードされたら、Copy to clipboard アイコンをクリックします。
    3. ansible.cfg ファイルを開き、API トークンを token= パラメーターに貼り付けます。API トークンは、ansible.cfg ファイルで指定されたサーバー URL に対して認証するために必要です。
  4. 以下の ansible-galaxy コマンドを入力して、network.offline_migration_sdn_to_ovnk Ansible コレクションをインストールします。

    $ ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
    Copy to Clipboard Toggle word wrap
  5. network.offline_migration_sdn_to_ovnk Ansible コレクションがシステムにインストールされていることを確認します。

    $ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
    Copy to Clipboard Toggle word wrap

    出力例

    network.offline_migration_sdn_to_ovnk   1.0.2
    Copy to Clipboard Toggle word wrap

    network.offline_migration_sdn_to_ovnk Ansible コレクションは、~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/ のデフォルトパスに保存されます。

  6. playbooks/playbook-migration.yml ファイルで移行機能を設定します。

    # ...
        migration_interface_name: eth0
        migration_disable_auto_migration: true
        migration_egress_ip: false
        migration_egress_firewall: false
        migration_multicast: false
        migration_routing_via_host: true
        migration_ip_forwarding: Global
        migration_cidr: "10.240.0.0/14"
        migration_prefix: 23
        migration_mtu: 1400
        migration_geneve_port: 6081
        migration_ipv4_subnet: "100.64.0.0/16"
    # ...
    Copy to Clipboard Toggle word wrap
    migration_interface_name
    プライマリーインターフェイスで NodeNetworkConfigurationPolicy (NNCP)リソースを使用する場合は、移行プロセス中に NNCP リソースがプライマリーインターフェイスで削除されるように、migration-playbook.yml ファイルでインターフェイス名を指定します。
    migration_disable_auto_migration
    OVN-Kubernetes プラグインへの OpenShift SDN CNI プラグイン機能の自動移行を無効にします。機能の自動移行を無効にする場合は、migration_egress_ip パラメーター、migration_egress_firewall パラメーター、および migration_multicast パラメーターも false に設定する必要があります。機能の自動移行を有効にする必要がある場合は、パラメーターを false に設定します。
    migration_routing_via_host
    ローカルゲートウェイモードを設定するには true に設定し、クラスターのノードの共有ゲートウェイモードを設定するには false に設定します。デフォルト値は false です。ローカルゲートウェイモードでは、トラフィックはホストネットワークスタックを介してルーティングされます。共有ゲートウェイモードでは、トラフィックはホストネットワークスタック経由でルーティングされません。
    migration_ip_forwarding
    ローカルゲートウェイモードを設定している場合は、ノードのホストネットワークが OVN-Kubernetes に関係のないトラフィックのルーターとして機能する必要がある場合は、IP 転送を Global に設定します。
    migration_cidr
    クラスターの Classless Inter-Domain Routing (CIDR) IP アドレスブロックを指定します。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16 CIDR ブロックと重複する CIDR ブロックは使用できません。
    migration_prefix
    クラスター内の各ノードに割り当てられる CIDR ブロックのスライスである prefix 値を指定します。
    migration_mtu
    移行プロセス後にクラスターネットワークに特定の最大伝送単位(MTU)を設定するオプションのパラメーター。
    migration_geneve_port
    OVN-Kubernetes の Geneve ポートを設定するオプションのパラメーター。デフォルトのポートは 6081 です。
    migration_ipv4_subnet
    OVN-Kubernetes による内部使用の IPv4 アドレス範囲を設定するオプションのパラメーター。パラメーターのデフォルト値は 100.64.0.0/16 です
  7. playbooks/playbook-migration.yml ファイルを実行するには、以下のコマンドを入力します。

    $ ansible-playbook -v playbooks/playbook-migration.yml
    Copy to Clipboard Toggle word wrap

24.6.2. OVN-Kubernetes ネットワークプラグインへの移行

クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。

重要

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

前提条件

  • ネットワークポリシー分離モードの OpenShift SDN CNI ネットワークプラグインで設定されたクラスターがある。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd データベースの最新のバックアップがある。
  • 各ノードを手動で再起動できる。
  • クラスターがエラーのない既知の良好な状態にあることを確認している。
  • すべてのクラウドプラットフォーム上のすべてのノードに対してポート 6081 上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。
  • Webhook を削除しました。または、手順で説明する各 Webhook にタイムアウト値を設定できます。これらのタスクのいずれかを完了しなかった場合、クラスターは Pod のスケジュールに失敗する可能性があります。

手順

  1. Webhook を削除しなかった場合は、ValidatingWebhookConfiguration カスタムリソースを作成し、timeoutSeconds パラメーターのタイムアウト値を指定して、各 Webhook のタイムアウト値を 3 秒に設定します。

    oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \ 
    1
    
    -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'
    Copy to Clipboard Toggle word wrap
    1
    & lt;webhook_name& gt; は Webhook の名前です。
  2. クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドを実行して、OVN_SDN_MIGRATION_TIMEOUT 環境変数が設定され、0s になっていることを確認します。

    #!/bin/bash
    
    if [ -n "$OVN_SDN_MIGRATION_TIMEOUT" ] && [ "$OVN_SDN_MIGRATION_TIMEOUT" = "0s" ]; then
        unset OVN_SDN_MIGRATION_TIMEOUT
    fi
    
    #loops the timeout command of the script to repeatedly check the cluster Operators until all are available.
    
    co_timeout=${OVN_SDN_MIGRATION_TIMEOUT:-1200s}
    timeout "$co_timeout" bash <<EOT
    until
      oc wait co --all --for='condition=AVAILABLE=True' --timeout=10s && \
      oc wait co --all --for='condition=PROGRESSING=False' --timeout=10s && \
      oc wait co --all --for='condition=DEGRADED=False' --timeout=10s;
    do
      sleep 10
      echo "Some ClusterOperators Degraded=False,Progressing=True,or Available=False";
    done
    EOT
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
    --patch '{"spec":{"migration":null}}'
    Copy to Clipboard Toggle word wrap
  5. .以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) を削除します。

    1. 次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。

      $ oc get nncp
      Copy to Clipboard Toggle word wrap

      出力例

      NAME          STATUS      REASON
      bondmaster0   Available   SuccessfullyConfigured
      Copy to Clipboard Toggle word wrap

      Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを /etc/NetworkManager/system-connections システムパスに保存します。

    2. クラスターから NNCP を削除します。

      $ oc delete nncp <nncp_manifest_filename>
      Copy to Clipboard Toggle word wrap
  6. すべてのノードを移行用に準備するには、次のコマンドを実行して、CNO 設定オブジェクトの 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) がトリガーされます。

    1. 次のコマンドを実行して、再起動が完了したことを確認します。

      $ oc get mcp
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、すべてのクラスター Operator が利用可能であることを確認します。

      $ oc get co
      Copy to Clipboard Toggle word wrap
    3. あるいは、いくつかの OpenShift SDN 機能の OVN-Kubernetes 同等機能への自動移行を無効にすることができます。

      • Egress IP
      • Egress ファイアウォール
      • マルチキャスト

      前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{
          "spec": {
            "migration": {
              "networkType": "OVNKubernetes",
              "features": {
                "egressIP": <bool>,
                "egressFirewall": <bool>,
                "multicast": <bool>
              }
            }
          }
        }'
      Copy to Clipboard Toggle word wrap

      ここでは、以下のようになります。

      bool: 機能の移行を有効にするかどうかを指定します。デフォルトは true です。

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

    • 最大伝送単位 (MTU)。このオプションの手順で MTU をカスタマイズする前に、以下を考慮してください。

      • デフォルトの MTU を使用しており、移行中にデフォルトの MTU を維持したい場合は、この手順を無視できます。
      • カスタム MTU を使用しており、移行中にカスタム MTU を維持する必要がある場合は、この手順でカスタム MTU 値を宣言する必要があります。
      • 移行中に MTU 値を変更する場合、この手順は機能しません。代わりに、まず「クラスター MTU の変更」に記載された指示に従う必要があります。その後、この手順を実行してカスタム MTU 値を宣言すると、カスタム MTU 値を維持できます。

        注記

        OpenShift-SDN と OVN-Kubernetes のオーバーレイオーバーヘッドは異なります。MTU 値は、「MTU 値の選択」ページにあるガイドラインに従って選択する必要があります。

    • Geneve (Generic Network Virtualization Encapsulation) オーバーレイネットワークポート
    • OVN-Kubernetes IPv4 内部サブネット

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

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>,
              "v4InternalSubnet":"<ipv4_subnet>"
        }}}}'
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    mtu
    Geneve オーバーレイネットワークの MTU。この値は通常は自動的に設定されますが、クラスターにあるノードすべてが同じ MTU を使用しない場合、これを最小のノード MTU 値よりも 100 小さく設定する必要があります。
    port
    Geneve オーバーレイネットワークの UDP ポート。値が指定されない場合、デフォルトは 6081 になります。ポートは、OpenShift SDN で使用される VXLAN ポートと同じにすることはできません。VXLAN ポートのデフォルト値は 4789 です。
    ipv4_subnet
    OVN-Kubernetes による内部使用のための IPv4 アドレス範囲。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は 100.64.0.0/16 です。

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

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

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

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

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

    注記

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

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

    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. 直前のコマンドの出力で示されるログ内のエラーを解決します。
  10. 移行を開始するには、次のいずれかのコマンドを使用して 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 ブロックは使用できません。

      重要

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

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

  12. ネットワークプラグインの変更を完了するには、クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。

    重要

    次のスクリプトは、クラスター内のすべてのノードを同時に再起動します。これにより、クラスターが不安定になる可能性があります。もう 1 つのオプションとして、ノードを一度に 1 つずつ手動でリブートすることもできます。ノードを 1 つずつ再起動すると、多数のノードを持つクラスターではかなりのダウンタイムが発生します。

    ノードを再起動するまで、クラスター Operator は正しく動作しません。

    • oc rsh コマンドでは、次のような bash スクリプトを使用できます。

      #!/bin/bash
      readarray -t POD_NODES <<< "$(oc get pod -n openshift-machine-config-operator -o wide| grep daemon|awk '{print $1" "$7}')"
      
      for i in "${POD_NODES[@]}"
      do
        read -r POD NODE <<< "$i"
        until oc rsh -n openshift-machine-config-operator "$POD" chroot /rootfs shutdown -r +1
          do
            echo "cannot reboot node $NODE, retry" && sleep 3
          done
      done
      Copy to Clipboard Toggle word wrap
    • ssh コマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように 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
  13. 移行が正常に完了したことを確認します。

    1. ネットワークプラグインが 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 のログで詳細を確認します。

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

    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

次のステップ

  • オプション:クラスターの移行後に、IPv4 のシングルスタッククラスターを、IPv4 および IPv6 アドレスファミリーをサポートするデュアルネットワーククラスターネットワークに変換できます。詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換を参照してください。

24.6.4. OVN-Kubernetes での外部 IP の動作の変更について

OpenShift SDN から OVN-Kubernetes (OVN-K)に移行する場合、ネットワークポリシーの適用により、外部 IP を使用するサービスは namespace 全体でアクセスできなくなる可能性があります。

OpenShift SDN では、デフォルトで外部 IP が namespace をまたいでアクセス可能でした。しかし、OVN-K ではネットワークポリシーによってマルチテナント分離が厳密に適用され、他の namespace からの外部 IP 経由で公開されるサービスにアクセスできません。

アクセス権を確保するには、次の方法を検討してください。

  • Ingress またはルートを使用する: 外部 IP を使用してサービスを公開する代わりに、セキュリティー制御を維持しながら外部アクセスを許可するように Ingress またはルートを設定します。
  • NetworkPolicy カスタムリソース(CR)の調整: NetworkPolicy CR を変更して、必要な namespace からのアクセスを明示的に許可し、トラフィックが指定されたサービスポートに対して許可されていることを確認します。必要なポートへのトラフィックを明示的に許可しないと、namespace が許可されている場合でもアクセスがブロックされる可能性があります。
  • LoadBalancer サービスを使用する: 該当する場合は、外部 IP に依存する代わりに LoadBalancer サービスをデプロイします。設定の詳細は、OVN-Kubernetes での NetworkPolicy と外部 IP を参照してください。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat