次の方法で共有

Azure Operator Nexus Kubernetes のネットワーク

Azure Operator Nexus (または単に Operator Nexus) インスタンスは、お客様のオンプレミスにインストールされたコンピューティングおよびネットワーク ハードウェアで構成されます。 物理デバイスと仮想デバイスの複数のレイヤーは、このコンピューティング ハードウェアで実行されているワークロードに対するネットワーク接続とルーティング サービスを提供します。 このドキュメントでは、これらの各ネットワーク レイヤーについて詳しく説明します。

トポロジ

ここでは、Operator Nexus インスタンス内のハードウェアのトポロジについて説明します。

ネットワークの図 - 鳥瞰図。

お客様は、プロバイダー エッジ (PE) ルーターを所有および管理します。 これらのルーターは、お客様のバックボーン ネットワークのエッジを表します。

Operator Nexus は、お客様のエッジ (CE) ルーターを管理します。 これらのルーターは Operator Nexus インスタンスの一部であり、ニアエッジ ハードウェアの部品表 (BOM) に含まれています。 各マルチラック Operator Nexus インスタンスには、2 つの CE ルーターがあります。 各 CE ルータには、各 PE ルーターへのアップリンクがあります。 CE ルータは、お客様のネットワークに物理的に接続されている唯一の Operator Nexus デバイスです。

マルチラック Azure Operator Nexus インスタンス内のコンピューティング サーバーの各ラックには、2 つの Top-of-Rack (TOR) スイッチがあります。 各 TOR には、各 CE ルーターへのアップリンクがあります。 各 TOR はラック内の各ベア メタル コンピューティング サーバーに接続され、単純なレイヤー 2 スイッチとして構成されます。

ベアメタル

このコンピューティング インフラストラクチャで実行されているテナント ワークロードは、通常、仮想またはコンテナー化されたネットワーク関数です。 仮想ネットワーク関数 (VNF) は、コンピューティング サーバー ハードウェア上で仮想マシン (VM) として実行されます。 コンテナー化されたネットワーク関数 (CMF) はコンテナー内で実行されます。 これらのコンテナーは、それ自体がコンピューティング サーバー ハードウェア上で実行される VM 上で実行されます。

エンド ユーザー データ プレーン サービスを提供するネットワーク関数を使用するには、高度な機能と高い I/O レートを提供するハイ パフォーマンスのネットワーク インターフェイスが必要です。

ネットワークの図 - ベア メタル。

ニアエッジのマルチラック Operator Nexus インスタンスでは、各ベア メタル コンピューティング サーバーは、非均一メモリ アクセス (NUMA) アーキテクチャ 備えたデュアル ソケット マシンです。

ニアエッジのマルチラック Azure Operator Nexus インスタンス内のベア メタル コンピューティング サーバーには、NUMA セルごとに 1 つのデュアルポート ネットワーク インターフェイス カード (pNIC) が含まれています。 これらの pNIC は、シングルルート I/O 仮想化 (SR-IOV) とその他の高パフォーマンス機能をサポートします。 1 つの NUMA セルは、1 つの pNIC とメモリおよび CPU が関連付けられています。

テナント ワークロードに割り当てられたすべてのネットワーク インターフェイスは、ホスト パススルー デバイスであり、ワークロード VM の CPU と メモリ リソースを収容する NUMAセル に関連付けられた pNIC から割り当てられた SR-IOV 仮想関数 (VF) を使用します。 この配置は、それらの VF が割り当てられた VM やコンテナー内のネットワーク スタックの最適なパフォーマンスが保証されます。

コンピューティング ラックは、1 組の Top-of-Rack (TOR) スイッチとともに導入されます。 各ベア メタル コンピューティング サーバー上の各 pNIC は、両方の TOR に接続されます。 マルチシャーシ リンク アグリゲーション グループ (MLAG) は高可用性を提供し、Link Aggregation Control Protocol (LACP) はリンクの合計スループットを強化します。

各ベア メタル コンピューティング サーバーには、"両方の" pNIC に接続された 2 つの "ホスト ローカル" 仮想関数 (VF) (VM ローカル VF ではなく) を集約するボンドによって提供されるストレージ ネットワーク インターフェイスがあります。 これら 2 つの VM はアクティブ バックアップ ボンドに集約され、いずれかの pNIC で障害が発生しても、ネットワーク ストレージ接続は使用可能なままになります。

