適用対象: AKS on Azure Local
AKS 対応 Azure Arc 用 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 | Azure Arc は、ローリング アップグレードを実行するため、Kubernetes のアップグレード操作用に AKS Arc クラスターごとに 1 つの IP アドレスを予約します。 | Arc VM 論理ネットワークの IP プールで IP アドレスを予約します。 |
| コントロール プレーン IP | お使いの環境の各 Kubernetes クラスターに対して 1 つの IP アドレスを予約します。 たとえば、合計で 5 つのクラスターを作成する場合、各 Kubernetes クラスターに対して 1 つずつ、合計 5 つの IP アドレスを予約します。 | Arc VM 論理ネットワークの IP プールで IP アドレスを予約します。 |
| Load balancer IP | 予約する IP アドレスの数は、アプリケーション デプロイ モデルによって異なります。 開始点として、各 Kubernetes サービスに 1 つの IP アドレスを予約します。 | Arc VM 論理ネットワークと同じサブネットで、IP プール外で、IP アドレスを予約します。 |
Kubernetes クラスターとアプリケーションの IP アドレス予約のウォークスルー例
Jane は、IT 管理者で Azure Arc が有効化した AKS を使い始めたばかりです。Jane は、Azure Local クラスターに Kubernetes クラスター A と Kubernetes クラスター B の 2 つのKubernetes クラスターをデプロイしたいと思っています。 Jane は、クラスター A で投票アプリケーションも実行したいと考えており、このアプリケーションには、2 つのクラスター間で実行されるフロントエンド UI の 3 つのインスタンスとバックエンド データベースの 1 つのインスタンスがあります。 すべての AKS クラスターとサービスは、1 つのネットワークの 1 つのサブネット内で実行されています。
- Kubernetes クラスター A には 3 つのコントロール プレーン ノードと 5 つのワーカー ノードがあります。
- Kubernetes クラスター B には 1 つのコントロール プレーン ノードと 3 つのワーカー ノードがあります。
- フロントエンド UI の 3 つのインスタンス (ポート 443)。
- バックエンド データベースの 1 つのインスタンス (ポート 80)。
前のテーブルに基づいて、Jane は、Jane のサブネットに合計 19 のIP アドレスを予約する必要があります。
- クラスター A の AKS Arc ノード VM 用に 8 つの IP アドレス (K8 ノード VM 1 つに対して 1 つの IP)。
- クラスター B の AKS Arc ノード VM 用に 4 つの IP アドレス (K8 ノード VM 1 つに対して 1 つの IP)。
- 実行中の AKS Arc アップグレード操作に対して 2 つの IP アドレス (AKS Arc クラスター 1 つに対して 1 つの IP)。
- AKS Arc コントロール プレーンに対して 2 つのIP アドレス (AKS Arc クラスター 1 つに対して 1 つの IP)
- Kubernetes サービスに対して 3 つの IP アドレス (これらすべてが同じポートを使用するため、フロントエンド UI のインスタンス 1 つに対して 1 つの IP。別のポートを使用している限り、バックエンド データベースは、3 つの IP アドレスから任意の IP アドレスを使用できます)。
この例を続けて、次のテーブルに加えると、以下のようになります。
| パラメーター | IP アドレスの数 | 予約方法と場所 |
|---|---|---|
| AKS Arc VM、K8 バージョン アップグレードおよびコントロール プレーン IP | 予約済みの 16 つの IP アドレス | Azure Local 論理ネットワークの IP プール経由でこの予約を作成します。 |
| Load balancer IP | Kubernetes サービスに対して 3 つの IP アドレス、Jane の投票アプリケーション向け。 | これらの 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に対して個別に論理ネットワークを定義します。
Azure Local の AKS と Arc VM で論理ネットワークを共有すると、通信費用を節約でき、ネットワーク管理がシンプルになります。 ただし、この方法には、リソースの競合、セキュリティーのリスク、トラブルシューティングの複雑さといった潜在的な課題もあります。
| 条件 | 論理ネットワークの共有 | 個別の論理ネットワークの定義 |
|---|---|---|
| 構成の複雑性 | 1 つのネットワークでのシンプルな構成で、セットアップの複雑性を軽減できます。 | VM や AKS クラスター用に複数の論理ネットワークを構成する必要があるため、セットアップがより複雑になります。 |
| スケーラビリティ | Arc VM と AKS クラスターの両方がネットワーク リソースを共有するため、スケーラビリティに制約が生じる可能性があります。 | ネットワーク リソースが分離され、独立して拡張できるため、拡張性が高くなります。 |
| ネットワーク ポリシー管理 | 1 セットのネットワーク ポリシーで管理するのは簡単ですが、ワークロードを分離するのは難しくなります。 | 論理ネットワークごとに個別のポリシーを適用できるため、ワークロードの分離が容易になります。 |
| セキュリティの考慮事項 | 適切にセグメント化されていない場合、相互通信の脆弱性のリスクが高まります。 | 各ネットワークをセグメント化し、より厳密に分離できるため、セキュリティが向上します。 |
| ネットワーク障害による影響 | 共有ネットワークの障害は、AKS と Arc VM の両方に同時に影響を与える可能性があります。 | 1 つのネットワークで障害が発生した場合、そのネットワーク内のワークロードにのみ影響が及ぶため、全体的なリスクが軽減されます。 |
ポッド CIDR とサービス CIDR に対して IP アドレス範囲を割り当てる
このセクションでは、クラスター内のポッドとサービスの通信に Kubernetes が使用する IP アドレス範囲について説明します。 これらの IP アドレス範囲は、AKS クラスターの作成プロセスで定義され、クラスタ内のポッドとサービスに一意の IP アドレスを割り当てるために使用されます。
ポッド ネットワーク CIDR
ポッド ネットワーク CIDR は、Kubernetes クラスター内で実行されている個々のポッドに固有の IP アドレスを割り当てるために Kubernetes が使用する IP アドレスの範囲です。 各ポッドはこの範囲内で自分の IP アドレスを取得し、ポッド同士やクラスター内のサービスと通信できるようにします。 AKS では、ポッド IP アドレスは VXLAN モードの Calico CNI を介して割り当てられます。 Calico VXLAN はオーバーレイ ネットワークの作成をサポートし、そこではポッドの IP アドレス (ポッド ネットワーク CIDR から) が仮想化され、物理ネットワーク経由でトンネル化されます。 このモードでは、各ポッドにポッド ネットワーク 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 のカスタマイズをサポートしていません。