AKS ノードをデプロイするためのネットワークの概念

適用対象: AKS on Azure Stack HCI 22H2、Windows Server 上の AKS

Arc で有効になっている AKS のネットワーク アーキテクチャには、2 つの IP アドレス割り当てモデルから選択できます。AKS では、Azure Kubernetes Service (AKS) の いつでもデプロイ オプション がサポートされます。

• 静的 IP ネットワーク: 仮想ネットワークは、Kubernetes クラスター API サーバー、Kubernetes ノード、基になる VM、ロード バランサー、クラスター上で実行されるすべての Kubernetes サービスに静的 IP アドレスを割り当てます。
• DHCP ネットワーク: 仮想ネットワークは、DHCP サーバーを使用して Kubernetes ノード、基になる VM、ロード バランサーに動的 IP アドレスを割り当てます。 Kubernetes クラスター API サーバーと、お使いのクラスター上で実行するすべての Kubernetes サービスには、まだ静的 IP アドレスが割り当てられています。

Note

ここで AKS Arc に対して定義されている仮想ネットワーク アーキテクチャは、データ センターの基になる物理ネットワーク アーキテクチャとは異なる場合があります。

仮想 IP プール

仮想 IP (VIP) プールは、AKS Arc でのデプロイに必須の IP アドレスのセットです。VIP プールは、Kubernetes クラスター API サーバーに IP アドレスを割り当てるために使用される予約済み IP アドレスの範囲です。 これにより、お使いのアプリケーションが常に到達可能であることが保証されます。 仮想ネットワーク モデル "および" 選択したアドレス割り当てモデルに関係なく、AKS ホストのデプロイ用の VIP プールを指定する必要があることに留意してください。

VIP プール内の IP アドレスの数は、ご自身のデプロイ内で実行されているワークロード クラスターと Kubernetes サービスの数によって異なります。

ネットワーク モデルによって、VIP プールの定義は次のように異なります。

• 静的 IP: 静的 IP を使用している場合は、仮想 IP アドレスが指定された同じサブネットからであることを確認します。
• DHCP: ネットワークが DHCP で構成されている場合は、ネットワーク管理者と協力して、AKS on Azure Stack HCI デプロイに使用される DHCP スコープから VIP プールの IP 範囲を除外します。

Kubernetes ノード VM IP プール

Kubernetes ノードは、AKS Arc に特殊な仮想マシンとしてデプロイされます。AKS はこれらの仮想マシンに IP アドレスを割り当てて、Kubernetes ノード間の通信を有効にします。

• 静的 IP: Kubernetes ノード VM の IP プール範囲を指定する必要があります。 この範囲内の IP アドレスの数は、AKS ホストおよびワークロード Kubernetes クラスター全体でデプロイに使用する計画の Kubernetes ノードの総数によって異なります。 更新プログラムでは、更新中に 1 ~ 3 個の追加 IP アドレスが使用されます。
• DHCP: Kubernetes ノードへの IP アドレスはネットワーク上の DHCP サーバーによって動的に割り当てられるので、Kubernetes ノード VM プールを指定する必要はありません。

静的 IP ネットワークを使用した仮想ネットワーク (推奨)

このネットワーク モデルにより、ご自身のデプロイ内のすべてのオブジェクトに対し、性的に定義されたアドレス プールから IP アドレスを割り当てる仮想ネットワークが作成されます。 静的 IP ネットワークを使用する付加的な利点として、長期間維持されるデプロイとアプリケーション ワークロードが常に到達可能であることが保証されます。

静的 IP 構成を使用して仮想ネットワークを定義する場合は、次のパラメーターを指定します。

重要

このバージョンの AKS では、AKS ホストまたはワークロード クラスターがデプロイされると、ネットワーク構成の変更は許可されません。 ネットワーク設定を変更するには、ワークロード クラスターを削除して AKS をアンインストールすることで、新しい作業を開始する必要があります。

• 名前: 仮想ネットワークの名前

• アドレスのプレフィックス: お使いのサブネットに使用する IP アドレスのプレフィックス。

• ゲートウェイ: サブネットの既定のゲートウェイの IP アドレス。

