AKS ハイブリッドに AKS ノードをデプロイするためのネットワークの概念
適用対象: AKS on Azure Stack HCI、Windows Server 上の AKS
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 ハイブリッド用にここで定義されている仮想ネットワーク アーキテクチャは、データ センター内の基になる物理ネットワーク アーキテクチャとは異なる場合があります。
仮想 IP プール
仮想 IP (VIP) プールは、AKS ハイブリッドでのデプロイに必須の IP アドレスのセットです。 VIP プールは、IP アドレスを Kubernetes クラスター API サーバーに割り当てる際に使用される、予約済み 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 ハイブリッドに特殊な仮想マシンとしてデプロイされます。 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 構成を使用して仮想ネットワークを定義する場合は、次のパラメーターを指定する必要があります。
重要
このバージョンの AKS では、AKS ホストまたはワークロード クラスターがデプロイされると、ネットワーク構成を変更することはできません。 ネットワーク設定を変更する唯一の方法は、ワークロード クラスターを削除して AKS をアンインストールすることで新たに開始することです。
名前: 仮想ネットワークの名前
仮想 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 and Windows Server クラスター ノード: Azure Stack HCI ノードに物理ネットワーク上に存在する DHCP サーバーから IP アドレスが割り当てられている場合は、MOC サービスが DHCP サーバーから IP アドレスも受信するため、IP アドレスを MOC サービスに明示的に指定する必要はありません。
静的 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 and Windows Server クラスター ノードの物理ネットワーク構成によって異なる | Azure Stack HCI and Windows Server クラスター ノードの物理ネットワーク構成によって異なる |
| VIP プール | Mandatory | Mandatory |
| Kubernetes ノード VM IP プール | Mandatory | サポートされていません |
AKS ハイブリッドデプロイの最小 IP アドレス予約
予約済み IP アドレスの数は、デプロイ モデルに関係なく同じです。 このセクションでは、AKS ハイブリッド デプロイ モデルに基づいて予約する必要がある 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 は、AKS から始めたばかりの IT 管理者です。 彼女は、Kubernetes クラスター A と Kubernetes クラスター B の 2 つの Kubernetes クラスターを、自分の 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 のインスタンスごとに IP アドレスが 1 つずつ。バックエンド データベースでは、使用しているポートが異なっていれば、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 は次の IP アドレスを、さらに複数の VIP プールと Kubernetes ノード 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 ノードをデプロイするためのネットワークの概念について説明します。 詳細については、次の記事を参照してください。