次の方法で共有

IP アドレス計画の要件

  • [アーティクル]

適用対象: Azure Local バージョン 23H2

Azure Arc で有効になっている AKS の IP アドレス計画には、アプリケーション、ノード プール、ポッド ネットワーク、サービス通信、外部アクセスをサポートするネットワークの設計が含まれます。 この記事では、効果的な IP アドレス計画に関するいくつかの重要な考慮事項と、運用環境での AKS のデプロイに必要な IP アドレスの最小数について説明します。 この記事を読む前に、 AKS ネットワークの概念と要件 を参照してください。

Kubernetes クラスターとアプリケーションの単純な IP アドレス計画

次のシナリオのチュートリアルでは、Kubernetes クラスターとサービス用に 1 つのネットワークから IP アドレスを予約します。 この例は、IP アドレス割り当ての最も簡単で簡単なシナリオです。

IP アドレスの要件 IP アドレスの最小数 この予約の方法と場所
AKS Arc VM IP Kubernetes クラスター内のワーカー ノードごとに 1 つの IP アドレスを予約します。 たとえば、各ノード プールに 3 つのノードを含む 3 つのノード プールを作成する場合は、IP プールに 9 つの IP アドレスが必要です。 Arc VM 論理ネットワーク内の IP プールを介して IP アドレスを予約します。
AKS Arc K8s バージョンアップグレード IP AKS Arc はローリング アップグレードを実行するため、Kubernetes バージョンのアップグレード操作のために、AKS Arc クラスターごとに 1 つの IP アドレスを予約します。 Arc VM 論理ネットワーク内の IP プールを介して IP アドレスを予約します。
コントロール プレーン IP 環境内の Kubernetes クラスターごとに 1 つの IP アドレスを予約します。 たとえば、合計で 5 つのクラスターを作成する場合は、Kubernetes クラスターごとに 1 つずつ、5 つの IP アドレスを予約します。 Arc VM 論理ネットワーク内の IP プールを介して IP アドレスを予約します。
ロード バランサー IP 予約されている IP アドレスの数は、アプリケーションのデプロイ モデルによって異なります。 開始点として、Kubernetes サービスごとに 1 つの IP アドレスを予約できます。 Arc VM 論理ネットワークと同じサブネット内の IP アドレスを予約しますが、IP プールの外部で予約します。

Kubernetes クラスターとアプリケーションの IP アドレス予約のチュートリアル例

Jane は、Azure Arc で有効になっている AKS から始めたばかりの IT 管理者です。Jane は、Kubernetes クラスター A と Kubernetes クラスター B という 2 つの Kubernetes クラスターを Azure ローカル クラスターにデプロイしたいと考えています。 Jane はまた、クラスター A の上に投票アプリケーションを実行したいと考えています。このアプリケーションには、2 つのクラスターとバックエンド データベースの 1 つのインスタンスで実行されているフロントエンド UI の 3 つのインスタンスがあります。 すべての AKS クラスターとサービスは、1 つのサブネットを持つ単一のネットワークで実行されています。

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

前の表に基づいて、Jane は Jane のサブネットに合計 19 個の IP アドレスを予約する必要があります。

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

この例に進み、次の表に追加すると、次のようになります。

パラメーター IP アドレスの数 この予約の方法と場所
AKS Arc VM、K8s バージョンのアップグレード、コントロール プレーン IP 16 個の IP アドレスを予約する この予約は、Azure ローカル論理ネットワークの IP プールを介して行います。
ロード バランサー IP Jane の投票アプリケーション用の Kubernetes サービスの 3 つの IP アドレス。 これらの IP アドレスは、クラスター A にロード バランサーをインストールするときに使用されます。MetalLB Arc 拡張機能を使用することも、独自のサード パーティのロード バランサーを使用することもできます。 この IP が Arc 論理ネットワークと同じサブネット内にあり、Arc VM 論理ネットワークで定義されている IP プールの外部にあることを確認します。

Kubernetes クラスターとアプリケーションの IP アドレス予約の CLI コマンドの例

このセクションでは、Jane が自分のシナリオで実行する一連のコマンドについて説明します。 まず、少なくとも 16 個の IP アドレスを持つ IP プールを持つ論理ネットワークを作成します。 20 個の IP アドレスを持つ IP プールを作成し、N 日にスケーリングするオプションを提供しました。論理ネットワークのパラメーター オプションの詳細については、 az stack-hci-vm network lnet createを参照してください。

$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd

次に、前の論理ネットワークを使用して AKS Arc クラスターを作成します。

az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys

これで、Arc VM 論理ネットワークと同じサブネットで、3 つの IP アドレスの IP プールで MetalLB ロード バランサーを有効にすることができます。 アプリケーションで増加が必要な場合は、後でさらに IP プールを追加できます。 詳細な要件については、 MetalLB Arc 拡張機能の概要を参照してください。

az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP

AKS クラスターと Arc VM の LNET に関する考慮事項