• DNS サーバー: サブネットに使用する DNS サーバーを指す IP アドレスの配列。 最小 1 台、最大 3 台のサーバーを指定できます。

• Kubernetes ノード IP プール: お使いの Kubernetes ノード VM に使用する連続した IP アドレス範囲。

• 仮想 IP プール: お使いの Kubernetes クラスター API サーバーと Kubernetes サービスに使用する連続した IP アドレス範囲。

  Note

  VIP プールは、Kubernetes ノード VM プールと同じサブネットに属している必要があります。

• vLAN ID: 仮想ネットワークの vLAN ID。 省略すると、仮想ネットワークにタグは付けされません。

DHCP ネットワークを使用した仮想ネットワーク

このネットワーク モデルにより、デプロイ内のすべてのオブジェクトに DHCP を使用して動的 IP アドレスを割り当てる仮想ネットワークが作成されます。

静的 IP 構成を使用して仮想ネットワークを定義する場合は、次のパラメーターを指定する必要があります。

• 名前: 仮想ネットワークの名前

• 仮想 IP プール: お使いの Kubernetes クラスター API サーバーと Kubernetes サービスに使用する連続した IP アドレス範囲。

  Note

  VIP プール アドレスは、DHCP スコープと同じサブネットに存在する必要があります。また、アドレスの競合を回避するために、DHCP スコープから除外する必要があります。

• vLAN ID: 仮想ネットワークの vLAN ID。 省略すると、仮想ネットワークにタグは付けされません。

Microsoft オンプレミス クラウド サービス

Microsoft オンプレミス クラウド (MOC) は、Azure Stack HCI および Windows Server ベースの SDDC 上の仮想マシンをクラウドで管理できるようにする管理スタックです。 MOC の構成は次のとおりです。

• クラスター上にデプロイされている可用性の高い cloud agent サービスの 1 つのインスタンス。 このエージェントは、Azure Stack HCI や Windows Server クラスター内の任意の 1 つのノードで実行され、別のノードにフェールオーバーするように構成されています。
• すべての Azure Stack HCI 物理ノードで実行されている node agent。

MOC との通信を有効にするには、サービスに使用する IP アドレス CIDR を指定する必要があります。 -cloudserviceCIDR は Set-AksHciConfig コマンドのパラメーターであり、クラウド エージェント サービスに IP アドレスを割り当て、クラウド エージェント サービスの高可用性を有効にするために使用されます。

MOC サービスの IP アドレスの選択は、Azure Stack HCI または Windows Server 上のクラスターデプロイで使用される基になるネットワーク モデルによって異なります。

Note

MOC サービスの IP アドレスの割り当ては、Kubernetes 仮想ネットワーク モデルに依存しません。 IP アドレスの割り当ては、基になる物理ネットワークと、データ センターの Azure Stack HCI または Windows Server クラスター ノード用に構成された IP アドレスに依存します。

• DHCP ベースの IP アドレス割り当てモードの Azure Stack HCI および Windows Server クラスター ノード: Azure Stack HCI ノードに物理ネットワーク上に存在する DHCP サーバーから IP アドレスが割り当てられている場合、MOC サービスも DHCP サーバーから IP アドレスを受信するため、MOC サービスに IP アドレスを明示的に指定する必要はありません。

• 静的 IP 割り当てモデルによる Azure Stack HCI and Windows Server クラスター ノード: ご自身の クラスター ノードに静的 IP アドレスが割り当てられている場合は、MOC クラウド サービスに対して IP アドレスを明示的に指定する必要があります。 MOC サービスの IP アドレスは、Azure Stack HCI and Windows Server クラスター ノードの IP アドレスと同じサブネット内に存在する必要があります。 MOC サービスに対して IP アドレスを明示的に割り当てるには、Set-AksHciConfig コマンドの -cloudserviceCIDR パラメーターを使用します。 IP アドレスは必ず CIDR 形式で入力します (例: "10.11.23.45/16")。

ネットワーク モデルを比較する

DHCP と静的 IP の両方で、AKS on Azure Stack HCI と Windows Server のデプロイでネットワーク接続が提供されます。 ただし、それぞれに長所と短所があります。 大まかに言えば、次の考慮事項が適用されます。

