Red Hat OpenShift の仮想化に対応したネットワークの設計 IBM Cloud VPC

IBM Cloud VPC 上の Red Hat OpenShift 仮想化向けに、VPCネットワーク、 OpenShift のソフトウェア定義ネットワーク（SDN）、およびOpen Virtual Networking（OVN）のユーザー定義ネットワークを網羅したネットワークを設計します。

IBM Cloud VPC 上の Red Hat OpenShift 仮想化におけるネットワーク設計には、以下のような明確なレイヤーがある。

VPCネットワーキング
Red Hat OpenShift ネットワーキング
OVNネットワーキング

主なネットワーク・アーキテクチャの要素を下図に示す。

Red Hat OpenShift IBM Cloud ネットワーク上の仮想化ネットワーク上の仮想化ネットワーク上の仮想化ネットワーク上の仮想化ネットワーク上の仮想化 — Red Hat OpenShift IBM Cloud

IBM Cloud VPC ネットワーキング

クラウドリソースのデプロイと管理には、 IBM Cloud VPC ネットワーキングを使用する。仮想サーバー、コンテナー、ベアメタルデプロイメントなどのワークロードの基盤を提供し、ネットワークのセグメンテーション、セキュリティ、スケーラビリティの確保を支援します。

Red Hat® OpenShift® をプロビジョニングするには、VPC を作成する必要があります。 Kubernetes Service クラスター。

サブネットを使ったデフォルトのプライベート・ネットワーク

Red Hat OpenShift Kubernetes Service クラスターをプロビジョニングするには、少なくとも1つのアベイラビリティゾーンにVPCサブネットを作成する必要があります。詳しくは、サブネットを使ったデフォルトプライベートネットワーキングを参照。

ロード・バランサー

Red Hat OpenShift Kubernetes Service クラスターには、外部ネットワークトラフィックのイングレスエンドポイントとして機能する Red Hat OpenShift イングレスコントローラーが配備されています。 Red Hat OpenShift Kubernetes Service クラスターでは、VPC アプリケーションロードバランサーがクラスターごとに自動的に作成され、イングレスコントローラーを公開します。詳しくはロードバランサーを参照。

Red Hat OpenShift Kubernetes Service は次のような働きをする。

DNSサービスはルートサブドメインをVPCロードバランサーのホスト名に解決します。
VPC ロードバランサーは、VPC ホスト名を、正常に動作していると報告されているインジェスト・コントローラー・サービスの利用可能な外部 IP アドレスに解決します。
VPCロードバランサはリクエストをイングレスコントローラサービスに送る。
Ingress コントローラーは、プライベート・ネットワークを介してアプリ・ポッドのプライベート IP アドレスに要求を転送します。

仮想プライベート・エンドポイント

Red Hat OpenShift Kubernetes Service 環境における仮想プライベート・エンドポイント（VPE）は、主に、 Red Hat OpenShift クラスタと IBM Cloud プラットフォーム・サービス間のプライベート接続を、パブリック・インターネットを横断するネットワーク・トラフィックなしで実現するために使用される。

次の表は、重要なクラスタ操作のために IBM Cloud によって自動的にプロビジョニングされるすべての仮想プライベートエンドポイントの一覧です。