論理ネットワーク リソース

Operator Nexus ネットワーク クラウド API とマネージド ネットワーク ファブリック API を操作する場合、ユーザーは一連の論理リソースを作成および変更します。

マネージド ネットワーク ファブリック API の論理リソースは、基になるネットワーク ハードウェア (TOR と CE) のネットワークとアクセス制御の構成に対応します。 特に、ManagedNetworkFabric.L2IsolationDomain および ManagedNetworkFabric.L3IsolationDomain リソースには、低レベルのスイッチとネットワーク構成が含まれています。 ManagedNetworkFabric.L2IsolationDomain は、仮想ローカル エリア ネットワーク 識別子 (VLAN) を表します。 ManagedNetworkFabric.L3IsolationDomain は、CE ルータにおける仮想ルーティングおよび転送構成 (VRF) を表します。 分離ドメインの概念について説明します。

ネットワーク クラウド API の論理リソースは、コンピューティング インフラストラクチャに対応します。 物理ラックとベア メタル ハードウェア用のリソースがあります。 同様に、Kubernetes クラスターと、そのハードウェア上で実行される仮想マシン、およびそれらを接続する論理ネットワーク用のリソースがあります。

NetworkCloud.L2Network、NetworkCloud.L3Network、および NetworkCloud.TrunkedNetwork はすべて、ワークロード ネットワークを表します。つまり、これらのネットワーク上のトラフィックはテナント ワークロードを対象とします。

NetworkCloud.L2Network はレイヤー 2 ネットワークを表し、ManagedNetworkFabric.L2IsolationDomain へのリンク以外はほとんど何も含まれていません。 この L2IsolationDomain には、VLAN 識別子と最大伝送単位 (MTU) 設定が含まれています。

NetworkCloud.L3Network はレイヤー 3 ネットワークを表し、VLAN 識別子、ネットワーク上のエンドポイントの IP アドレス割り当てに関する情報、および ManagedNetworkFabric.L3IsolationDomain へのリンクが含まれています。

Note

NetworkCloud.L3Network リソースに VLAN 識別子が含まれているのはなぜですか? VLAN はレイヤー 2 の概念ではないのですか?

はい、そうです。 その理由は、NetworkCloud.L3Network が特定の ManagedNetworkFabric.InternalNetwork を参照できる必要があるという事実によるものです。 ManagedNetworkFabric.InternalNetwork は、特定の ManagedNetworkFabric.L3IsolationDomain 内に作成され、VLAN 識別子が指定されます。 したがって、特定の ManagedNetworkFabric.InternalNetwork を参照するには、NetworkCloud.L3Network に L3IsolationDomain 識別子と VLAN 識別子の両方が含まれている必要があります。

ネットワークの図 - 論理リソース ビュー。

ネットワーク クラウド API における論理 "ネットワークリソース" (NetworkCloud.L3Network など) は、マネージド ネットワーク ファブリック API の論理リソースを "参照" し、そうすることで物理コンピューティング インフラストラクチャと物理ネットワーク インフラストラクチャの間の論理的な接続を提供します。

Nexus 仮想マシンを作成する際に、Nexus 仮想マシンの NetworkAttachments で 0 個以上の L2、L3、およびトランク ネットワークを指定できます。 Nexus Kubernetes クラスターを作成する際に、Nexus Kubernetes クラスターの NetworkConfiguration.AttachedNetworkConfiguration フィールドで 0 個以上の L2、L3、およびトランク ネットワークを指定できます。 エージェント プールは、Nexus Kubernetes クラスター内の類似の Kubernetes ワーカー ノードのコレクションです。 エージェント プールの AttachedNetworkConfiguration フィールドで、各エージェント プールのアタッチされた L2、L3、およびトランク ネットワークを構成できます。

スタンドアロンの Nexus 仮想マシンと Nexus Kubernetes クラスターの間でネットワークを共有できます。 この構成可能性により、同じ論理ネットワーク間で連携して動作する CMF と VNF を結合できます。