DHCP - AKS デプロイの一部のリソースの種類に対して、有効期間が長い IP アドレスは保証されません。 - ご自身のデプロイが最初に予想したよりも大きくなった場合の予約済み DHCP IP アドレスの拡張がサポートされます。

静的 IP - AKS デプロイ内のすべてのリソースの有効期間が長い IP アドレスを保証します。 - Kubernetes ノード IP プールの自動拡張はサポートされていないため、Kubernetes ノード IP プールを使い果たしたときに、新しいクラスターを作成できないことがあります。

次の表は、静的 IP ネットワーク モデルと DHCP ネットワーク モデルのリソースに対する IP アドレスの割り当てを比較したものです。

機能	[静的 IP]	[DHCP]
Kubernetes クラスター API サーバー	VIP プールを使用して静的に割り当てられます。	VIP プールを使用して静的に割り当てられます。
Kubernetes ノード (仮想マシン上)	Kubernetes ノード IP プールを使用して割り当てられます。	動的に割り当てられます。
Kubernetes サービス	VIP プールを使用して静的に割り当てられます。	VIP プールを使用して静的に割り当てられます。
HAProxy ロード バランサー VM	Kubernetes ノード IP プールを使用して割り当てられます。	動的に割り当てられます。
Microsoft オンプレミス クラウド サービス	Azure Stack HCI および Windows Server クラスター ノードの物理ネットワーク構成によって異なります。	Azure Stack HCI および Windows Server クラスター ノードの物理ネットワーク構成によって異なります。
VIP プール	必須	必須
Kubernetes ノード VM IP プール	必須	サポートされていません

AKS デプロイの最小 IP アドレス予約

予約済み IP アドレスの数は、デプロイ モデルに関係なく同じです。 このセクションでは、AKS Arc デプロイ モデルに基づいて予約する必要がある IP アドレスの数について説明します。

最小 IP アドレス予約

少なくとも、次の数の IP アドレスをご自身のデプロイに対して予約する必要があります。

クラスターの種類	コントロール プレーン ノード	ワーカー ノード	更新操作	Load Balancer
AKS ホスト	1 つの IP	NA	2 つの IP	NA
ワークロード クラスター	ノードごとに 1 つの IP	ノードごとに 1 つの IP	5 IP	1 つの IP

さらに、次の数の IP アドレスをご自身の VIP プールに対して予約する必要があります。

リソースの種類	IP アドレスの数
クラスター API サーバー	クラスターあたり 1
Kubernetes サービス	サービスあたり 1
アプリケーション サービス	計画されるサービスあたり 1

ご覧のように、必要な IP アドレスの数は、AKS デプロイのアーキテクチャと、Kubernetes クラスターで実行するサービスの数によって異なります。 お使いのデプロイに対して最小でも 256 個の IP アドレス (/24 サブネット) を予約することをお勧めします。

デプロイ例の手順

Jane は、Azure Arc で有効になっている AKS から始めたばかりの IT 管理者です。彼女は、2 つの Kubernetes クラスター (Kubernetes クラスター A と Kubernetes クラスター B) を Azure Stack HCI クラスターにデプロイしたいと考えています。 また、自分のクラスター上で投票アプリケーションを実行したいとも考えています。 このアプリケーションには、2 つのクラスターと、バックエンド データベースの 1 つのインスタンスにわたって実行されている、フロントエンド UI の 3 つのインスタンスがあります。

• Kubernetes クラスター A には、3 つのコントロール プレーン ノードと 5 つのワーカー ノードがあります。
• Kubernetes クラスター B には、1 つのコントロール プレーン ノードと 3 つのワーカー ノードがあります。
• フロントエンド UI の 3 つのインスタンス (ポート 443)。
• バックエンド データベースの 1 つのインスタンス (ポート 80)。

前の表に基づいて、次を予約する必要があります。

