Azure Stack Hub のカスタム仮想ネットワークに Kubernetes クラスターをデプロイする
カスタム仮想ネットワークで Azure Kubernetes Service (AKS) エンジンを使用して Kubernetes クラスターをデプロイできます。 この記事では、仮想ネットワークで必要な情報を見つける方法について説明します。 この記事には、クラスターで使用される IP アドレスの計算、API モデルでの vale の設定、ルート テーブルとネットワーク セキュリティ グループの設定の手順が含まれています。
AKS エンジンを使用する Azure Stack Hub の Kubernetes クラスターでは、kubenet ネットワーク プラグインが使用されます。 Azure Stack Hub 上の AKS エンジンは、Azure CNI ネットワーク プラグインもサポートしています。
- Azure の kubenet ネットワーク プラグインの詳細については、「Azure Kubernetes Service (AKS) の独自の IP アドレス範囲で kubenet ネットワークを使用する」を参照してください。
- Azure の Azure CNI ネットワーク プラグインの詳細については、「Azure Kubernetes Service (AKS) で Azure CNI ネットワークを構成する」を参照してください。
カスタム仮想ネットワークを作成するときの考慮事項
- カスタム VNET は、Kubernetes クラスターのその他すべてのコンポーネントと同じサブスクリプションに存在する必要があります。
- コントロール プレーン ノードのプールとエージェント ノードのプールは、同じ仮想ネットワークに存在する必要があります。 同じ仮想ネットワーク内の異なるサブネットにノードをデプロイすることはできます。
- Kubernetes クラスター サブネットは、カスタム仮想ネットワーク IP 範囲内の IP 範囲を使用する必要があります。 「IP アドレス ブロックを取得する」を参照してください。
- ノード サブネットの推奨サイズは、使用されているネットワーク プラグインの種類によって異なると考えてください。 一般的なガイドラインとして、エージェント ノード プールをサポートするサブネットに必要な IP アドレスの数は、kubenet より Azure CNI の方が多くなります。 次の kubenet と Azure CNI の例を示します。
169.254.0.0/16アドレス空間は、Kubernetes クラスターのカスタム VNET には使用できません。
カスタム仮想ネットワークを作成する
Azure Stack Hub インスタンスにカスタム仮想ネットワークが必要です。 詳細については、「クイック スタート: Azure portal を使用した仮想ネットワークの作成」を参照してください。
仮想ネットワークの新しいサブネットを作成します。 クラスターをデプロイするときに API モデルで使用するサブネット リソース ID と IP アドレス範囲を取得する必要があります。
Azure Stack Hub インスタンスで Azure Stack Hub ユーザー ポータルを開きます。
[すべてのリソース] を選択します。
検索ボックスに仮想ネットワークの名前を入力します。
サブネットを追加するには [サブネット]>[+ サブネット] を選択します。
CIDR 表記を使用して [名前] と [アドレス範囲] を追加します。 [OK] を選択します。
[仮想ネットワーク] ブレードで、[プロパティ] を選択します。 [リソース ID] フィールドをコピーし、
/subnets/<nameofyoursubnect>を追加します。 この値は、クラスターの API モデルのvnetSubnetIdキーの値として使用します。 サブネットのリソース ID は、次の形式を使用します:/subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME。
[仮想ネットワーク] ブレードで、[サブネット] を選択します。 サブネット名を選択します (
control-plane-snなど)。 サブネットをネットワーク セキュリティ グループ (NSG) に関連付けないでください。
サブネット ブレードで、各サブネットのアドレス範囲 (CIDR ブロック) を記録しておきます。
アドレス空間を選択する場合の考慮事項
カスタム仮想ネットワークを作成するときに、ネットワークの IP アドレス空間と、すべてのサブネットの IP アドレス範囲を指定します。 Kubernetes クラスターで使用するアドレス空間と範囲を選択するときは、次の点を考慮してください。
- アドレス空間が重複していると、IP アドレスの競合や通信エラーが発生するおそれがあります。 IP アドレスの重複のリスクを軽減するには、新しい仮想ネットワーク用に一意のアドレス空間を選択します。
10/8、172.16/12、192.168/16の範囲内のアドレス空間は、プライベート ネットワークによく使用されているため、既存のデータセンター インフラストラクチャで使用されている可能性があります。 Kubernetes アプリケーションでデータセンターのリソースが使用されている場合は、データセンターのアドレス空間とは異なるカスタム仮想ネットワークのアドレス空間を選択することで、競合のリスクを軽減します。- Kubernetes クラスターには専用サブネットを使用することをお勧めします。
- 複数の既存の仮想ネットワークを使用する場合は、仮想ネットワーク ピアリングを使用する場合は、各ネットワークで異なるアドレス空間を使用することを検討してください。 アドレス空間が重複すると、ピアリングを有効にする機能が損なわれる可能性があります。
IP アドレス ブロックを取得する
AKS エンジンは、既存の仮想ネットワークへのデプロイをサポートします。 既存の仮想ネットワークにデプロイすると、クラスターは、エージェント ノード、コントロール プレーン ノード、クラスター サービス、コンテナー (ポッド) に連続するアドレスのブロックを使用します。 各アドレス ブロックは、仮想ネットワーク内のサブネットに変換できます。 クラスターデプロイ内のすべてのアドレス ブロックは、仮想ネットワークのアドレス空間全体の一部である必要があります。 仮想ネットワーク アドレス空間の外部でアドレス ブロックを選択すると、接続の問題が発生する可能性があります。
Kubernetes クラスターを設定するときは、少なくとも 3 つのアドレス ブロックが必要です。
- ノード アドレス ブロック: クラスター ノードにアドレスを割り当てるために使用されるアドレス ブロック。 この値は、すべてのクラスター ノードに対して 1 つのアドレス ブロックにすることも、コントロール プレーンとエージェント プール用に個別のブロック (サブネット) にすることもできます。 このブロックのアドレス範囲を選択するときは、クラスター内のノード数を考慮してください。 Azure CNI の場合、ノードとコンテナーは同じアドレス ブロックからアドレスを取得するため、Azure CNI を使用するときにアドレス範囲を選択するときにクラスターにデプロイするコンテナーの数が考慮されます。
- サービス アドレス ブロック: Kubernetes クラスターにデプロイされたサービスのクラスター アドレスの取得元のアドレス ブロック。 このブロックのアドレス範囲を選択するときは、クラスターで実行するサービスの最大数を考慮します。
- クラスター アドレス ブロック: ポッドがクラスター アドレスを取得するアドレス ブロック。 このブロックのアドレス範囲を選択するときは、クラスターで実行するポッドの最大数を考慮します。 前に説明したように、Azure CNI の場合、クラスターとノードのアドレス ブロックは同じです。
アドレス ブロックに加えて、コントロール プレーン ノードの場合は、さらに 2 つの値を設定する必要があります。 クラスター用に予約する IP アドレスの数と、サブネット IP 空間内の最初の連続する静的 IP を把握する必要があります。 複数のコントロール プレーン ノードを使用する場合、AKS エンジンには最大 16 個の未使用 IP アドレスの範囲が必要です。 クラスターは、コントロール プレーンごとに最大 5 つのコントロール プレーン ノードに 1 つの IP アドレスを使用します。 AKS エンジンでは、ヘッドルーム IP アドレス予約の最後のコントロール プレーン ノードの後に次の 10 個の IP アドレスも必要です。 最後に、コントロール プレーン ノードとヘッドルーム予約の後に、ロード バランサーによって合計 16 の別の IP アドレスが使用されます。 IP アドレスのブロックを配置する場合、サブネットでは既存の IP アドレスの次の割り当てが必要になります。
- 最初の 4 つの IP アドレスと最後の IP アドレスは予約されており、どの Azure サブネットでも使用できません。
- 16 個の IP アドレスのバッファーをオープンにしたままにする必要があります。
- IP の競合を回避するには、クラスターの最初の IP アドレスの値をアドレス空間の末尾に配置する必要があります。 可能であれば、サブネット内の使用可能な IP アドレス空間の
firstConsecutiveStaticIPの近くの IP アドレスにプロパティを割り当てます。
たとえば、3 つのコントロール プレーン ノードを持つクラスターの場合、256 個のアドレス (たとえば 10.100.0.0/24) のサブネットを使用する場合は、239 より前に最初の連続する静的 IP アドレスを設定する必要があります。 次の表に、アドレスと考慮事項を示します。
| /24 サブネットの範囲 | 番号 | Note |
|---|---|---|
| 172.100.0.0 - 172.100.0.3 | 4 | Azure サブネットで予約済み。 |
| 172.100.0.224-172.100.0.238 | 14 | AKS エンジンで定義されたクラスターの IP アドレスの数。 3 つのコントロール プレーン ノードに 3 個の IP アドレス 余分の IP アドレス 10 個 ロード バランサー用の IP アドレス 1 個 |
| 172.100.0.238 - 172.100.0.254 | 16 | 16 個の IP アドレス バッファー。 |
| 172.100.0.255 | 1 | Azure サブネットで予約済み。 |
この例では、firstConsecutiveStaticIP プロパティは 172.100.0.224です。
より大きなサブネットの場合。たとえば、60,000 を超えるアドレスを持つ /16、静的 IP 割り当てをネットワーク空間の末尾に設定するのは実用的でない場合があります。 クラスターの静的 IP アドレス範囲を IP 空間の最初の 24 個のアドレスから離して設定し、アドレスを要求するときにクラスターが回復力を持てるようにします。
Kubernet のアドレス ブロックの例
次の例では、kubernet ネットワーク プラグインと、コントロール プレーン ノード プールおよびエージェント ノード プール (それぞれのプールに 3 つのノード) の専用サブネットを使用するクラスターの仮想ネットワークのアドレス空間が、上記のさまざまな考慮事項によってどのように埋められるかを確認できます。
VNET のアドレス空間: 10.100.0.0/16。
| アドレス ブロック (サブネット) | CIDR | IP 範囲 | IP の数 (利用可能) |
|---|---|---|---|
| コントロール プレーン ノード ブロック | 10.100.0.0/24 | 10.100.0.0 - 10.100.0.255 | 255 - 4 予約済み = 251 |
| エージェント ノード ブロック | 10.100.1.0/24 | 10.100.1.0 - 10.100.1.255 | 255 - 4 予約済み = 251 |
| サービス ブロック | 10.100.16.0/20 | 10.100.16.0 - 10.100.31.255 | 4,096 - 5 予約済み = 4,091 |
| クラスター ブロック | 10.100.128.0/17 | 10.100.128.0 - 10.100.255.255 | 32,768 - 5 予約済み = 32,763 |
この例では、firstConsecutiveStaticIP プロパティは 10.100.0.239です。
Azure CNI のアドレス ブロックの例
次の例では、Azure CNI ネットワーク プラグインと、コントロール プレーン ノード プールおよびエージェント ノード プール (それぞれのプールに 3 つのノード) の専用サブネットを使用するクラスターの仮想ネットワークのアドレス空間が、上記のさまざまな考慮事項によってどのように埋められるかを確認できます。
VNET のアドレス空間: 172.24.0.0/16。
Note
環境のパブリック IP 範囲が CIDR10.0.0.0/8 内である場合は、ネットワーク プラグインとして kubenet を使います。
| アドレス ブロック (サブネット) | CIDR | IP 範囲 | IP の数 (利用可能) |
|---|---|---|---|
| コントロール プレーン ノード ブロック | 172.24.0.0/24 | 172.24.0.0 - 172.24.0.255 | 255 - 4 予約済み = 251 |
| エージェント ノードとクラスター ブロック | 172.24.128.0/17 | 172.24.128.0 - 172.24.255.255 | 32,768 - 5 予約済み = 32,763 |
| サービス ブロック | 172.24.16.0/20 | 172.24.16.0 - 172.24.31.255 | 4,096 - 5 予約済み = 4,091 |
この例では、firstConsecutiveStaticIP プロパティは 172.24.0.239 になります。
API モデルの更新
AKS エンジンからカスタム仮想ネットワークにクラスターをデプロイするために使用する API モデルを更新します。
masterProfile
| フィールド | 例 | 説明 |
|---|---|---|
| vnetSubnetId | /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn |
サブネットの Azure Resource Manager パス ID を指定します。 この値は、コントロール プレーン ノードのアドレス ブロックにマップされます。 |
| firstConsecutiveStaticIP | 10.100.0.239 | firstConsecutiveStaticIP 構成プロパティに、サブネット内の使用可能な IP アドレス空間の終わりの近くにある IP アドレスを割り当てます。 firstConsecutiveStaticIP はコントロール プレーン ノード プールにのみ適用されます。 |
agentPoolProfiles で、次の値を設定します。
| フィールド | 例 | 説明 |
|---|---|---|
| vnetSubnetId | /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn |
サブネットの Azure Resource Manager パス ID を指定します。 この値は、エージェント ノードのアドレス ブロックにマップされます。 |
orchestratorProfile から kubernetesConfig を見つけ、次の値を設定します。
| フィールド | 例 | 説明 |
|---|---|---|
| clusterSubnet | 10.100.128.0/17 |
ポッド ネットワーク インターフェイスに IP アドレスを割り当てるために使用される IP サブネット。 この値は、クラスター アドレス ブロックにマップされます。 サブネットは、VNET アドレス空間にある必要があります。 Azure CNI が有効になっている場合、既定値は 10.240.0.0/12 です。 Azure CNI を使用しない場合、既定値は 10.244.0.0/16 です。 /24 ではなく /16 サブネットを使用します。 /24 を使用する場合、このサブネットは 1 つのノードにのみ割り当てられます。 IP 領域が不足しているため、他のノードには POD ネットワークが割り当てられないため、クラスター内で準備ができていません。 |
| serviceCidr | 10.100.16.0/20 |
クラスターにデプロイされるサービスの IP アドレスを割り当てるために使用される IP サブネット。 この値は、クラスター サービス ブロックにマップされます。 |
| dnsServiceIP | 10.100.16.10 |
クラスター DNS サービスに割り当てられる IP アドレス。 このアドレスは、serviceCidr サブネットのものである必要があります。 この値は、serviceCidr を指定するときに設定する必要があります。 既定値は、serviceCidr サブネットの .10 アドレスです。 |
たとえば、kubernet を使用している場合:
ネットワークアドレス空間は 10.100.0.0/16、control-plane-sn のサブネットは 10.100.0.0/24、agents-sn は 10.100.1.0/24
"masterProfile": {
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "10.100.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
...
},
...
"kubernetesConfig": [
{
...
"clusterSubnet": "10.100.128.0/17",
"serviceCidr": "10.100.16.0/20",
"dnsServiceIP" : "10.100.16.10",
...
},
たとえば、control-plane-sn のサブネットが 172.24.0.0/24 され、k8s-sn が 172.24.128.0/17されている 172.24.0.0/16 のネットワーク アドレス空間で Azure CNI を使用する場合は、次のようになります。
"masterProfile": {
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "172.24.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
...
},
...
"kubernetesConfig": [
{
...
"clusterSubnet": "172.24.128.0/17",
"serviceCidr": "172.24.16.0/20",
"dnsServiceIP" : "172.24.16.10",
...
},
クラスターをデプロイする
API モデルに値を追加した後は、AKS エンジンの deploy コマンドを使用して、クライアント コンピューターからクラスターをデプロイできます。 説明については、「Kubernetes クラスターのデプロイ」を参照してください。
ルート テーブルを設定する
kubenet を使用している場合 (たとえば networkPlugin): kubenet API モデル構成オブジェクト内の kubernetesConfig。 クラスターをデプロイした後、Azure Stack ユーザー ポータルで仮想ネットワークに戻ります。 サブネット ブレードで、ルート テーブルとネットワーク セキュリティ グループ (NSG) の両方を設定します。 クラスターをカスタム仮想ネットワークに正常にデプロイしたら、クラスターのリソース グループの [ネットワーク] ブレードからルート テーブル リソースの ID を取得します。
Azure Stack Hub インスタンスで Azure Stack Hub ユーザー ポータルを開きます。
[すべてのリソース] を選択します。
検索ボックスに仮想ネットワークの名前を入力します。
[サブネット] を選択し、クラスターを含むサブネットの名前を選択します。
[ルート テーブル] を選択し、クラスターのルート テーブルを選択します。
これは、
masterProfileサブネットを含め、API モデルで指定されたすべてのサブネットに対して行われることを確認します。
Note
Kubernetes Windows クラスター用のカスタム仮想ネットワークには、
次のステップ
- Azure Stack Hub 上の AKS エンジンについて確認する
- 「コンテナーに対する Azure Monitor の概要」を読む