ネットワークの図 - 複雑なネットワークとコンピューティングのリレーションシップの例。

この図は、2 つのエージェントプールと、異なるワークロード ネットワークに接続されたスタンドアロンの Nexus 仮想マシンを備えた Nexus Kubernetes クラスターの例を示しています。 エージェント プール "AP1" には追加のネットワーク構成がないため、KubernetesCluster のネットワーク情報を継承します。 また、すべての Kubernetes ノードとすべてのスタンドアロン Nexus 仮想マシンが、同じ Cloud Services ネットワークに接続するように構成されていることにも注意してください。 最後に、エージェント プール "AP2" とスタンドアロン VM が "共有 L3 ネットワーク" に接続するように構成されます。

Cloud Services ネットワーク

Nexus 仮想マシンと Nexus Kubernetes クラスターは、常に "Cloud Services ネットワーク" (CSN) と呼ばれるものを参照します。 CSN は、オンプレミスのワークロードと一連の外部または Azure でホストされるエンドポイントとの間のトラフィックに使用される特別なネットワークです。

Cloud Services ネットワーク上のトラフィックはプロキシ経由でルーティングされ、エグレス トラフィックは許可リストを使用して制御されます。 ユーザーは、Network Cloud API を使用して、この許可リストを調整できます。

CNI ネットワーク

Nexus Kubernetes クラスターを作成する際に、NetworkConfiguration.CniNetworkId フィールドに NetworkCloud.L3Network のリソース識別子を指定します。

この "CNI ネットワーク" ("DefaultCNI ネットワーク" とも呼ばれます) は、Nexus Kubernetes クラスター内の Kubernetes ノードの IP アドレスを提供するレイヤー 3 ネットワークを指定します。

ネットワークの図 - 論理リソース ビュー - CNI L3 ネットワーク。

この図は、いくつかのネットワーク クラウド、マネージド ネットワーク ファブリック、および Kubernetes 論理リソースの間の関係を示しています。 この図で、NetworkCloud.L3Network は、レイヤー 3 ネットワークを表すネットワーク クラウド API の論理リソースです。 NetworkCloud.KubernetesCluster リソースには、NetworkCloud.L3Network リソースへの参照を含むフィールド networkConfiguration.cniNetworkId があります。

NetworkCloud.L3Network リソースは、l3IsolationDomainId および vlanId フィールドを介して 1 つの ManagedNetworkFabric.InternalNetwork リソースに関連付けられます。 ManagedNetworkFabric.L3IsolationDomain リソースには、vlanId によってキー指定された 1 つ以上の ManagedNetworkFabric.InternalNetwork リソースが含まれています。 ユーザーが NetworkCloud.KubernetesCluster リソースを作成すると、1 つ以上の NetworkCloud.AgentPool リソースが作成されます。

これらの各 NetworkCloud.AgentPool リソースは、1 つ以上の仮想マシンで構成されます。 Kubernetes Node リソースは、これらの各仮想マシンを表します。 これらの Kubernetes Node リソースは IP アドレスを取得する必要があり、仮想マシン上の Container Networking Interface (CNI) プラグインは NetworkCloud.L3Network に関連付けられた IP アドレスのプールから IP アドレスを取得します。 NetworkCloud.KubernetesCluster リソースは、cniNetworkId フィールドを介して NetworkCloud.L3Network を参照します。 これらのノード レベル IP アドレスのルーティングとアクセスのルールは、ManagedNetworkFabric.L3IsolationDomainに含まれています。 NetworkCloud.L3Network は、l3IsoldationDomainId フィールドを介して ManagedNetworkFabric.L3IsolationDomain を参照します。

Operator Nexus Kubernetes ネットワーク

Kubernetes には、次の 3 つの論理レイヤーのネットワークがあります。

  • ノード ネットワーク レイヤー
  • ポッド ネットワーク レイヤー
  • サービス ネットワーク レイヤー

"ノード ネットワーク レイヤー" は、Kubernetes コントロール プレーンと kubelet ワーカー ノード エージェント間の接続を提供します。

"ポッド ネットワーク レイヤー" は、Nexus Kubernetes クラスター内で実行されているコンテナー (ポッド) 間の接続と、ポッドと 1 つ以上のテナント定義ネットワークの間の接続を提供します。