クラスタ運用のためにプロビジョニングされる仮想プライベート・エンドポイント。
仮想プライベート・エンドポイント	管理サービス	説明
iks-api	Kubernetes Service API	IBM Cloud Kubernetes Service API へのプライベートアクセスクラスタ管理操作 (kubectl、oc コマンド) ワーカーノードからコントロールプレーンへの通信 IBM Cloud CLI 操作 (`ibmcloud ks` コマンド) プライベート専用のクラスタ構成が可能
イクスリアス	VPC インフラストラクチャー・サービス	VPC インフラストラクチャ API へのプライベートアクセスワーカーノードのプロビジョニングとライフサイクル管理ストレージボリュームのアタッチと管理 VPC ネットワーキング操作（ロードバランサ、セキュリティグループ）インフラストラクチャのリソース管理 IBM Cloud クラスタオートスケーラ、ボリューム操作用ストレージ CSI ドライバ、ロードバランサプロビジョニングサービス、ワーカーノードライフサイクルコントローラによって使用されます
IKSレジストリ	Container registry	IBM Cloud Container Registry へのプライベート・アクセス公共インターネットを介さずにコンテナ・イメージをプル公共およびプライベートのレジストリ・ネームスペースへのアクセスイメージ・プルのための公共退出料金を排除
iks-<クラスタID>	特定のクラスタインスタンス	クラスタインスタンス固有のプライベートエンドポイントクラスタAPIへの直接アクセスプライベート専用のクラスタ構成に使用地域APIエンドポイントの代替クラスタへの直接アクセス、VPC内のサービス間通信、プライベートクラスタアクセスパターンを必要とするツールで使用される
iks-cos-config	Cloud Object Storage (設定)	IBM Cloud Object Storage コンフィギュレーション API へのプライベート・アクセスバケット管理とコンフィギュレーション操作 IAM ポリシーとアクセス・コントロール管理サービス・クレデンシャル操作
イクスコス	Cloud Object Storage (データ)	IBM Cloud Object Storage S3 API オブジェクト・ストレージのデータプレーン操作（PUT/GET/DELETE）バックアップおよび復元データ転送アプリケーション・データ・ストレージへのアクセス

Red Hat OpenShift 仮想化ネットワーク

Red Hat OpenShift 仮想化は、 Red Hat OpenShift ネットワーキング機能を使用して、コンテナ化されたワークロードと同時に実行される仮想サーバーに柔軟なソフトウェア定義ネットワーキングを提供する。仮想サーバーネットワーキングとポッドネットワーキングの違いを理解することが重要だ。各仮想サーバーは virt-launcher ポッド内で実行され、常にデフォルトのポッドネットワークに接続されている。

┌────────────────────────────────┐
│          Worker Node           │
│  ┌──────────────────────────┐  │
│  │      virt-launcher       │  │  ← Kubernetes Pod Security Context
│  │          pod             │  │
│  │  ┌────────────────────┐  │  │
│  │  │   virtual server   │  │  │  ← KVM/QEMU Hypervisor Isolation
│  │  │       (QEMU)       │  │  │
│  │  └────────────────────┘  │  │
│  └──────────────────────────┘  │
└────────────────────────────────┘

仮想サーバーをどのようにプロビジョニングしてセットアップするかによって、仮想サーバーはポッドネットワークを共有します（または、 multus を使用して異なるネットワークに接続することもできます）。

次の例では、 Red Hat OpenShift のデフォルトのポッドネットワーキングについて説明します。このポッドネットワーキングは OVN- Kubernetes ネットワーキングで変更できます。

ポッドネットワーク（クラスターネットワーク）

各ポッドは、クラスタネットワークのクラスレス・ドメイン間ルーティング（CIDR）からプライベートIPアドレスを割り当てられます
ノード間のポッド間通信を提供
Podはクラスタ内のプライベートIPを使って直接通信する
ネットワーク・ポリシーはレイヤー3/4でポッド間のトラフィックを制御する
フラットネットワークモデル - デフォルトですべてのポッドが通信可能
ポッド間のNATなし（ポッド間直接通信）
ネットワーク・ポリシーはセグメンテーションとセキュリティを提供する
クラスタ内でのDNSベースのサービス発見
仮想サーバーが virt-launcher ポッド内で実行されると、その IP アドレスは virt-launcher ポッドの IP アドレスに対して NAT 変換されます

IPマスカレード（送信元NAT（SNAT））

ポッドが外部ネットワークへのアウトバウンド接続を開始すると、ソースIPはマスカレードされる
リクエストパケットの発信元IPアドレスは、ポッドが実行されているワーカーノードのIPアドレスに変更されます
ポッドのIPはクラスタ外ではルーティングできないため、IPマスカレードが必要です
リターントラフィックは元のポッドIPにデマスケレートされる
外部サービスは、ポッドIPではなくワーカーノードIPから来たリクエストを見る