• AKS ホストの 3 つの IP アドレス (コントロール プレーン ノード用に 1 つの IP、更新操作を実行するための 2 つの IP)。
• クラスター A のコントロール プレーン ノードの 3 つの IP アドレス (コントロール プレーン ノードごとに 1 つの IP)。
• クラスター A のワーカー ノードの 5 つの IP アドレス (ワーカー ノードごとに 1 つの IP)。
• クラスター A の 6 つの IP アドレス (更新操作を実行するための 5 つの IP とロード バランサー用の 1 つの IP)。
• クラスター B 内のコントロール プレーン ノードの 1 つの IP アドレス (コントロール プレーン ノードごとに 1 つの IP)。
• クラスター B のワーカー ノードの 3 つの IP アドレス (ワーカー ノードごとに 1 つの IP)。
• クラスター B に 6 つの IP アドレス (更新操作を実行するための 5 つの IP とロード バランサー用の 1 つの IP)。
• Kubernetes クラスター API サーバーの 2 つの IP アドレス (Kubernetes クラスターごとに 1 つの IP)。
• Kubernetes サービスの 3 つの IP アドレス (フロントエンド UI のインスタンスごとに 1 つの IP アドレス。これらはすべて同じポートを使用するため)。バックエンド データベースは、別のポートを使用する限り、3 つの IP アドレスのいずれかを使用できます)。

前述のように、Jane はクラスターをデプロイするために合計 32 個の IP アドレスを必要とします。 そのため、Jane は、自分の仮想ネットワーク用に /26 サブネットを予約する必要があります。

静的 IP ネットワーク モデルに基づく予約済み IP アドレスの分割

予約済み IP アドレスは、合計数は同じですが、IP グループ間でどのように分割されるかはデプロイ モデルによって決まります。 静的 IP ネットワーク モデルには、次の 2 つの IP プールがあります。

• Kubernetes ノード VM IP プール: Kubernetes ノード VM とロード バランサー VM 用。 この IP プールには、更新操作の実行に必要な IP アドレスも含まれています。
• 仮想 IP プール: Kubernetes API サーバーと Kubernetes サービス用。

この例では、Jane は、VIP プールと Kubernetes ノード IP プール間でこれらの IP アドレスをさらに分割する必要があります。

• 32 個の IP アドレスのうち、自分の VIP プール用に 5 つ (Kubernetes クラスター API サーバー用に 2 つ、Kubernetes サービス用に 3 つ)。
• Kubernetes ノード IP プール用に 27 個 (すべての IP アドレスが、Kubernetes ノード IP プールと基礎となる VM、ロード バランサー VM、および更新操作用)。

DHCP ネットワーク モデルに基づく予約済み IP アドレスの分割

予約済み IP アドレスは、合計数は同じですが、IP グループ間でどのように分割されるかはデプロイ モデルによって決まります。 前のセクションで説明したように、DHCP ネットワーク モデルには次の 1 つの IP スコープがあります。

• 仮想 IP プール: Kubernetes API サーバーと Kubernetes サービス用

前の例の操作:

• Jane は、自分の DHCP サーバー上で合計 32 個の IP アドレスまたは /26 サブネットを予約する必要があります。
• Jane は、32 個の IP アドレスの DHCP スコープから、自分の VIP プール用に 5 つ (Kubernetes クラスター API サーバー用に 2 つ、Kubernetes サービス用に 3 つ) を除外しなければなりません。

イングレス コントローラー

ターゲット クラスターのデプロイ中に、HAProxy ベースのロード バランサー リソースが作成されます。 ロード バランサーは、特定のポートでサービス内のポッドにトラフィックを分散するように構成されます。 ロード バランサーはレイヤー 4 でのみ機能します。これは、サービスが実際のアプリケーションを認識していることを示します。つまり、ルーティングに関する追加の考慮事項を行うことはできません。

イングレス コントローラーはレイヤー 7 で動作し、よりインテリジェントなルールを使用してアプリケーションのトラフィックを分散させることができます。 イングレス コントローラーの一般的な用途は、受信 URL に基づいて異なるアプリケーションに HTTP トラフィックをルーティングすることです。

次のステップ

この記事では Azure Stack HCI で AKS ノードをデプロイするためのネットワークの概念について説明します。 詳細については、次の記事をご覧ください。

• コンテナー ネットワークの概念
• クラスターとワークロード
• Kubernetes ワークロード クラスターをデプロイする