"サービス ネットワーク レイヤー" は、関連するポッドのセットに対する負荷分散とイングレス機能を提供します。

ノード ネットワーク

Operator Nexus Kubernetes クラスターには、仮想マシン (VM) 上で実行される 1 つ以上のコンテナー化されたネットワーク関数 (CMF) が格納されます。 Kubernetes "ノード" は、1 つの VM を表します。 Kubernetes ノードは、"コントロール プレーン" ノードまたは "ワーカー" ノード のいずれかです。 コントロール プレーン ノードには、Kubernetes クラスターの管理コンポーネントが含まれています。 ワーカー ノードはテナント ワークロードを格納します。

Kubernetes ワーカー ノードのグループは、"エージェント プール" と呼ばれます。 エージェント プールは、Kubernetes コンストラクト "ではなく"、Operator Nexus コンストラクトです。

ネットワークの図 - ノード ネットワーク。

Operator Nexus インスタンス内の各ベア メタル コンピューティング サーバーには、ベア メタル サーバー上の単一の NUMA セルに関連付けられた switchdev があります。 switchdev は、さまざまなネットワークのルーティング テーブルを格納するために使用される一連のブリッジ デバイスへの接続を提供する、SR-IOV VF レプレゼンター ポートのセットを備えています。

defaultcni インターフェイスに加えて、Operator Nexus はすべてのノードで cloudservices ネットワーク インターフェイスを確立します。 cloudservices ネットワーク インターフェイスは、(お客様のオンプレミスの) 外部のエンドポイント宛てのトラフィックをルーティングする役割を担います。 cloudservices ネットワーク インターフェイスは、Nexus Kubernetes クラスターの作成前にユーザーが定義した NetworkCloud.CloudServicesNetwork API リソースに対応します。 cloudservices ネットワーク インターフェイスに割り当てられた IP アドレスはリンク ローカル アドレスであり、外部ネットワーク トラフィックが常にこの特定のインターフェイスを通過することを保証します。

defaultcni および cloudservices ネットワーク インターフェイスに加えて、Operator Nexus は、Nexus Kubernetes クラスターまたはエージェント プールと NetworkCloud.L2Network、NetworkCloud.L3Network、および NetworkCloud.TrunkedNetwork の関連付けに対応する 1 つ以上のネットワーク インターフェイスを各 Kubernetes ノードに作成します。

これらの追加のネットワーク インターフェイスを持つのは、エージェント プール VM だけです。 コントロール プレーン VM は、defaultcni および cloudservices ネットワーク インターフェイスのみを持ちます。

ノード IP アドレス管理 (IPAM)

ネットワークの図 - ノード ネットワーク - IP アドレス管理。

エージェント プール内のノードは、NetworkCloud.KubernetesCluster リソースの networkConfiguration.cniNetworkId フィールドで参照される NetworkCloud.L3Network リソースに関連付けられた IP アドレスのプールから IP アドレスを受け取ります。 この defaultcni ネットワークは、そのノードで実行されるすべてのポッドのデフォルト ゲートウェイであり、Nexus Kubernetes クラスター内のポッド間の東西通信の既定のネットワークとして機能します。

ポッド ネットワーク

Kubernetes ポッドは、Linux 名前空間で実行される 1 つ以上のコンテナー イメージのコレクションです。 この Linux 名前空間は、コンテナーのプロセスとリソースを、ホスト上の他のコンテナーとプロセスから分離します。 Nexus Kubernetes クラスターの場合、この "ホスト" は Kubernetes ワーカー ノードとして表される VM です。

Operator Nexus Kubernetes クラスターを作成する前に、ユーザーはまず、テナント ワークロードの割り当て元となる仮想ネットワークを表すリソースのセットを作成します。 これにより、Operator Nexus Kubernetes クラスターを作成するときに、これらの仮想ネットワークが cniNetworkId、cloudServicesNetworkId、agentPoolL2Networks、agentPoolL3Networks、および agentPoolTrunkedNetworks フィールドで参照されるようになります。