ClusterIP サービス

サービスは安定したエンドポイントを提供し、ポッドのロードバランシングを行う。ポッドIPを抽象化し、アプリケーションに一貫したアクセスポイントを提供する。 ClusterIP サービスは以下の機能を提供する。

クラスタ内のみでアクセス可能な仮想IP ( ClusterIP ) を作成します
ClusterIP 指定がない場合、デフォルトのサービスタイプ
バックエンドポッド間の内部ロードバランシングを提供します
トラフィック分散にkube-proxyまたはOVN- Kubernetes を使用

以下の使用例は、 ClusterIP の使用例である。

内部マイクロサービス通信
外部からのアクセスを必要としないバックエンド・サービス
クラスタワークロードのみがアクセスするデータベースサービス
ポッド間サービス発見

NodePort サービス

サービスは安定したエンドポイントを提供し、ポッドのロードバランシングを行う。ポッドIPを抽象化し、アプリケーションに一貫したアクセスポイントを提供する。 NodePort サービスは以下の機能を提供する。

各ワーカーノードの固定ポート(30000-32767)でサービスを公開する
を通じてサービスを利用しやすくする。 <NodeIP>:<NodePort>
ClusterIP サービスを自動的に作成
NodePort へのトラフィックはサービスへ転送される

次の例は、 NodePort のトラフィックフローを示している。

外部クライアントからの接続 <WorkerNodeIP>:<NodePort>
ノードはトラフィックを ClusterIP サービスに転送する
サービスはバックエンドのポッドに負荷を分散する
応答は、SNAT（送信元ネットワークアドレス変換）を用いて逆の経路をたどります

以下の使用例は、 NodePorts の使用例である。

開発環境とテスト環境
ロードバランサーを使用しない迅速な外部アクセス
外部ロードバランサーとの統合
カスタム負荷分散ソリューション

ロード・バランサー・サービス

IBM Cloud Red Hat OpenShift Kubernetes Service では、ロードバランサーサービスは自動的にVPCネットワークロードバランサーまたはアプリケーションロードバランサーをプロビジョニングします。ロードバランサーサービスは以下の機能を提供する。

外部のロードバランサーを自動的にプロビジョニングする
外部IPまたはホスト名をサービスに割り当てる
NodePort と ClusterIP サービスを自動的に作成
サービスのバックエンドにレイヤー4のロードバランシングを提供

次の例は、VPC内のトラフィック・フローを示している。

外部クライアントがVPCロードバランサーのIPまたはホスト名に接続する
VPCロードバランサがワーカーノードに配信 NodePorts
Node サービスへ ClusterIP
サービスはバックエンドのポッドに負荷を分散する

以下のユースケースは、ロードバランサーの使用例である。

専用の外部アクセスを必要とするプロダクション・アプリケーション
HTTP 以外のプロトコル ( TCP または UDP サービス)
安定した外部IPを必要とするアプリケーション
イングレス・レイヤーまたはルート・レイヤーをバイパスするサービス

Red Hat OpenShift ルート

Red Hat OpenShift ルートは、完全修飾ドメイン名（FQDN）をバックエンドサービスにマッピングすることで、外部ネットワークトラフィックに対してサービスを公開し、これによりクラスタ外からもアプリケーションにアクセスできるようになります。以下のリストは、 Red Hat OpenShift Routesの主な機能を示している。

レイヤー7ルーティング - HTTP / HTTPS ホスト名ベースのルーティングによるトラフィック
自動DNS - ルートはクラスタのサブドメインを使用します: <route-name>-<namespace>.apps.<cluster-domain>
無担保ルート ( HTTP )
TLS 終端処理
- エッジ終端ルート（ルーターで TLS ）
- パススルー・ルート ( TLS at Pod)
- ルートの再暗号化（ルーターとポッドで TLS ）
HAProxy-ベースは、 Red Hat OpenShift イングレスコントローラー（ルーター）によって実装される
トラフィック管理 - パスベースルーティング、トラフィック分割、セッションアフィニティ

