第9章 OVN-Kubernetes ネットワークプラグイン
9.1. OVN-Kubernetes ネットワークプラグインについて
Red Hat OpenShift Service on AWS クラスターは、Pod およびサービスネットワークに仮想化ネットワークを使用します。
Red Hat OpenShift Networking の一部である OVN-Kubernetes ネットワークプラグインは、Red Hat OpenShift Service on AWS のデフォルトのネットワークプロバイダーです。OVN-Kubernetes は Open Virtual Network (OVN) をベースとしており、オーバーレイベースのネットワーク実装を提供します。OVN-Kubernetes プラグインを使用するクラスターは、各ノードで Open vSwitch (OVS) も実行します。OVN は、宣言ネットワーク設定を実装するように各ノードで OVS を設定します。
OVN-Kubernetes は、Red Hat OpenShift Service on AWS およびシングルノード OpenShift デプロイメントのデフォルトのネットワークソリューションです。
OVS プロジェクトから生まれた OVN-Kubernetes は、オープンフロールールなど、同じコンストラクトの多くを使用して、パケットがネットワークを通過する方法を決定します。詳細は、Open Virtual Network の Web サイト を参照してください。
OVN-Kubernetes は、仮想ネットワーク設定を OpenFlow ルールに変換する OVS 用の一連のデーモンです。OpenFlow は、ネットワークスイッチおよびルーターと通信するためのプロトコルであり、ネットワークデバイス上のネットワークトラフィックのフローをリモートで制御する手段を提供し、ネットワーク管理者がネットワークトラフィックのフローを設定、管理、および監視できるようにします。
OVN-Kubernetes は、OpenFlow では利用できない高度な機能をさらに提供します。OVN は、分散仮想ルーター、分散論理スイッチ、アクセス制御、DHCP および DNS をサポートします。OVN は、オープンフローと同等のロジックフロー内に分散仮想ルーターを実装します。たとえば、ネットワーク上に DHCP リクエストを送信する Pod がある場合、Pod はそのブロードキャストを送信して DHCP アドレスを探します。また、そのパケットに一致するロジックフロールールが存在し、応答としてゲートウェイ、DNS サーバー、IP アドレスなどを提供します。
OVN-Kubernetes は、各ノードでデーモンを実行します。すべてのノードで実行されるデータベースおよび OVN コントローラー用のデーモンセットがあります。OVN コントローラーは、ネットワークプロバイダーの機能 (Egress IP、ファイアウォール、ルーター、ハイブリッドネットワーク、IPSEC 暗号化、IPv6、ネットワークポリシー、ネットワークポリシーログ、ハードウェアオフロード、およびマルチキャスト) をサポートするために、ノード上で Open vSwitch デーモンをプログラムします。
9.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 暗号化。
9.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 ファミリーにデフォルトゲートウェイが含まれるようにホストネットワークを再設定できます。
9.1.3. セッションアフィニティー
セッションアフィニティーは、Kubernetes Service オブジェクトに適用される機能です。<service_VIP>:<Port> に接続するたびに、トラフィックが常に同じバックエンドに負荷分散されるようにする場合は、セッションアフィニティー を使用できます。クライアントの IP アドレスに基づいてセッションアフィニティーを設定する方法など、詳細は、セッションアフィニティー を参照してください。
セッションアフィニティーのスティッキネスタイムアウト
Red Hat OpenShift Service on AWS の OVN-Kubernetes ネットワークプラグインは、最後のパケットに基づいてクライアントからのセッションのスティッキネスタイムアウトを計算します。たとえば、curl コマンドを 10 回実行すると、スティッキーセッションタイマーは最初のパケットではなく 10 番目のパケットから開始します。その結果、クライアントが継続的にサービスに接続している場合でも、セッションがタイムアウトすることはありません。タイムアウトは、timeoutSeconds パラメーターで設定された時間、サービスがパケットを受信しなかった場合に開始されます。