Azure Local 上の論理ネットワークは、AKS クラスターと Arc VM の両方で使用されます。 論理ネットワークは、次の 2 つの方法のいずれかで構成できます。

  • AKS と Arc VM の間で論理ネットワークを共有します。
  • AKS クラスターと Arc VM 用に個別の論理ネットワークを定義します。

AKS と Azure Local 上の Arc VM 間で論理ネットワークを共有すると、通信の合理化、コスト削減、ネットワーク管理の簡素化という利点があります。 ただし、この方法では、リソースの競合、セキュリティ リスク、トラブルシューティングの複雑さなどの潜在的な課題も発生します。

条件 論理ネットワークの共有 個別の論理ネットワークの定義
構成の複雑さ 1 つのネットワークを使用した構成がシンプルで、セットアップの複雑さが軽減されます。 VM と AKS クラスター用に複数の論理ネットワークを構成する必要がある場合は、より複雑なセットアップです。
スケーラビリティ Arc VM と AKS クラスターの両方がネットワーク リソースを共有するため、スケーラビリティの制限が考えられます。 ネットワーク リソースは分離され、個別にスケーリングできるため、よりスケーラブルです。
ネットワーク ポリシー管理 1 セットのネットワーク ポリシーを使用して管理する方が簡単ですが、ワークロードを分離するのは困難です。 論理ネットワークごとに個別のポリシーを適用できるため、ワークロードの分離が容易になります。
セキュリティに関する考慮事項 適切にセグメント化されていない場合、通信間の脆弱性のリスクが高まります。 各ネットワークをより厳密にセグメント化して分離できるため、セキュリティが向上します。
ネットワーク障害の影響 共有ネットワークの障害は、AKS VM と Arc VM の両方に同時に影響する可能性があります。 1 つのネットワークで障害が発生すると、そのネットワーク内のワークロードのみが影響を受け、全体的なリスクが軽減されます。

ポッド CIDR とサービス CIDR の IP アドレス範囲の割り当て

このセクションでは、クラスター内のポッドとサービスの通信に Kubernetes によって使用される IP アドレス範囲について説明します。 これらの IP アドレス範囲は、AKS クラスターの作成プロセス中に定義され、クラスター内のポッドとサービスに一意の IP アドレスを割り当てるために使用されます。

ポッド ネットワーク CIDR

ポッド ネットワーク CIDR は、Kubernetes クラスター内で実行されている個々のポッドに一意の IP アドレスを割り当てるために Kubernetes によって使用される一連の IP アドレスです。 各ポッドは、この範囲内で独自の IP アドレスを取得し、ポッドが相互に通信し、クラスター内のサービスと通信できるようにします。 AKS では、VXLAN モードの Calico CNI を介してポッド IP アドレスが割り当てられます。 Calico VXLAN は、(ポッド ネットワーク CIDR からの) ポッドの IP アドレスが仮想化され、物理ネットワーク経由でトンネリングされる、 Overlay ネットワークを作成するのに役立ちます。 このモードでは、各ポッドにはポッド ネットワーク CIDR からの IP アドレスが割り当てられますが、この IP アドレスは物理ネットワーク上で直接ルーティングできません。 代わりに、ネットワーク パケット内にカプセル化され、基になる物理ネットワークを介して送信され、別のノード上の宛先ポッドに到達します。

AKS では、ポッド ネットワーク CIDR の 既定値として 10.244.0.0/16 が提供されます。 AKS では、ポッド ネットワーク CIDR のカスタマイズがサポートされています。 AKS クラスターの作成時に、 --pod-cidr パラメーターを使用して独自の値を設定できます。 CIDR IP 範囲が、ノードあたりのポッドの最大数と Kubernetes クラスター全体に対応できる十分な大きさであることを確認します。

サービス ネットワーク CIDR

サービス ネットワーク CIDR は、クラスター内の LoadBalancers、ClusterIP、NodePort などの Kubernetes サービス用に予約された IP アドレスの範囲です。 Kubernetes では、次のサービスの種類がサポートされています。

  • ClusterIP: クラスター内のサービスを公開する既定のサービスの種類。 サービス ネットワーク CIDR から割り当てられた IP には、Kubernetes クラスター内でのみアクセスできます。
  • NodePort: 各ノードの IP アドレス上の特定のポートでサービスを公開します。 ClusterIP は内部で引き続き使用されますが、外部アクセスはノード IP と特定のポートを介して行われます。
  • LoadBalancer: この型は、クラウド プロバイダーで管理されるロード バランサーを作成し、サービスを外部に公開します。 クラウド プロバイダーは通常、外部 IP 割り当てを管理しますが、内部 ClusterIP はサービス ネットワーク CIDR 内に残ります。

AKS では、サービス ネットワーク CIDR に対して 10.96.0.0/12 既定値が提供されます。 現在、AKS では、サービス ネットワーク CIDR のカスタマイズはサポートされていません。

次のステップ

Azure Local バージョン 23H2 で Kubernetes クラスターの論理ネットワークを作成する