オープン・バーチャル・ネットワーキング（OVN）

OVN- Kubernetes コンテナネットワークインターフェース（CNI）プラグインは、 Red Hat OpenShift Virtualizationにおいて推奨されるネットワークオプションであり、従来のポッドネットワークと並行して動作する仮想サーバーのネットワーク利用シナリオをサポートします。 OVN- Kubernetes は、Open Virtual Networking（OVN）を基盤としており、すべてのワーカーノードでOpen vSwitch （OVS）を採用しています。マルチテナント、 NetworkPolicies,、ハイブリッド仮想サーバー、ポッドネットワーキングをサポートしている。 Red Hat OpenShift on IBM Cloud VPCは、デフォルトのネットワーキング・プラグインとしてOVN- Kubernetes をサポートしています。

VMware vSphere およびNSX-Tに精通している管理者の方は、『 vSphere 管理者向け OpenShift におけるOVNネットワーキング』を参照し、OVNの概念と vSphere における対応する概念との対応関係を確認してください。

Red Hat OpenShift OVNでは、以下の3つのネットワーク・トポロジーが、ポッドと仮想サーバーへのセカンダリ・ネットワーク接続を提供する。

レイヤ 2 ( L2 )- Geneve カプセル化によるソフトウェア定義 L2 ブロードキャスト・ドメイン
レイヤー3 ( L3 )- カスタムIPサブネットを持つルーティングされたネットワークセグメント。 L3 ネットワークでは、ノードごとに個別のCIDR（クラスレス・ドメイン間ルーティング）が割り当てられています。
ローカルネット - 基礎となる物理ネットワークVLANへの直接アクセス

IBM Cloud の Red Hat OpenShift 仮想化では、 OVNレイヤー 2と OVNローカルネットが、ユーザー定義ネットワーク（UDN）で使用される2つの主要なトポロジーである。

OVN レイヤ 2 は、Geneve カプセル化を使用してクラスタ全体で Software-Defined L2 ブロードキャストドメインを作成することで、NSX オーバーレイセグメントと同様のオーバーレイネットワーキングを提供する。これらのネットワークはVPCサブネットから分離されている。 VPCサブネットへのイングレスとイグレスを提供するOVNローカルネットに接続されたゲートウェイポッドまたは仮想サーバーと、VPCルートが必要です。
OVN Localnet は、基盤となる VPC ネットワークへの VLAN アクセスを提供し、NSX の VLAN バックドセグメントに似ています。 IBM Cloud VPC では、この直接接続により、仮想サーバーとポッドは、仮想ネットワーク・インターフェイス（VNI）とVLANアタッチメントを使用して、VPCサブネットに直接接続できます。

次の図は、OVN と multus による仮想サーバー・ネットワーキングの概要を示している。デフォルトでは、 Kubernetes （および Red Hat OpenShift ）は、プライマリCNIプラグイン（OVN- Kubernetes など）を使用して、各ポッドに単一のネットワークインタフェースを割り当てます。 Red Hat OpenShift の Multus は、ポッドと仮想サーバーに複数のネットワーク・インターフェイスを有効にする CNI プラグインです。

当初はOVNレイヤー2ネットワーキングのみが利用可能です。

OVNユーザー定義ネットワーク

Red Hat OpenShift 仮想化

Red Hat OpenShift におけるユーザー定義ネットワーク（UDN）は、OVN- Kubernetes によって提供されるカスタムネットワークである。 UDNは、デフォルトのクラスタネットワーク（デフォルトのポッドネットワークとも呼ばれる）を置き換えます。 UDNは、独自のIPサブネット、ゲートウェイ、およびルーティングドメインを持つネットワークを作成するために使用します。 UDNはプライマリポッドネットワークから独立しており、ワークロードが以下の機能を必要とする場合に一般的に使用される。

