第7章 OVN-Kubernetes ネットワークプラグイン
7.1. OVN-Kubernetes ネットワークプラグインについて
OpenShift Dedicated クラスターは、Pod およびサービスネットワークに仮想化ネットワークを使用します。
Red Hat OpenShift Networking の一部である OVN-Kubernetes ネットワークプラグインは、OpenShift Dedicated のデフォルトのネットワークプロバイダーです。OVN-Kubernetes は Open Virtual Network (OVN) をベースとしており、オーバーレイベースのネットワーク実装を提供します。OVN-Kubernetes プラグインを使用するクラスターは、各ノードで Open vSwitch (OVS) も実行します。OVN は、宣言ネットワーク設定を実装するように各ノードで OVS を設定します。
OVN-Kubernetes は、OpenShift Dedicated およびシングルノード OpenShift デプロイメントのデフォルトのネットワークソリューションです。
OVS プロジェクトから生まれた OVN-Kubernetes は、オープンフロールールなど、同じコンストラクトの多くを使用して、パケットがネットワークを通過する方法を決定します。詳細は、Open Virtual Network の Web サイト を参照してください。
OVN-Kubernetes は、仮想ネットワーク設定を OpenFlow
ルールに変換する OVS 用の一連のデーモンです。OpenFlow
は、ネットワークスイッチおよびルーターと通信するためのプロトコルです。ネットワークデバイス上のネットワークトラフィックのフローをリモートで制御する手段を提供し、ネットワーク管理者がネットワークトラフィックのフローを設定、管理、および監視できるようにします。
OVN-Kubernetes は、OpenFlow
では利用できない高度な機能をさらに提供します。OVN は、分散仮想ルーティング、分散論理スイッチ、アクセス制御、Dynamic Host Configuration Protocol (DHCP)、および DNS をサポートしています。OVN は、オープンフローと同等のロジックフロー内に分散仮想ルーターを実装します。たとえば、ネットワーク上の DHCP サーバーに DHCP 要求を送信する Pod がある場合、要求内のロジックフロールールによって OVN-Kubernetes がパケットを処理することにより、サーバーがゲートウェイ、DNS サーバー、IP アドレスなどの情報で応答できるようになります。
OVN-Kubernetes は、各ノードでデーモンを実行します。すべてのノードで実行されるデータベースおよび OVN コントローラー用のデーモンセットがあります。OVN コントローラーは、ネットワークプロバイダーの機能 (Egress IP、ファイアウォール、ルーター、ハイブリッドネットワーク、IPSEC 暗号化、IPv6、ネットワークポリシー、ネットワークポリシーログ、ハードウェアオフロード、およびマルチキャスト) をサポートするために、ノード上で Open vSwitch デーモンをプログラムします。
7.1.1. OVN-Kubernetes の目的
OVN-Kubernetes ネットワークプラグインは、Open Virtual Network (OVN) を使用してネットワークトラフィックフローを管理する、オープンソースのフル機能の Kubernetes CNI プラグインです。OVN はコミュニティーで開発され、ベンダーに依存しないネットワーク仮想化ソリューションです。OVN-Kubernetes ネットワークプラグインは次のテクノロジーを使用します。
- ネットワークトラフィックフローを管理するための OVN。
- Ingress ルールおよび Egress ルールを含む Kubernetes ネットワークポリシーのサポートとログ。
- ノード間にオーバーレイネットワークを作成するための、Virtual Extensible LAN (VXLAN) ではなく、Generic Network Virtualization Encapsulation (Geneve) プロトコル。
OVN-Kubernetes ネットワークプラグインは、次の機能をサポートしています。
- Linux と Microsoft Windows の両方のワークロードを実行できるハイブリッドクラスター。この環境は ハイブリッドネットワーキング と呼ばれます。
- ホストの中央処理装置 (CPU) から互換性のあるネットワークカードおよびデータ処理装置 (DPU) へのネットワークデータ処理のオフロード。これは ハードウェアオフロード と呼ばれます。
- ベアメタル、VMware vSphere、IBM Power®、IBM Z®、および RHOSP プラットフォーム上の IPv4 プライマリーデュアルスタックネットワーク。
- ベアメタルプラットフォーム上の IPv6 シングルスタックネットワーキング。
- ベアメタル、VMware vSphere、または RHOSP プラットフォーム上で実行しているクラスター用の IPv6 プライマリーデュアルスタックネットワーク。
- Egress ファイアウォールデバイスと Egress IP アドレス。
- リダイレクトモードで動作する Egress ルーターデバイス。
- クラスター内通信の IPsec 暗号化。
7.1.2. OVN-Kubernetes IPv6 とデュアルスタックの制限
OVN-Kubernetes ネットワークプラグインには、次の制限があります。
デュアルスタックネットワークに設定されたクラスターでは、IPv4 と IPv6 の両方のトラフィックがデフォルトゲートウェイとして同じネットワークインターフェイスを使用する必要があります。この要件が満たされない場合には、
ovnkube-node
デーモンセットのホストにある Pod は、CrashLoopBackOff
状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml
のようなコマンドで Pod を表示すると、以下の出力のように、status
フィールドにデフォルトゲートウェイに関する複数のメッセージが表示されます。I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
唯一の解決策は、両方の IP ファミリーがデフォルトゲートウェイに同じネットワークインターフェイスを使用するように、ホストネットワークを再設定することです。
デュアルスタックネットワーク用に設定されたクラスターの場合、IPv4 と IPv6 の両方のルーティングテーブルにデフォルトゲートウェイが含まれている必要があります。この要件が満たされない場合には、
ovnkube-node
デーモンセットのホストにある Pod は、CrashLoopBackOff
状態になります。oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml
のようなコマンドで Pod を表示すると、以下の出力のように、status
フィールドにデフォルトゲートウェイに関する複数のメッセージが表示されます。I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
唯一の解決策として、両方の IP ファミリーにデフォルトゲートウェイが含まれるようにホストネットワークを再設定できます。
7.1.3. セッションアフィニティー
セッションアフィニティーは、Kubernetes Service
オブジェクトに適用される機能です。<service_VIP>:<Port> に接続するたびに、トラフィックが常に同じバックエンドに負荷分散されるようにする場合は、セッションアフィニティー を使用できます。クライアントの IP アドレスに基づいてセッションアフィニティーを設定する方法など、詳細は、セッションアフィニティー を参照してください。
セッションアフィニティーのスティッキネスタイムアウト
OpenShift Dedicated の OVN-Kubernetes ネットワークプラグインは、最後のパケットに基づいてクライアントからのセッションのスティッキネスタイムアウトを計算します。たとえば、curl
コマンドを 10 回実行すると、スティッキーセッションタイマーは最初のパケットではなく 10 番目のパケットから開始します。その結果、クライアントが継続的にサービスに接続している場合でも、セッションがタイムアウトすることはありません。タイムアウトは、timeoutSeconds
パラメーターで設定された時間、サービスがパケットを受信しなかった場合に開始されます。