16.2. OpenShift SDN クラスターネットワークプロバイダーからの移行
クラスター管理者は、OpenShift SDN CNI クラスターネットワークプロバイダーから OVN-Kubernetes Container Network Interface(CNI) クラスターネットワークプロバイダーに移行できます。
OVN-Kubernetes についての詳細は、OVN-Kubernetes ネットワークプロバイダーについて を参照してください。
16.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 ネットワークプラグインとの間の移行は、OpenShift Dedicated や Red Hat OpenShift Service on AWS (ROSA) などのマネージド OpenShift クラウドサービスではサポートされていません。
16.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 アドレスを設定する際の相違点は、以下の表で説明されています。
OVN-Kubernetes | OpenShift SDN |
---|---|
|
|
OVN-Kubernetes で egress IP アドレスを使用する方法についての詳細は、egress IP アドレスの設定について参照してください。
Egress ネットワークポリシー
OVN-Kubernetes と OpenShift SDN との間に egress ファイアウォールとしても知られる egress ネットワークポリシーの設定についての相違点は、以下の表に記載されています。
OVN-Kubernetes | OpenShift SDN |
---|---|
|
|
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 から移行する際に、ネットワークポリシーで変更を加える必要はありません。
16.2.1.2. 移行プロセスの仕組み
以下の表は、プロセスのユーザーが開始する手順と、移行が応答として実行するアクション間を区分して移行プロセスを要約しています。
ユーザー起動の手順 | 移行アクティビティー |
---|---|
|
|
|
|
クラスターの各ノードを再起動します。 |
|
OpenShift SDN へのロールバックが必要な場合、以下の表がプロセスについて説明します。
ユーザー起動の手順 | 移行アクティビティー |
---|---|
MCO を一時停止し、移行が中断されないようにします。 | MCO が停止します。 |
|
|
|
|
クラスターの各ノードを再起動します。 |
|
クラスターのすべてのノードが再起動した後に MCO を有効にします。 |
|
16.2.2. OVN-Kubernetes デフォルト CNI ネットワークプロバイダーへの移行
クラスター管理者は、クラスターのデフォルトの Container Network Interface (CNI) ネットワークプロバイダーを OVN-Kubernetes に変更できます。移行時に、クラスター内のすべてのノードを再起動する必要があります。
移行の実行中はクラスターを利用できず、ワークロードが中断される可能性があります。サービスの中断が許容可能な場合にのみ移行を実行します。
前提条件
- ネットワークポリシーの分離モードで OpenShift SDN CNI クラスターネットワークプロバイダーで設定されたクラスター。
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - etcd データベースの最新のバックアップが利用可能である。
- 再起動は、ノードごとに手動でトリガーできます。
- クラスターは既知の正常な状態にあり、エラーがないこと。
手順
クラスターネットワークの設定のバックアップを作成するには、以下のコマンドを入力します。
$ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
移行のすべてのノードを準備するには、以下のコマンドを入力して Cluster Network Operator 設定オブジェクトに
migration
フィールドを設定します。$ oc patch Network.operator.openshift.io cluster --type='merge' \ --patch '{ "spec": { "migration": {"networkType": "OVNKubernetes" } } }'
注記この手順では、OVN-Kubernetes はすぐにデプロイしません。その代わりに、
migration
フィールドを指定すると、新規マシン設定が OVN-Kubernetes デプロイメントの準備に向けてクラスター内のすべてのノードに適用されるように Machine Config Operator (MCO) がトリガーされます。オプション: ネットワークインフラストラクチャーの要件を満たすように 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> }}}}'
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 }}}}'
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
移行を完了するには、クラスター内の各ノードを再起動します。たとえば、以下のような 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
ssh アクセスが使用できない場合、インフラストラクチャープロバイダーの管理ポータルから各ノードを再起動できる場合があります。
移行が正常に完了したことを確認します。
CNI ネットワークプロバイダーが 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