クラスタ内の他のアプリケーションからのネットワーク分離
カスタムIPアドレス範囲または重複サブネット
選択したネームスペースまたはワークロード間の東西トラフィックを直接制御する
複数のネットワーク・インターフェイスを必要とする仮想サーバー（ Red Hat OpenShift 仮想化）との統合
セキュリティやコンプライアンス要件に対応した専用ネットワークセグメント

デフォルトのポッドネットワークとは異なり、UDNはネームスペースに明示的にアタッチされます。各UDNは、OVNに追加の論理スイッチを作成する。 UDN がネームスペースのプライマリ・ユーザ定義ネットワークとしてラベル付けされると、そのネームスペース内のすべてのポッドと仮想サーバは、クラスタのデフォルトではなく、そのネットワークをメイン・ネットワークとして使用します。

クラスタ・ユーザー定義ネットワーク（CUDN）は、特定の名前空間に属さないクラスタ・スコープのリソースを提供することで、UDNの概念を拡張します。 CUDNが作成され、1つ以上の名前空間と関連付けられる。名前空間ごとに1つ必要な名前空間スコープ付き NetworkAttachmentDefinition （NAD）リソースとは異なり、CUDNは、名前空間がCUDN定義に追加されると、自動的に名前空間にNADを作成する。

UDNは、スコープ、アタッチメント方式、トポロジーに基づく柔軟なネットワーキング・オプションを提供する：

ネットワークの範囲

名前空間スコープ付きUDN - 1つの名前空間に限定されたネットワーク定義で、名前空間ごとに個別の NetworkAttachmentDefinitions
クラスタスコープ CUDN - クラスタ全体で利用可能なネットワーク定義で、選択したネームスペースに NetworkAttachmentDefinitions を自動的に作成します

アタッチメント方式

プライマリ・ネットワーク - 名前空間内のすべてのポッド/仮想サーバのデフォルト・ネットワークとして機能し、クラスタのデフォルト・ネットワークに置き換わります
セカンダリネットワーク - Multus CNIを介して接続され、プライマリネットワークと並行してポッド/仮想サーバーに追加のネットワークインターフェイスを提供する

ネットワーク・トポロジー

レイヤー2 - ソフトウェア定義の L2 ブロードキャストドメイン。Geneveカプセル化を採用しており、アドレス解決プロトコル（ARP）に基づく検出およびMAC間通信を可能にする
レイヤー3 - カスタムIPサブネットとゲートウェイを持つルーティングされたネットワークセグメント
ローカルネット - 仮想ネットワークインターフェース（VNI）アタッチメントを使用して、基礎となるVPCサブネットに直接VLANアクセスします

これらの特性を組み合わせて、カスタマイズされたネットワーキング・ソリューションを構築することができます。たとえば、ローカルネット・トポロジーを使用するクラスタ・スコープのCUDNは、プライマリまたはセカンダリ・ネットワークのいずれかとして、VPCサブネットに直接アクセスできる複数のネームスペースを提供できます。

OVNレイヤー2ネットワーク

OVN レイヤー 2 ネットワークは、NSX オーバーレイ・セグメントや従来の VLAN に似たソフトウェア定義のレイヤー 2 ブロードキャスト・ドメインです。レイヤー2は、クラスタの既存のネットワーク・インフラストラクチャ上でGeneveカプセル化を使用することにより、完全にOVN内に実装されています。レイヤー2ネットワークにより、ポッドと仮想サーバーは、ARPディスカバリー、ブロードキャスト、マルチキャスト、直接MAC間通信をサポートし、あたかも同じイーサネットセグメント上にあるかのように通信できる。

Red Hat OpenShift クラスタにはプライマリクラスタネットワークがあり、ポッドと仮想サーバは OVN 経由でルーティングされたデフォルトクラスタ CIDR から IP を受け取ります。セカンダリ・レイヤー2ネットワークは、 ClusterUserDefinedNetwork （CUDN）またはネームスペース・スコープ付きUDNによって定義する。セカンダリー・レイヤー2ネットワークとは、デフォルトのポッドネットワーク以外に作成する追加ネットワークのことです。

