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
0/16、/16、169.254.169.0/29、100
.88
.0.fd98::/64、fd
が使用されていないことを確認してください。OVN-Kubernetes はこれらの範囲を内部で使用します。これらの範囲については、クラスターまたはインフラストラクチャーの他の CIDR 定義に含めないでください。69::/125、および
/64fd97
:: -
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 アドレスを設定する際の相違点は、以下の表で説明されています。
OVN-Kubernetes | OpenShift SDN |
---|---|
|
|
OVN-Kubernetes で Egress IP アドレスを使用する方法の詳細は、「Egress IP アドレスの設定」を参照してください。
Egress ネットワークポリシー
OVN-Kubernetes と OpenShift SDN との間に Egress ファイアウォールとしても知られる Egress ネットワークポリシーの設定に関する相違点は、以下の表に記載されています。
OVN-Kubernetes | OpenShift SDN |
---|---|
|
|
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 でマルチキャストトラフィックを有効にする方法の相違点は、以下の表で説明されています。
OVN-Kubernetes | OpenShift SDN |
---|---|
|
|
OVN-Kubernetes でのマルチキャストの使用に関する詳細は、「プロジェクトのマルチキャストの有効化」を参照してください。
ネットワークポリシー
OVN-Kubernetes は、networking.k8s.io/v1
API グループで Kubernetes NetworkPolicy
API を完全にサポートします。OpenShift SDN から移行する際に、ネットワークポリシーで変更を加える必要はありません。
24.6.1.2. 移行プロセスの仕組み リンクのコピーリンクがクリップボードにコピーされました!
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
ユーザーが開始する手順 | 移行アクティビティー |
---|---|
|
|
|
|
クラスターの各ノードを再起動します。 |
|
OpenShift SDN へのロールバックが必要な場合は、以下の表がプロセスを説明します。
ロールバックを開始する前に、OpenShift SDN から OVN-Kubernetes ネットワークプラグインへの移行プロセスが成功するまで待つ必要があります。
ユーザーが開始する手順 | 移行アクティビティー |
---|---|
MCO を一時停止し、移行が中断されないようにします。 | MCO が停止します。 |
|
|
|
|
クラスターの各ノードを再起動します。 |
|
クラスターのすべてのノードが再起動した後に MCO を有効にします。 |
|
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
に設定する必要があります。
-
true の場合、後の手順では、
-
OpenShift-SDN プラグインが 100
.64.0.0/16 および
アドレス範囲を使用する場合は、アドレス範囲にパッチを適用します。詳細については、関連情報 セクションの OVN-Kubernetes アドレス範囲の修正を参照して ください。100.
88.0.0/16
手順
ansible-core
パッケージをインストールします(最小バージョン 2.15)。以下のコマンド例は、Red Hat Enterprise Linux (RHEL)にansible-core
パッケージをインストールする方法を示しています。sudo dnf install -y ansible-core
$ sudo dnf install -y ansible-core
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ansible.cfg
ファイルを作成し、以下の例のような情報をファイルに追加します。ansible-galaxy
コマンドおよび Playbook が実行されるのと同じディレクトリーにファイルが存在することを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ansible Automation Platform Web コンソールから、Connect to Hub ページに移動し、次の手順を実行します。
- ページの Offline token セクションで、Load token ボタンをクリックします。
- トークンがロードされたら、Copy to clipboard アイコンをクリックします。
-
ansible.cfg
ファイルを開き、API トークンをtoken=
パラメーターに貼り付けます。API トークンは、ansible.cfg
ファイルで指定されたサーバー URL に対して認証するために必要です。
以下の
ansible-galaxy
コマンドを入力して、network.offline_migration_sdn_to_ovnk
Ansible コレクションをインストールします。ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection install network.offline_migration_sdn_to_ovnk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnk
Ansible コレクションがシステムにインストールされていることを確認します。ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
$ ansible-galaxy collection list | grep network.offline_migration_sdn_to_ovnk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
network.offline_migration_sdn_to_ovnk 1.0.2
network.offline_migration_sdn_to_ovnk 1.0.2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow network.offline_migration_sdn_to_ovnk
Ansible コレクションは、~/.ansible/collections/ansible_collections/network/offline_migration_sdn_to_ovnk/
のデフォルトパスに保存されます。playbooks/playbook-migration.yml
ファイルで移行機能を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 です
。
playbooks/playbook-migration.yml
ファイルを実行するには、以下のコマンドを入力します。ansible-playbook -v playbooks/playbook-migration.yml
$ ansible-playbook -v playbooks/playbook-migration.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
24.6.2. OVN-Kubernetes ネットワークプラグインへの移行 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。
移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。
前提条件
- ネットワークポリシー分離モードの OpenShift SDN CNI ネットワークプラグインで設定されたクラスターがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップがある。
- 各ノードを手動で再起動できる。
- クラスターがエラーのない既知の良好な状態にあることを確認している。
-
すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081
上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。 - Webhook を削除しました。または、手順で説明する各 Webhook にタイムアウト値を設定できます。これらのタスクのいずれかを完了しなかった場合、クラスターは Pod のスケジュールに失敗する可能性があります。
手順
Webhook を削除しなかった場合は、
ValidatingWebhookConfiguration
カスタムリソースを作成し、timeoutSeconds
パラメーターのタイムアウト値を指定して、各 Webhook のタイムアウト値を3
秒に設定します。oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \ -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'
oc patch ValidatingWebhookConfiguration <webhook_name> --type='json' \
1 -p '[{"op": "replace", "path": "/webhooks/0/timeoutSeconds", "value": 3}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;webhook_name&
gt; は Webhook の名前です。
クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。
oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
$ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
OVN_SDN_MIGRATION_TIMEOUT
環境変数が設定され、0s
になっていることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow .以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する
NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) を削除します。次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。
oc get nncp
$ oc get nncp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを
/etc/NetworkManager/system-connections
システムパスに保存します。クラスターから NNCP を削除します。
oc delete nncp <nncp_manifest_filename>
$ oc delete nncp <nncp_manifest_filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべてのノードを移行用に準備するには、次のコマンドを実行して、CNO 設定オブジェクトの
migration
フィールドを設定します。oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、
migration
フィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。次のコマンドを実行して、再起動が完了したことを確認します。
oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、すべてのクラスター Operator が利用可能であることを確認します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、いくつかの OpenShift SDN 機能の OVN-Kubernetes 同等機能への自動移行を無効にすることができます。
- Egress IP
- Egress ファイアウォール
- マルチキャスト
前述の OpenShift SDN 機能の設定の自動移行を無効にするには、次のキーを指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
bool
: 機能の移行を有効にするかどうかを指定します。デフォルトはtrue
です。
オプション: ネットワークインフラストラクチャーの要件を満たすように 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 内部サブネット
以前の設定のいずれかをカスタマイズするには、以下のコマンドを入力してカスタマイズします。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
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
フィールドを更新するパッチコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。注記デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
oc describe node | egrep "hostname|machineconfig"
$ oc describe node | egrep "hostname|machineconfig"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 Copied! Toggle word wrap Toggle overflow 以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/state
フィールドの値はDone
です。 -
machineconfiguration.openshift.io/currentConfig
フィールドの値は、machineconfiguration.openshift.io/desiredConfig
フィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
oc get machineconfig <config_name> -o yaml | grep ExecStart
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<config_name>
はmachineconfiguration.openshift.io/currentConfig
フィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含める必要があります。
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードが
NotReady
状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。Pod をリスト表示するには、以下のコマンドを入力します。
oc get pod -n openshift-machine-config-operator
$ oc get pod -n openshift-machine-config-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定デーモン Pod の名前は以下の形式になります。
machine-config-daemon-<seq>
<seq>
値は、ランダムな 5 文字の英数字シーケンスになります。以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。
oc logs <pod> -n openshift-machine-config-operator
$ oc logs <pod> -n openshift-machine-config-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
pod
はマシン設定デーモン Pod の名前になります。- 直前のコマンドの出力で示されるログ内のエラーを解決します。
移行を開始するには、次のいずれかのコマンドを使用して OVN-Kubernetes ネットワークプラグインを設定します。
クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。
oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
$ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
cidr
は CIDR ブロックであり、prefix
はクラスター内の各ノードに割り当てられる CIDR ブロックのスライスです。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16
CIDR ブロックと重複する CIDR ブロックは使用できません。重要移行時に、サービスネットワークのアドレスブロックを変更することはできません。
Multus デーモンセットのロールアウトが完了したことを確認してから、後続の手順を続行します。
oc -n openshift-multus rollout status daemonset/multus
$ oc -n openshift-multus rollout status daemonset/multus
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 Copied! Toggle word wrap Toggle overflow ネットワークプラグインの変更を完了するには、クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。
重要次のスクリプトは、クラスター内のすべてのノードを同時に再起動します。これにより、クラスターが不安定になる可能性があります。もう 1 つのオプションとして、ノードを一度に 1 つずつ手動でリブートすることもできます。ノードを 1 つずつ再起動すると、多数のノードを持つクラスターではかなりのダウンタイムが発生します。
ノードを再起動するまで、クラスター Operator は正しく動作しません。
oc rsh
コマンドでは、次のような bash スクリプトを使用できます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ssh
コマンドでは、次のような bash スクリプトを使用できます。このスクリプトは、パスワードの入力を求めないように sudo が設定されていることを前提としています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
移行が正常に完了したことを確認します。
ネットワークプラグインが OVN-Kubernetes であることを確認するには、次のコマンドを入力します。
status.networkType
の値はOVNKubernetes
である必要があります。oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
$ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターノードが
Ready
状態にあることを確認するには、以下のコマンドを実行します。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。
oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードの Pod がエラー状態にある場合は、そのノードを再起動します。
すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのクラスター Operator のステータスは、
AVAILABLE="True"
、PROGRESSING="False"
、DEGRADED="False"
になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。
以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。
CNO 設定オブジェクトから移行設定を削除するには、以下のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift SDN ネットワークプロバイダーのカスタム設定を削除するには、以下のコマンドを入力します。
oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift SDN ネットワークプロバイダー namespace を削除するには、以下のコマンドを入力します。
oc delete namespace openshift-sdn
$ oc delete namespace openshift-sdn
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- オプション:クラスターの移行後に、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 を参照してください。