ポッドは、Operator Nexus インスタンス内の任意のラックの任意のコンピューティング サーバーで実行できます。 既定では、Nexus Kubernetes クラスター内のすべてのポッドは、"ポッド ネットワーク" と呼ばれるものを介して相互に通信できます。 各 Nexus Kubernetes ワーカー ノードにインストールされている複数の Container Networking Interface (CNI) プラグインによっIてポッド ネットワークが管理されます。

追加のネットワーク

Nexus Kubernetes クラスターでポッドを作成する際に、k8s.v1.cni.cnf.io/networks 注釈を指定することで、ポッドがアタッチする必要がある追加のネットワーク (ある場合) を宣言します。 注釈の値は、ネットワーク名のコンマ区切りリストです。 これらのネットワーク名は、Nexus Kubernetes クラスターまたはエージェント プールに関連付けられているトランク、L3、または L2 ネットワークの名前に対応します。

Operator Nexus は、NetworkAttachmentDefinition (NAD) ファイルを使用してエージェント プール VM を構成します。このファイルには、単一の追加ネットワークのネットワーク構成が含まれます。

ポッドの関連ネットワークにリストされているトランク ネットワークごとに、ポッドは 1 つのネットワーク インターフェイスを取得します。 ワークロードは、このインターフェイスを介して未加工のタグ付きトラフィックを送信するか、ネットワーク インターフェイス上にタグ付きインターフェイスを構築する役割を担います。

ポッドの関連ネットワークにリストされている L2 ネットワークごとに、ポッドは 1 つのネットワーク インターフェイスを取得します。 ワークロードの静的 MAC アドレス指定は、ワークロード自身が行います。

ポッド IP アドレス管理

ネットワークの図 - ポッド ネットワーク - IP アドレス管理。

Nexus Kubernetes クラスターを作成する際に、podCidrs フィールドにポッド ネットワークの IP アドレス範囲を指定します。 ポッドが起動すると、CNI プラグインはポッドに eth0@ifXX インターフェイスを確立し、その podCidrs フィールド内の IP アドレスの範囲から IP アドレスを割り当てます。

L3 ネットワークでは、ネットワークが Nexus IPAM を使用するように構成されている場合、L3 ネットワークに関連付けられているポッドのネットワーク インターフェイスは、そのネットワーク用に構成されている IP アドレス範囲 (CIDR) から IP アドレスを受け取ります。 L3 ネットワークが Nexus IPAM を使用するように構成されていない場合、ワークロードはポッドのネットワーク インターフェイスに IP アドレスを静的に割り当てる役割を担います。

ルーティング

各ポッド内では、eth0 インターフェイスのトラフィックは、defaultcni、cloudservices、およびその他のノード レベルのインターフェイスを収容したホスト (VM) 上の switchdev に接続された仮想イーサネット デバイス (veth) を通過します。

ポッド内の eth0 インターフェイスには、以下のトラフィックに対してワーカー ノード VM のルート テーブルを効果的に使用する単純なルート テーブルがあります。

ネットワークの図 - ポッド ルーティング。

  • ポッド間トラフィック: podCidrs アドレス範囲内の IP を宛先とするトラフィックは、ホスト VM 上の switchdev に送信され、ノード レベルの defaultcni インターフェースを経由して、適切な宛先エージェント プール VM の IP アドレスにルーティングされます。
  • L3 OSDevice ネットワーク トラフィック: OSDevice プラグイン タイプを持つ関連する L3 ネットワーク内の IP を宛先とするトラフィックは、ホスト VM 上の switchdev に送信され、その L3 ネットワークに関連付けられたノードレベルのインターフェイスを経由します。
  • その他のすべてのトラフィックはポッドのデフォルト ゲートウェイに渡され、ノード レベルの cloudservices インターフェイスにルーティングされます。 Nexus Kubernetes クラスターに関連付けられている Cloud Services ネットワークで構成されたエグレス ルールによって、トラフィックのルーティング方法が決まります。

ネットワークの図 - ポッド ルーティング - 追加インターフェイス。

ポッド内の追加のネットワーク インターフェイスは、ポッドのルート テーブルを使用して、SRIOV および DPDK プラグインの種類を使用する追加の L3 ネットワークにトラフィックをルーティングします。