以下の項目は、レイヤ2ネットワークの主な特徴である。

OVNによって作成されたレイヤ2ブロードキャストドメインに、IPAM、MAC割り当て、接続性を提供する
セカンダリ・ネットワーク上のポッド名に対するDNS解決が組み込まれていない
プライマリのレイヤー2ネットワークからのトラフィックは、仮想サーバーから送信される際に送信元ネットワークアドレスの変換（NAT）が行われ、 FRR-K8s およびVPCルートを使用して設定可能なレイヤー2ネットワークへのアクセスもルーティングされます
セカンダリーレイヤー2ネットワークは、明示的に設定されない限り、インターネットに直接アクセスできないようにデフォルトで隔離されています
クラスタ内の仮想サーバー間通信や、マルチキャストに依存するアプリケーションに適しています

OVN ローカルネットワーク

OVN Localnetネットワークは、基盤となるVPCネットワーク・インフラストラクチャへの直接VLANアクセスを仮想サーバーとポッドに提供します。 OVN Localnetは、仮想ネットワーク・インターフェイス（VNI）とVLANアタッチメントを使用することで、仮想サーバーとポッドがVPCサブネットに接続できるようにします。

VLANアタッチメントを使用すると、 Red Hat OpenShift Virtualization上で実行する仮想サーバーをVPCサブネットに直接アタッチできます。このアプローチでは、ワークロード全体で一貫したネットワーキングを提供することで、新規または移行した仮想サーバーに既存のVPCサブネット設計を使用することができます。

ローカルネットネットワーキングでは、VPCサブネットに接続される各仮想サーバーNICに以下の要件が必要です：

VPCサブネットから予約されたIPアドレスと、VNIへのインバウンド・トラフィックとアウトバウンド・トラフィックを制御する1つ以上のセキュリティ・グループを定義する仮想ネットワーク・インターフェイス（VNI）リソース。
ベアメタルサーバーのVLANアタッチメント。このVLANアタッチメントの「フローティング機能」（アタッチメントがワーカーノード間で移動できるかどうかを決定する機能）は、仮想サーバーを別のワーカーノードへライブマイグレーションさせるために有効にする必要があります。
VLAN ID。 VLANタグは、ワーカーノード上のPCIインターフェイスを関連付ける。通常、この関連付けはVLAN IDとVPCサブネットの間で1対1のマッピングとなる。

ローカルネット・ネットワークのセキュリティ・グループ・ルールを設計する際には、一部のネットワーク・スイッチングがワーカー・ノード上の OVS 内で発生し、VPC インフラストラクチャに到達しないことを考慮してください。セキュリティ・グループ・ルールは、VPCネットワーク・ファブリックを通過するトラフィックにのみ適用されます。同じワーカーノード上の仮想サーバー間のトラフィックは、VPC のセキュリティ制御をバイパスできます。

以下の例は、Localnetのユースケースです。

既存のVPCサブネットIPアドレスを必要とする仮想サーバーの移行
既存のVPCセキュリティグループおよびネットワークポリシーとの統合
他のVPCリソースへの直接接続
VPCサブネットを使用したネットワーク・セグメンテーションのコンプライアンス要件
VPCと Red Hat OpenShift 仮想化間で一貫したIPアドレッシングを必要とするハイブリッド・アーキテクチャ

次のステップ

Red Hat OpenShift 仮想化のネットワーキング設計を理解したところで、次に関連するトピックを探ります：

セキュリティネットワークポリシーやSCCを含むセキュリティ設計の検討
コンピュートワーカーノードのコンピュート設計オプションの検討
ストレージ永続ボリュームのストレージ・デザイン・パターンについて学ぶ
観測可能性ネットワーク監視のための観測可能性ソリューションを理解する