Azure Stack Hub のカスタム仮想ネットワークに Kubernetes クラスターをデプロイする
カスタム仮想ネットワークで Azure Kubernetes Service (AKS) エンジンを使用して Kubernetes クラスターをデプロイできます。 この記事では、仮想ネットワークで必要な情報を見つける方法について説明します。 クラスターで使用されている IP アドレスの計算、API モデルでの値の設定、ルート テーブルとネットワーク セキュリティ グループの設定の手順を確認できます。
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 を使用した仮想ネットワークの作成」を参照してください。
仮想ネットワークの新しいサブネットを作成します。 サブネットのリソース ID と IP アドレス範囲を取得する必要があります。 クラスターをデプロイするときに、API モデル内でリソース ID と範囲を使用します。
Azure Stack Hub インスタンスで Azure Stack Hub ユーザー ポータルを開きます。
[すべてのリソース] を選択します。
検索ボックスに仮想ネットワークの名前を入力します。
サブネットを追加するには [サブネット][+ サブネット] を選択します。
CIDR 表記を使用して [名前] と [アドレス範囲] を追加します。 [OK] を選択します。
[仮想ネットワーク] ブレードで、 [プロパティ] を選択します。 [リソース ID] フィールドをコピーし、 を追加します。 この値は、クラスターの 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 アドレスも必要になります。 最後に、コントロール プレーン ノードとヘッドルーム予約の後に、ロード バランサーによって別の IP アドレスが使用され、合計で 16 になります。 IP アドレスのブロックを配置する場合、サブネットでは既存の IP アドレスの次の割り当てが必要になります。
- 最初の 4 つの IP アドレスと最後の IP アドレスは予約されており、どの Azure サブネットでも使用できません。
- 16 個の IP アドレスのバッファーをオープンにしたままにする必要があります。
- IP の競合を回避するには、クラスターの最初の IP アドレスの値をアドレス空間の末尾に向けて指定する必要があります。 可能であれば、サブネット内の
firstConsecutiveStaticIP使用可能な IP アドレス空間の 末尾 近くの IP アドレスに プロパティを割り当てます。
たとえば、3 つのコントロール プレーン ノードを含むクラスターがあるとします。 10.100.0.0/24 など、256 のアドレスを持つサブネットを使用している場合は、連続する最初の静的 IP アドレスを 239 より前に設定する必要があります。 次の表に、アドレスと考慮事項を示します。
| /24 サブネットの範囲 | Number | 注意 |
|---|---|---|
| 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 になります。
より大きいサブネット (たとえば、/16 でアドレスが 6 万を超える) では、ネットワーク領域の最後に静的 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。
注意
環境のパブリック 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/77e28b6a-582f-42b0-94d2-93b9eca60845/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn |
サブネットの Azure Resource Manager パス ID を指定します。 この値は、上のコントロール プレーン ノードのアドレス ブロックにマップされます。 |
| firstConsecutiveStaticIP | 10.100.0.239 | firstConsecutiveStaticIP 構成プロパティに、サブネット内の使用可能な IP アドレス空間のfirstConsecutiveStaticIPの近くにある IP アドレスを割り当てます。 firstConsecutiveStaticIP はコントロール プレーン ノード プールにのみ適用されます。 |
agentPoolProfiles で、次の値を設定します。
| フィールド | 例 | 説明 |
|---|---|---|
| vnetSubnetId | /subscriptions/77e28b6a-582f-42b0-94d2-93b9eca60845/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 空間が不足するため、他のノードにポッド ネットワークが割り当てられません。そのため、これらをクラスターで準備することができなくなります。 |
| 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/77e28b6a-582f-42b0-94d2-93b9eca60845/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "10.100.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/77e28b6a-582f-42b0-94d2-93b9eca60845/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",
...
},
たとえば、Azure CNI を使用している場合:
ネットワークアドレス空間は 172.24.0.0/16、control-plane-sn のサブネットは 172.24.0.0/24、k8s-sn は 172.24.128.0/17
"masterProfile": {
...
"vnetSubnetId": "/subscriptions/77e28b6a-582f-42b0-94d2-93b9eca60845/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "172.24.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/77e28b6a-582f-42b0-94d2-93b9eca60845/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): kubernetesConfig API モデル構成オブジェクト内の kubenet。 クラスターをデプロイした後、Azure Stack ユーザー ポータルで仮想ネットワークに戻ります。 サブネット ブレードで、ルート テーブルとネットワーク セキュリティ グループ (NSG) の両方を設定します。 クラスターをカスタム仮想ネットワークに正常にデプロイしたら、クラスターのリソース グループにある [ネットワーク] ブレードからルート テーブル リソースの ID を取得します。
Azure Stack Hub インスタンスで Azure Stack Hub ユーザー ポータルを開きます。
[すべてのリソース] を選択します。
検索ボックスに仮想ネットワークの名前を入力します。
[サブネット] を選択し、クラスターを含むサブネットの名前を選択します。
[ルート テーブル] を選択し、クラスターのルート テーブルを選択します。
これは、API モデルで指定されたすべてのサブネット (サブネットを含む) に対して行われることを
masterProfile確認します。
Note
Kubernetes Windows クラスターのカスタム仮想ネットワークには 既知の問題があります。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示