20.5. OpenShift SDN ネットワークプラグインからの移行
クラスター管理者は、オフライン の移行方法または制限付きライブマイグレーション方法を使用して、OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインに移行できます。
OpenShift SDN ネットワークプラグインを使用している場合、クラスターを OpenShift Container Platform 4.17 にアップグレードすることはできません。OpenShift Container Platform 4.17 にアップグレードする前に、OVN-Kubernetes プラグインに移行する必要があります。
OVN-Kubernetes の詳細は、OVN-Kubernetes ネットワークプラグインについて を参照してください。
スクリプトや Red Hat Ansible Automation Platform などの別のツールを使用して、OpenShift SDN から OVN-Kubernetes への移行を自動化しないでください。これにより、OpenShift Container Platform クラスターが停止したりクラッシュしたりする可能性があります。
20.5.1. OVN-Kubernetes ネットワークプラグインへのオフライン移行の概要
オフライン移行方法は手動のプロセスであり、ダウンタイムが発生し、その間はクラスターにアクセスできなくなります。この方法は主に、セルフマネージド OpenShift Container Platform デプロイメントに使用されます。
OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。
ロールバック手順は提供されていますが、オフライン移行は一方向のプロセスとなる想定です。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
次のセクションでは、オフライン移行方法についてさらに詳しく説明します。
20.5.1.1. オフライン移行方法を使用する場合にサポートされるプラットフォーム
次の表は、オフライン移行タイプでサポートされているプラットフォームに関する情報を示しています。
プラットフォーム | オフライン移行 |
---|---|
ベアメタルハードウェア | ✓ |
Amazon Web Services (AWS) | ✓ |
Google Cloud Platform (GCP) | ✓ |
IBM Cloud® | ✓ |
Microsoft Azure | ✓ |
Red Hat OpenStack Platform (RHOSP) | ✓ |
VMware vSphere | ✓ |
Nutanix | ✓ |
リストされている各プラットフォームは、installer-provisioned infrastructure および user-provisioned infrastructure への OpenShift Container Platform クラスターのインストールをサポートしています。
20.5.1.2. OVN-Kubernetes ネットワークプラグインへのオフライン移行のベストプラクティス
オフライン移行方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Best practices for OpenShift SDN to OVN Kubernetes CNI Offline migration を参照してください。
20.5.1.3. 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
::
以下のセクションでは、OVN-Kubernetes と OpenShift SDN ネットワークプラグインの前述の機能の設定の違いを強調しています。
プライマリーネットワークインターフェイス
OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。
プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、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 から移行する際に、ネットワークポリシーで変更を加える必要はありません。
20.5.1.4. オフライン移行プロセスの仕組み
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
ユーザーが開始する手順 | 移行アクティビティー |
---|---|
|
|
|
|
クラスターの各ノードを再起動します。 |
|
20.5.1.5. オフライン移行方法を使用して OVN-Kubernetes ネットワークプラグインに移行する
クラスター管理者は、クラスターのネットワークプラグインを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。
移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。
前提条件
- ネットワークポリシー分離モードの OpenShift SDN CNI ネットワークプラグインで設定されたクラスターがある。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップがある。
- 各ノードを手動で再起動できる。
- クラスターがエラーのない既知の良好な状態にあることを確認している。
-
すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081
上の User Datagram Protocol (UDP) パケットを許可するセキュリティーグループルールを作成している。 -
Webhook のすべてのタイムアウトを
3
秒に設定しているか、Webhook を削除している。
手順
クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。
$ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
次のコマンドを実行して、
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
次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する
NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) を削除します。次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。
$ oc get nncp
出力例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを
/etc/NetworkManager/system-connections
システムパスに保存します。クラスターから NNCP を削除します。
$ oc delete nncp <nncp_manifest_filename>
すべてのノードを移行用に準備するには、次のコマンドを実行して、CNO 設定オブジェクトの
migration
フィールドを設定します。$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": { "networkType": "OVNKubernetes" } } }'
注記この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、
migration
フィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。次のコマンドを実行して、再起動が完了したことを確認します。
$ oc get mcp
次のコマンドを実行して、すべてのクラスター Operator が利用可能であることを確認します。
$ oc get co
あるいは、いくつかの 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> } } } }'
ここでは、以下のようになります。
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 内部サブネット
- OVN-Kubernetes IPv6 内部サブネット
以前の設定のいずれかをカスタマイズするには、以下のコマンドを入力してカスタマイズします。デフォルト値を変更する必要がない場合は、パッチのキーを省略します。
$ oc patch Network.operator.openshift.io cluster --type=merge \ --patch '{ "spec":{ "defaultNetwork":{ "ovnKubernetesConfig":{ "mtu":<mtu>, "genevePort":<port>, "v4InternalSubnet":"<ipv4_subnet>", "v6InternalSubnet":"<ipv6_subnet>" }}}}'
ここでは、以下のようになります。
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
です。 ipv6_subnet
-
OVN-Kubernetes による内部使用のための IPv6 アドレス範囲。IP アドレス範囲が、OpenShift Container Platform インストールで使用される他のサブネットと重複しないようにする必要があります。IP アドレス範囲は、クラスターに追加できるノードの最大数より大きくする必要があります。デフォルト値は
fd98::/48
です。
mtu
フィールドを更新するパッチコマンドの例$ oc patch Network.operator.openshift.io cluster --type=merge \ --patch '{ "spec":{ "defaultNetwork":{ "ovnKubernetesConfig":{ "mtu":1200 }}}}'
MCO がそれぞれのマシン設定プールのマシンを更新すると、各ノードが 1 つずつ再起動します。すべてのノードが更新されるまで待機する必要があります。以下のコマンドを実行してマシン設定プールのステータスを確認します。
$ oc get mcp
正常に更新されたノードには、
UPDATED=true
、UPDATING=false
、DEGRADED=false
のステータスがあります。注記デフォルトで、MCO はプールごとに一度に 1 つのマシンを更新するため、移行にかかる合計時間がクラスターのサイズと共に増加します。
ホスト上の新規マシン設定のステータスを確認します。
マシン設定の状態と適用されたマシン設定の名前をリスト表示するには、以下のコマンドを入力します。
$ oc describe node | egrep "hostname|machineconfig"
出力例
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
以下のステートメントが true であることを確認します。
-
machineconfiguration.openshift.io/state
フィールドの値はDone
です。 -
machineconfiguration.openshift.io/currentConfig
フィールドの値は、machineconfiguration.openshift.io/desiredConfig
フィールドの値と等しくなります。
-
マシン設定が正しいことを確認するには、以下のコマンドを入力します。
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
ここで、
<config_name>
はmachineconfiguration.openshift.io/currentConfig
フィールドのマシン設定の名前になります。マシン設定には、systemd 設定に以下の更新を含めることができます。
ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
ノードが
NotReady
状態のままになっている場合、マシン設定デーモン Pod のログを調べ、エラーを解決します。Pod をリスト表示するには、以下のコマンドを入力します。
$ oc get pod -n openshift-machine-config-operator
出力例
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
設定デーモン Pod の名前は以下の形式になります。
machine-config-daemon-<seq>
<seq>
値は、ランダムな 5 文字の英数字シーケンスになります。以下のコマンドを入力して、直前の出力に表示される最初のマシン設定デーモン Pod の Pod ログを表示します。
$ oc logs <pod> -n openshift-machine-config-operator
ここで、
pod
はマシン設定デーモン Pod の名前になります。- 直前のコマンドの出力で示されるログ内のエラーを解決します。
移行を開始するには、次のいずれかのコマンドを使用して OVN-Kubernetes ネットワークプラグインを設定します。
クラスターネットワークの IP アドレスブロックを変更せずにネットワークプロバイダーを指定するには、以下のコマンドを入力します。
$ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
別のクラスターネットワーク IP アドレスブロックを指定するには、以下のコマンドを入力します。
$ oc patch Network.config.openshift.io cluster \ --type='merge' --patch '{ "spec": { "clusterNetwork": [ { "cidr": "<cidr>", "hostPrefix": <prefix> } ], "networkType": "OVNKubernetes" } }'
ここで、
cidr
は CIDR ブロックであり、prefix
はクラスター内の各ノードに割り当てられる CIDR ブロックのスライスです。OVN-Kubernetes ネットワークプロバイダーはこのブロックを内部で使用するため、100.64.0.0/16
CIDR ブロックと重複する CIDR ブロックは使用できません。重要移行時に、サービスネットワークのアドレスブロックを変更することはできません。
Multus デーモンセットのロールアウトが完了したことを確認してから、後続の手順を続行します。
$ oc -n openshift-multus rollout status daemonset/multus
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
ネットワークプラグインの変更を完了するには、クラスター内の各ノードを再起動します。次のいずれかの方法で、クラスター内のノードを再起動できます。
重要次のスクリプトは、クラスター内のすべてのノードを同時に再起動します。これにより、クラスターが不安定になる可能性があります。もう 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
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
移行が正常に完了したことを確認します。
ネットワークプラグインが OVN-Kubernetes であることを確認するには、次のコマンドを入力します。
status.networkType
の値はOVNKubernetes
である必要があります。$ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
クラスターノードが
Ready
状態にあることを確認するには、以下のコマンドを実行します。$ oc get nodes
Pod がエラー状態ではないことを確認するには、以下のコマンドを入力します。
$ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'
ノードの Pod がエラー状態にある場合は、そのノードを再起動します。
すべてのクラスター Operator が異常な状態にないことを確認するには、以下のコマンドを入力します。
$ oc get co
すべてのクラスター Operator のステータスは、
AVAILABLE="True"
、PROGRESSING="False"
、DEGRADED="False"
になります。クラスター Operator が利用できないか、そのパフォーマンスが低下する場合には、クラスター Operator のログで詳細を確認します。
以下の手順は、移行に成功し、クラスターの状態が正常である場合にのみ実行します。
CNO 設定オブジェクトから移行設定を削除するには、以下のコマンドを入力します。
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": null } }'
OpenShift SDN ネットワークプロバイダーのカスタム設定を削除するには、以下のコマンドを入力します。
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
OpenShift SDN ネットワークプロバイダー namespace を削除するには、以下のコマンドを入力します。
$ oc delete namespace openshift-sdn
20.5.2. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションの概要
限定的なライブマイグレーション方式は、OpenShift SDN ネットワークプラグインとそのネットワーク設定、接続、および関連リソースを、サービスを中断することなく OVN-Kubernetes ネットワークプラグインに移行するプロセスです。OpenShift Container Platform で利用できます。
OpenShift Container Platform クラスターを移行して OVN-Kubernetes ネットワークプラグインを使用する前に、最新のバグ修正がすべてクラスターに適用されるように、クラスターを最新の z-stream リリースに更新してください。
Hosted Control Plane デプロイメントタイプでは使用できません。この移行方式は、継続的なサービス可用性を必要とするデプロイメントタイプにとって有用で、以下のような利点があります。
- 継続的なサービスの可用性
- ダウンタイムの最小化
- 自動ノード再起動
- OpenShift SDN ネットワークプラグインから OVN-Kubernetes ネットワークプラグインへのシームレスな移行
ロールバック手順は提供されていますが、限定的なライブマイグレーションは一方向のプロセスとなる想定です。
OpenShift SDN CNI は、OpenShift Container Platform 4.14 以降非推奨になりました。OpenShift Container Platform 4.15 以降の新規インストールでは、ネットワークプラグインというオプションはなくなりました。今後のリリースでは、OpenShift SDN ネットワークプラグインは削除され、サポートされなくなる予定です。Red Hat は、この機能が削除されるまでバグ修正とサポートを提供しますが、この機能は拡張されなくなります。OpenShift SDN CNI の代わりに、OVN Kubernetes CNI を使用できます。詳細は、OpenShift SDN CNI の削除 を参照してください。
次のセクションでは、限定的なライブマイグレーションの方法についてさらに詳しく説明します。
20.5.2.1. 限定的なライブマイグレーション方式を使用する場合にサポートされるプラットフォーム
次の表は、制限付きライブマイグレーションタイプでサポートされているプラットフォームに関する情報を示しています。
プラットフォーム | 限定的なライブマイグレーション |
---|---|
ベアメタルハードウェア | ✓ |
Amazon Web Services (AWS) | ✓ |
Google Cloud Platform (GCP) | ✓ |
IBM Cloud® | ✓ |
Microsoft Azure | ✓ |
Red Hat OpenStack Platform (RHOSP) | ✓ |
VMware vSphere | ✓ |
Nutanix | ✓ |
リストされている各プラットフォームは、installer-provisioned infrastructure および user-provisioned infrastructure への OpenShift Container Platform クラスターのインストールをサポートしています。
20.5.2.2. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションのベストプラクティス
限定的なライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する場合のベストプラクティスのリストについては、Limited Live Migration from OpenShift SDN to OVN-Kubernetes を参照してください。
20.5.2.3. OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項
OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションメソッドを使用する前に、クラスター管理者は次の情報を考慮する必要があります。
- OpenShift SDN マルチテナントモードが有効になっているクラスターでは、制限付きライブマイグレーション手順はサポートされません。
- Egress ルーター Pod は、制限されたライブマイグレーションプロセスをブロックします。制限付きライブマイグレーションのプロセスを開始する前に、それらを削除する必要があります。
- 移行時に、クラスターが OVN-Kubernetes と OpenShift SDN の両方で実行されている場合、マルチキャストおよび egress IP アドレスは両方の CNI について一時的に無効になります。Egress ファイアウォールは引き続き機能します。
- 移行は一方向のプロセスとして行われます。ただし、OpenShift-SDN にロールバックするユーザーの場合、OpenShift-SDN から OVN-Kubernetes への移行が成功している必要があります。以下の同じ手順に従って、OVN-Kubernetes ネットワークプラグインから OpenShift SDN ネットワークプラグインに移行できます。
- 制限付きライブマイグレーションは、HyperShift クラスターではサポートされていません。
- OpenShift SDN は IPsec をサポートしません。移行後、クラスター管理者は IPsec を有効にできます。
- OpenShift SDN は IPv6 をサポートしていません。移行後、クラスター管理者はデュアルスタックを有効にできます。
-
OpenShift SDN プラグインを使用すると、
NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。 クラスター MTU は、Pod インターフェイスの MTU 値です。クラスターネットワークオーバーレイのオーバーヘッドを考慮して、常にハードウェア MTU よりも小さくなります。オーバーヘッドは、OVN-Kubernetes の場合は 100 バイト、OpenShift SDN の場合は 50 バイトです。
制限付きライブマイグレーション中は、OVN-Kubernetes と OpenShift SDN の両方が並行して実行されます。OVN-Kubernetes は一部のノードのクラスターネットワークを管理し、OpenShift SDN は他のノードのクラスターネットワークを管理します。CNI 間のトラフィックが機能し続けるように、Cluster Network Operator はルーティング可能な MTU を更新し、両方の CNI が同じオーバーレイ MTU を共有するようにします。その結果、移行が完了すると、クラスター MTU は 50 バイト少なくなります。
OVN-Kubernetes の一部のパラメーターは、インストール後に変更できません。次のパラメーターを設定できるのは、制限付きライブマイグレーションを開始する前のみです。
-
InternalTransitSwitchSubnet
-
internalJoinSubnet
-
-
OVN-Kubernetes は、
100.64.0.0/16
および100.88.0.0/16
の IP アドレス範囲を予約します。これらのサブネットは、他の内部ネットワークまたは外部ネットワークと重複することはできません。これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。 - ほとんどの場合、制限付きライブマイグレーションは、Multus CNI プラグインによって作成された Pod のセカンダリーインターフェイスとは無関係です。ただし、これらのセカンダリーインターフェイスがホストのデフォルトのネットワークインターフェイスコントローラー (NIC) 上に設定されている場合 (たとえば、MACVLAN、IPVLAN、SR-IOV、またはブリッジインターフェイスを使用し、デフォルトの NIC を制御ノードとして使用する場合)、OVN-Kubernetes で誤動作が発生する可能性があります。限られたライブマイグレーションに進む前に、このような設定を削除する必要があります。
- ホスト内に複数の NIC があり、デフォルトルートが Kubernetes NodeIP を持つインターフェイス上にない場合は、代わりにオフライン移行を使用する必要があります。
-
制限付きライブマイグレーションを開始する前に、Cluster Network Operator (CNO) によって管理されていない
openshift-sdn
namespace 内のすべてのDaemonSet
オブジェクトを削除する必要があります。これらの管理されていないデーモンセットが適切に処理されない場合は、移行ステータスが不完全なままになる可能性があります。 -
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。
PodDisruptionBudget で minAvailable
が 1 に設定されている場合、削除
プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget
フィールドはノードのドレインを防ぐことができます。
20.5.2.4. 限定的なライブマイグレーションプロセスの仕組み
次の表は、限定的なライブマイグレーションプロセスをまとめたものです。プロセス内のユーザーが開始する手順と、それに対して移行スクリプトが実行するアクションに分かれています。
ユーザーが開始する手順 | 移行アクティビティー |
---|---|
|
|
20.5.2.5. 制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行する
制限付きライブマイグレーション方式を使用して OVN-Kubernetes ネットワークプラグインに移行するには、複数のステップから成るプロセスが必要であり、ユーザーは Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace の動作を確認する必要があります。管理者は、限定的なライブマイグレーションプロセスを開始する前に、デプロイメント内のネットワークポリシーを確認し、Egress ルーターリソースを削除する必要があります。以下の手順を連続して実行する必要があります。
20.5.2.5.1. 限定的なライブマイグレーションを開始する前にクラスターリソースを確認する
制限付きライブマイグレーションを使用して OVN-Kubernetes に移行する前に、OpenShift SDN デプロイメントで Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認する必要があります。また、デプロイメント内のネットワークポリシーも確認する必要があります。移行前にクラスターにこれらのリソースがあることがわかった場合は、移行後にそれらの動作をチェックして、意図したとおりに動作していることを確認する必要があります。
次の手順では、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、ネットワークポリシー、および NNCP を確認する方法を示します。これらのリソースを確認した後は、何もする必要はありません。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、
oc
CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。oc
CLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。
$ oc get egressnetworkpolicies.network.openshift.io -A
出力例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
-o yaml
フラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。$ oc get egressnetworkpolicy <example_egressfirewall> -n <namespace> -o yaml
出力例
apiVersion: network.openshift.io/v1 kind: EgressNetworkPolicy metadata: name: <example_egress_policy> namespace: <namespace> spec: egress: - type: Allow to: cidrSelector: 0.0.0.0/0 - type: Deny to: cidrSelector: 10.0.0.0/8
OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに
sdn_controller_num_egress_firewalls
と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
-
OpenShift Container Platform Web コンソールで、Observe
クラスターの Egress IP リソースを確認します。これは、
oc
CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。oc
CLI ツールを使用して Egress IP を確認するには、以下を行います。Egress IP リソースを持つ namespace をリスト表示するには、次のコマンドを入力します。
$ oc get netnamespace -A | awk '$3 != ""'
出力例
NAME NETID EGRESS IPS namespace1 14173093 ["10.0.158.173"] namespace2 14173020 ["10.0.158.173"]
OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに
sdn_controller_num_egress_ips
と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
-
OpenShift Container Platform Web コンソールで、Observe
クラスターでマルチキャスト対応の namespace を確認します。これは、
oc
CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。oc
CLI ツールを使用してマルチキャスト対応の namespace を確認するには、次を行います。マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。
$ oc get netnamespace -o json | jq -r '.items[] | select(.metadata.annotations."netnamespace.network.openshift.io/multicast-enabled" == "true") | .metadata.name'
出力例
namespace1 namespace3
OpenShift Container Platform Web コンソールを使用してマルチキャスト対応の namespace を確認するには、以下を行います。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに
sdn_controller_num_multicast_enabled_namespaces
と入力し、Run queries をクリックします。マルチキャスト対応の namespace がある場合は、それらが Expression ボックスに返されます。
-
OpenShift Container Platform Web コンソールで、Observe
クラスターのネットワークポリシーを確認します。これは
oc
CLI を使用して実行できます。oc
CLI ツールを使用してネットワークポリシーを確認するには、次のコマンドを実行します。$ oc get networkpolicy -n <namespace>
出力例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
20.5.2.5.2. 制限付きライブマイグレーションを開始する前に Egress ルーター Pod を削除する
制限付きライブマイグレーションを開始する前に、Egress ルーター Pod を確認して削除する必要があります。制限付きライブマイグレーションを実行するときにクラスター上に Egress ルーター Pod がある場合、ネットワーク Operator は移行をブロックし、次のエラーを返します。
The cluster configuration is invalid (network type limited live migration is not supported for pods with `pod.network.openshift.io/assign-macvlan` annotation. Please remove all egress router pods). Use `oc edit network.config.openshift.io cluster` to fix.
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
クラスター上の Egress ルーター Pod を見つけるには、次のコマンドを入力します。
$ oc get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."pod.network.openshift.io/assign-macvlan" == "true") | {name: .metadata.name, namespace: .metadata.namespace}'
出力例
{ "name": "egress-multi", "namespace": "egress-router-project" }
あるいは、OpenShift Container Platform Web コンソールでメトリクスをクエリーすることもできます。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに、
network_attachment_definition_instances{networks="egress-router"}
と入力します。次に、Add をクリックします。
-
OpenShift Container Platform Web コンソールで、Observe
Egress ルーター Pod を削除するには、次のコマンドを実行します。
$ oc delete pod <egress_pod_name> -n <egress_router_project>
20.5.2.5.3. NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) の削除
OpenShift SDN プラグインを使用すると、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) をノード上のプライマリーインターフェイスに適用できます。OVN-Kubernetes ネットワークプラグインにはこの機能はありません。
プライマリーインターフェイスに NNCP が適用されている場合は、OVN-Kubernetes ネットワークプラグインに移行する前に NNCP を削除する必要があります。NNCP を削除しても、プライマリーインターフェイスから設定は削除されませんが、Kubernetes-NMState はこの設定を管理できません。代わりに、configure-ovs.sh
シェルスクリプトがプライマリーインターフェイスとそれに接続された設定を管理します。
前提条件
- NNCP CR を作成し、ネットワークのプライマリーインターフェイスに適用している。
手順
次のコマンドを実行して、Cluster Network Operator (CNO) 設定オブジェクトから設定を削除します。
$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{"spec":{"migration":null}}'
以下の手順を実行して、OpenShift SDN ネットワークプラグインのプライマリーネットワークインターフェイスを定義する
NodeNetworkConfigurationPolicy
(NNCP) カスタムリソース (CR) を削除します。次のコマンドを入力して、既存の NNCP CR がプライマリーインターフェイスをクラスターにボンディングしていることを確認します。
$ oc get nncp
出力例
NAME STATUS REASON bondmaster0 Available SuccessfullyConfigured
Network Manager は、ボンディングされたプライマリーインターフェイスの接続プロファイルを
/etc/NetworkManager/system-connections
システムパスに保存します。クラスターから NNCP を削除します。
$ oc delete nncp <nncp_manifest_filename>
20.5.2.5.4. 限定的なライブマイグレーションプロセスの開始
Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応 namespace の動作を確認し、Egress ルーターリソースを削除したら、制限付きライブマイグレーションプロセスを開始できます。
前提条件
- クラスターは、ネットワークポリシー分離モードで OpenShift SDN CNI ネットワークプラグインを使用して設定されています。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップを作成している。
- クラスターは既知の正常な状態にあり、エラーがない。
-
OVN-Kubernetes に移行する前に、すべてのクラウドプラットフォーム上のすべてのノードに対してポート
6081
上の UDP パケットを許可するセキュリティーグループルールを設定する必要があります。 -
100.64.0.0/16
および100.88.0.0/16
アドレス範囲が以前 OpenShift-SDN によって使用されていた場合は、パッチが適用されています。この手順の最初のステップでは、これらのアドレス範囲が使用中かどうかを確認します。使用中の場合は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。 - Egress IP リソース、Egress ファイアウォールリソース、およびマルチキャスト対応の namespace を確認しました。
- 制限付きライブマイグレーションを開始する前に、Egress ルーター Pod をすべて削除しておきます。Egress ルーター Pod の詳細は、「リダイレクトモードでの Egress ルーター Pod のデプロイ」を参照してください。
- このドキュメントの「OVN-Kubernetes ネットワークプラグインへの限定的なライブマイグレーションに関する考慮事項」セクションを確認している。
手順
クラスターレベルのネットワーク設定にパッチを適用し、OpenShift SDN から OVN-Kubernetes への移行を開始するには、次のコマンドを入力します。
$ oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'
このコマンドを実行すると、移行プロセスが開始します。このプロセス中に、Machine Config Operator はクラスター内のノードを 2 回再起動します。移行には、クラスターのアップグレードの約 2 倍の時間がかかります。
重要この
oc patch
コマンドは、OpenShift SDN で使用されている重複する CIDR をチェックします。重複する CIDR が検出された場合は、制限付きライブマイグレーションプロセスを開始する前に、CIDR をパッチする必要があります。詳細は、「OVN-Kubernetes アドレス範囲のパッチ適用」を参照してください。オプション: 移行プロセスが完了したことを確認し、
network.config
のステータスを確認するには、次のコマンドを実行します。$ oc get network.config.openshift.io cluster -o jsonpath='{.status.networkType}'
$ oc get network.config cluster -o=jsonpath='{.status.conditions}' | jq .
問題のトラブルシューティングのために、限定的なライブマイグレーションのメトリクスを確認できます。詳細は、「限定的なライブマイグレーションのメトリクスの確認」を参照してください。
20.5.2.5.5. OVN-Kubernetes アドレス範囲のパッチ適用
OVN-Kubernetes は次の IP アドレス範囲を予約します。
-
100.64.0.0/16
.この IP アドレス範囲は、デフォルトで OVN-Kubernetes のinternalJoinSubnet
パラメーターに使用されます。 -
100.88.0.0/16
.この IP アドレス範囲は、デフォルトで OVN-Kubernetes のinternalTransSwitchSubnet
パラメーターに使用されます。
これらの IP アドレスが OpenShift SDN またはこのクラスターと通信する可能性のある外部ネットワークによって使用されている場合は、制限付きライブマイグレーションを開始する前に、別の IP アドレス範囲を使用するようにパッチを適用する必要があります。
移行が最初にブロックした場合は、次の手順を使用して、OpenShift SDN で使用している CIDR 範囲にパッチを適用できます。
これはオプションの手順であり、「限定的なライブマイグレーションプロセスの開始」の oc patch Network.config.openshift.io cluster --type='merge' --patch '{"metadata":{"annotations":{"network.openshift.io/network-type-migration":""}},"spec":{"networkType":"OVNKubernetes"}}'
コマンドを使用した後に移行がブロックされた場合にのみ使用する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
100.64.0.0/16
IP アドレス範囲がすでに使用されている場合は、次のコマンドを実行して別の範囲にパッチを適用します。次の例では100.63.0.0/16
を使用します。$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalJoinSubnet": "100.63.0.0/16"}}}}}'
100.88.0.0/16
IP アドレス範囲がすでに使用されている場合は、次のコマンドを入力して別の範囲にパッチを適用します。次の例では、100.99.0.0/16
を使用します。$ oc patch network.operator.openshift.io cluster --type='merge' -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipv4":{"internalTransitSwitchSubnet": "100.99.0.0/16"}}}}}'
IP アドレス範囲 100.64.0.0/16
および 100.88.0.0/16
にパッチを適用した後、制限付きライブマイグレーションを開始できます。
20.5.2.5.6. 限定的なライブマイグレーションを開始した後のクラスターリソースの確認
次の手順では、デプロイで OVN-Kubernetes を使用しているときに、Egress IP リソース、Egress ファイアウォールリソース、マルチキャスト対応の namespace、およびネットワークポリシーを確認する方法を示します。OpenShift SDN 上にこれらのリソースがあった場合は、移行後にそれらを確認して、適切に動作していることを確認する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - 制限付きライブマイグレーションを使用して、OpenShift SDN から OVN-Kubernetes に正常に移行しました。
手順
OpenShift Container Platform クラスター管理者として、Egress ファイアウォールリソースを確認します。これは、
oc
CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。oc
CLI ツールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。Egress ファイアウォールリソースを確認するには、次のコマンドを入力します。
$ oc get egressfirewalls.k8s.ovn.org -A
出力例
NAMESPACE NAME AGE <namespace> <example_egressfirewall> 5d
-o yaml
フラグを使用して、Egress ファイアウォールリソースの意図された動作を確認できます。以下に例を示します。$ oc get egressfirewall <example_egressfirewall> -n <namespace> -o yaml
出力例
apiVersion: k8s.ovn.org/v1 kind: EgressFirewall metadata: name: <example_egress_policy> namespace: <namespace> spec: egress: - type: Allow to: cidrSelector: 192.168.0.0/16 - type: Deny to: cidrSelector: 0.0.0.0/0
移行後にこのリソースの動作が変更されている可能性があるため、このリソースの動作が意図したとおりであることを確認してください。Egress ファイアウォールの詳細は、「プロジェクトの Egress ファイアウォールの設定」を参照してください。
OpenShift Container Platform Web コンソールを使用して Egress ファイアウォールリソースを確認するには、以下を行います。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに
ovnkube_controller_num_egress_firewall_rules
と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
-
OpenShift Container Platform Web コンソールで、Observe
クラスターの Egress IP リソースを確認します。これは、
oc
CLI を使用するか、OpenShift Container Platform Web コンソールを使用して実行できます。oc
CLI ツールを使用して Egress IP を確認するには、以下を行います。Egress IP リソースを含む namespace をリスト表示するには、次のコマンドを実行します。
$ oc get egressip
出力例
NAME EGRESSIPS ASSIGNED NODE ASSIGNED EGRESSIPS egress-sample 192.0.2.10 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.10 egressip-sample-2 192.0.2.14 ip-10-0-42-79.us-east-2.compute.internal 192.0.2.14
Egress IP に関する詳細情報を提供するには、次のコマンドを実行します。
$ oc get egressip <egressip_name> -o yaml
出力例
apiVersion: k8s.ovn.org/v1 kind: EgressIP metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"k8s.ovn.org/v1","kind":"EgressIP","metadata":{"annotations":{},"name":"egressip-sample"},"spec":{"egressIPs":["192.0.2.12","192.0.2.13"],"namespaceSelector":{"matchLabels":{"name":"my-namespace"}}}} creationTimestamp: "2024-06-27T15:48:36Z" generation: 7 name: egressip-sample resourceVersion: "125511578" uid: b65833c8-781f-4cc9-bc96-d970259a7631 spec: egressIPs: - 192.0.2.12 - 192.0.2.13 namespaceSelector: matchLabels: name: my-namespace
すべての Egress IP に対してこれを繰り返します。移行後に各リソースの動作が変更されている可能性があるため、各リソースの動作が意図したとおりであることを確認します。Egress IP の詳細は、「Egress IP アドレスの設定」を参照してください。
OpenShift Container Platform Web コンソールを使用して Egress IP を確認するには、以下を行います。
-
OpenShift Container Platform Web コンソールで、Observe
Metrics をクリックします。 -
Expression ボックスに
ovnkube_clustermanager_num_egress_ips
と入力し、Run queries をクリックします。Egress ファイアウォールリソースがある場合は、それらが Expression ボックスに返されます。
-
OpenShift Container Platform Web コンソールで、Observe
クラスターでマルチキャスト対応の namespace を確認します。これを実行できるのは
oc
CLI を使用する場合のみです。マルチキャストが有効になっている namespace を見つけるには、次のコマンドを入力します。
$ oc get namespace -o json | jq -r '.items[] | select(.metadata.annotations."k8s.ovn.org/multicast-enabled" == "true") | .metadata.name'
出力例
namespace1 namespace3
マルチキャスト対応の各 namespace を説明するには、次のコマンドを実行します。
$ oc describe namespace <namespace>
出力例
Name: my-namespace Labels: kubernetes.io/metadata.name=my-namespace pod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/audit-version=v1.24 pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/warn-version=v1.24 Annotations: k8s.ovn.org/multicast-enabled: true openshift.io/sa.scc.mcs: s0:c25,c0 openshift.io/sa.scc.supplemental-groups: 1000600000/10000 openshift.io/sa.scc.uid-range: 1000600000/10000 Status: Active
各 namespace でマルチキャスト機能が正しく設定され、期待どおりに動作していることを確認します。詳細は、"プロジェクトでのマルチキャストの有効化" を参照してください。
クラスターのネットワークポリシーを確認します。これを実行できるのは
oc
CLI を使用する場合のみです。namespace 内のネットワークポリシーに関する情報を取得するには、次のコマンドを実行します。
$ oc get networkpolicy -n <namespace>
出力例
NAME POD-SELECTOR AGE allow-multicast app=my-app 11m
ネットワークポリシーに関する詳細情報を提供するには、次のコマンドを入力します。
$ oc describe networkpolicy allow-multicast -n <namespace>
出力例
Name: allow-multicast Namespace: my-namespace Created on: 2024-07-24 14:55:03 -0400 EDT Labels: <none> Annotations: <none> Spec: PodSelector: app=my-app Allowing ingress traffic: To Port: <any> (traffic allowed to all ports) From: IPBlock: CIDR: 224.0.0.0/4 Except: Allowing egress traffic: To Port: <any> (traffic allowed to all ports) To: IPBlock: CIDR: 224.0.0.0/4 Except: Policy Types: Ingress, Egress
ネットワークポリシーの動作が意図したとおりであることを確認します。ネットワークポリシーの最適化は SDN と OVN-K で異なるため、ユーザーはさまざまな CNI で最適なパフォーマンスを実現するためにポリシーの調整が必要になる場合があります。詳細は、「ネットワークポリシーについて」を参照してください。
20.5.2.6. 限定的なライブマイグレーションのメトリクスの確認
限定的なライブマイグレーションの進行状況を監視するためのメトリクスが利用可能です。メトリクスは、OpenShift Container Platform Web コンソール、または oc
CLI を使用して表示できます。
前提条件
- OVN-Kubernetes への限定的なライブマイグレーションを開始している。
手順
OpenShift Container Platform Web コンソールで限定されたライブマイグレーションメトリクスを表示するには、次の手順を実行します。
-
Observe
Metrics をクリックします。 - Expression ボックスに openshift_network と入力し、openshift_network_operator_live_migration_procedure オプションをクリックします。
-
Observe
oc
CLI を使用してメトリクスを表示するには、以下を実行します。以下のコマンドを入力して、
openshift-monitoring
namespace にprometheus-k8s
サービスアカウントのトークンを生成します。$ oc create token prometheus-k8s -n openshift-monitoring
出力例
eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...
次のコマンドを入力して、
openshift_network_operator_live_migration_condition
メトリクスに関する情報を要求します。$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: <eyJhbGciOiJSUzI1NiIsImtpZCI6IlZiSUtwclcwbEJ2VW9We...>" "https://<openshift_API_endpoint>" --data-urlencode "query=openshift_network_operator_live_migration_condition" | jq
出力例
"status": "success", "data": { "resultType": "vector", "result": [ { "metric": { "__name__": "openshift_network_operator_live_migration_condition", "container": "network-operator", "endpoint": "metrics", "instance": "10.0.83.62:9104", "job": "metrics", "namespace": "openshift-network-operator", "pod": "network-operator-6c87754bc6-c8qld", "prometheus": "openshift-monitoring/k8s", "service": "metrics", "type": "NetworkTypeMigrationInProgress" }, "value": [ 1717653579.587, "1" ] }, ...
「制限付きのライブマイグレーションメトリクスに関する情報」の表には、利用可能なメトリクスと、openshift_network_operator_live_migration_procedure
式から入力されたラベル値が表示されます。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。
20.5.2.6.1. ライブマイグレーションのメトリックスに関する情報
次の表は、openshift_network_operator_live_migration_procedure
式から入力された利用可能なメトリクスとラベル値を示しています。この情報を使用して、移行の進行状況を監視したり、移行のトラブルシューティングを行ったりします。
メトリクス | ラベル値 |
---|---|
|
|
|
|
20.5.3. 関連情報
- Red Hat OpenShift Network Calculator
- OVN-Kubernetes ネットワークプラグインの設定
- etcd のバックアップ
- ネットワークポリシーについて
- クラスター MTU の変更
- MTU 値の選択
- ネットワークポリシーについて
OVN-Kubernetes の機能
OpenShift SDN の機能
- network.operator.openshift.io/v1