Azure Kubernetes Service (AKS) の独自の IP アドレス範囲で kubenet ネットワークを使用するUse kubenet networking with your own IP address ranges in Azure Kubernetes Service (AKS)

既定では、AKS クラスターでは kubenet が使用されて、Azure 仮想ネットワークとサブネットが自動的に作成されます。By default, AKS clusters use kubenet, and an Azure virtual network and subnet are created for you. kubenet を使用すると、ノードでは Azure 仮想ネットワーク サブネットから IP アドレスが取得されます。With kubenet, nodes get an IP address from the Azure virtual network subnet. ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。Pods receive an IP address from a logically different address space to the Azure virtual network subnet of the nodes. その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。Network address translation (NAT) is then configured so that the pods can reach resources on the Azure virtual network. トラフィックの発信元 IP アドレスは、ノードのプライマリ IP アドレスに NAT 変換されます。The source IP address of the traffic is NAT'd to the node's primary IP address. この方法では、ポッド用にネットワーク空間で予約する必要がある IP アドレスの数が大幅に減ります。This approach greatly reduces the number of IP addresses that you need to reserve in your network space for pods to use.

Azure Container Networking Interface (CNI) では、すべてのポッドにサブネットから IP アドレスが割り当てられ、すべてのポッドに直接アクセスできます。With Azure Container Networking Interface (CNI), every pod gets an IP address from the subnet and can be accessed directly. これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、事前に計画する必要があります。These IP addresses must be unique across your network space, and must be planned in advance. 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。Each node has a configuration parameter for the maximum number of pods that it supports. ノードごとにそれと同じ数の IP アドレスが、そのノードに対して事前に予約されます。The equivalent number of IP addresses per node are then reserved up front for that node. この方法では詳細な計画が必要であり、多くの場合、IP アドレスが不足するか、アプリケーション需要の拡大に伴い、より大きなサブネットでのクラスターの再構築が必要になります。This approach requires more planning, and often leads to IP address exhaustion or the need to rebuild clusters in a larger subnet as your application demands grow. クラスターの作成時、または新しいノード プールを作成するときに、ノードに展開できる最大ポッド数を構成できます。You can configure the maximum pods deployable to a node at cluster create time or when creating new node pools. 新しいノード プールを作成するときに maxPods を指定しない場合は、kubenet の既定値 110 を受け取ります。If you don't specify maxPods when creating new node pools, you receive a default value of 110 for kubenet.

この記事では、 kubenet ネットワークを使用して、AKS クラスター用の仮想ネットワーク サブネットを作成して使用する方法を示します。This article shows you how to use kubenet networking to create and use a virtual network subnet for an AKS cluster. ネットワークのオプションと考慮事項について詳しくは、Kubernetes および AKS のネットワークの概念に関する記事をご覧ください。For more information on network options and considerations, see Network concepts for Kubernetes and AKS.

前提条件Prerequisites

  • AKS クラスターの仮想ネットワークでは、送信インターネット接続を許可する必要があります。The virtual network for the AKS cluster must allow outbound internet connectivity.
  • 同じサブネット内に複数の AKS クラスターを作成しないでください。Don't create more than one AKS cluster in the same subnet.
  • AKS クラスターでは、Kubernetes サービスのアドレス範囲、ポッド アドレス範囲、またはクラスターの仮想ネットワーク アドレス範囲に 169.254.0.0/16172.30.0.0/16172.31.0.0/16192.0.2.0/24 を使用することはできません。AKS clusters may not use 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16, or 192.0.2.0/24 for the Kubernetes service address range, pod address range or cluster virtual network address range.
  • AKS クラスターで使用されるサービス プリンシパルには、少なくとも、ご利用の仮想ネットワーク内のサブネットに対するネットワーク共同作成者ロールが必要です。The service principal used by the AKS cluster must have at least Network Contributor role on the subnet within your virtual network. また、サービス プリンシパルを作成してアクセス許可を割り当てるには、サブスクリプション所有者などの適切なアクセス許可が必要です。You must also have the appropriate permissions, such as the subscription owner, to create a service principal and assign it permissions. 組み込みのネットワークの共同作成者ロールを使用する代わりに、カスタム ロールを定義する場合は、次のアクセス許可が必要です。If you wish to define a custom role instead of using the built-in Network Contributor role, the following permissions are required:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

警告

Windows Server ノード プールを使用するには、Azure CNI を使用する必要があります。To use Windows Server node pools, you must use Azure CNI. Windows Server コンテナーには、ネットワーク モデルとして kubenet を使用できません。The use of kubenet as the network model is not available for Windows Server containers.

開始する前にBefore you begin

Azure CLI バージョン 2.0.65 以降がインストールされて構成されている必要があります。You need the Azure CLI version 2.0.65 or later installed and configured. バージョンを確認するには、az --version を実行します。Run az --version to find the version. インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。If you need to install or upgrade, see Install Azure CLI.

独自のサブネットでの kubenet ネットワークの概要Overview of kubenet networking with your own subnet

多くの環境では、割り当て済みの IP アドレス範囲を使用して仮想ネットワークとサブネットを定義します。In many environments, you have defined virtual networks and subnets with allocated IP address ranges. これらの仮想ネットワーク リソースは、複数のサービスとアプリケーションをサポートするために使用されます。These virtual network resources are used to support multiple services and applications. ネットワーク接続を提供するため、AKS クラスターでは kubenet (基本的なネットワーク) または Azure CNI ("高度なネットワーク) を使用できます。To provide network connectivity, AKS clusters can use kubenet (basic networking) or Azure CNI (advanced networking).

kubenet では、ノードだけが仮想ネットワーク サブネットの IP アドレスを受け取ります。With kubenet, only the nodes receive an IP address in the virtual network subnet. ポッドが相互に直接通信することはできません。Pods can't communicate directly with each other. 代わりに、複数のノードにまたがるポッド間の接続には、ユーザー定義ルーティング (UDR) と IP 転送が使用されます。Instead, User Defined Routing (UDR) and IP forwarding is used for connectivity between pods across nodes. 既定では、UDR と IP 転送の構成は AKS サービスによって作成および管理されますが、カスタム ルート管理用に独自のルートテーブルを用意するオプションがあります。By default, UDRs and IP forwarding configuration is created and maintained by the AKS service, but you have to the option to bring your own route table for custom route management. 割り当て済み IP アドレスを受け取ってアプリケーションに対するトラフィックを負荷分散するサービスの背後に、ポッドをデプロイすることもできます。You could also deploy pods behind a service that receives an assigned IP address and load balances traffic for the application. 次の図では、ポッドではなく AKS ノードが仮想ネットワーク サブネットの IP アドレスを受け取る方法を示します。The following diagram shows how the AKS nodes receive an IP address in the virtual network subnet, but not the pods:

AKS クラスターでの kubenet ネットワーク モデル

Azure でサポートされる UDR のルート数は最大 400 なので、AKS クラスターに 400 個より多くのノードを作成することはできません。Azure supports a maximum of 400 routes in a UDR, so you can't have an AKS cluster larger than 400 nodes. AKS 仮想ノードや Azure ネットワーク ポリシーは、kubenet ではサポートされていません。AKS Virtual Nodes and Azure Network Policies aren't supported with kubenet. Kubernet でサポートされている Calico ネットワーク ポリシーをご利用ください。You can use Calico Network Policies, as they are supported with kubenet.

Azure CNI では、各ポッドは IP サブネット内の IP アドレスを受け取り、他のポッドやサービスと直接通信できます。With Azure CNI, each pod receives an IP address in the IP subnet, and can directly communicate with other pods and services. クラスターは、ユーザーが指定する IP アドレスの範囲まで拡大できます。Your clusters can be as large as the IP address range you specify. ただし、IP アドレスの範囲を事前に計画する必要があり、すべての IP アドレスは、ノードでサポートできるポッドの最大数に基づいて AKS ノードによって消費されます。However, the IP address range must be planned in advance, and all of the IP addresses are consumed by the AKS nodes based on the maximum number of pods that they can support. Azure CNI では、仮想ノードやネットワーク ポリシー (Azure または Calico) などの高度なネットワーク機能とシナリオがサポートされます。Advanced network features and scenarios such as Virtual Nodes or Network Policies (either Azure or Calico) are supported with Azure CNI.

kubenet に関する制限と考慮事項Limitations & considerations for kubenet

  • kubenet の設計には、追加のホップが必要になるため、ポッド通信の待機時間がわずかに増加します。An additional hop is required in the design of kubenet, which adds minor latency to pod communication.
  • kubenet を使用するには、ルート テーブルとユーザー定義ルートが必要になるため、操作が複雑になります。Route tables and user-defined routes are required for using kubenet, which adds complexity to operations.
  • kubenet の設計により、直接的なポッドのアドレス指定は kubenet ではサポートされていません。Direct pod addressing isn't supported for kubenet due to kubenet design.
  • Azure CNI クラスターとは異なり、複数の kubenet クラスターで 1 つのサブネットを共有することはできません。Unlike Azure CNI clusters, multiple kubenet clusters can't share a subnet.
  • kubenet でサポートされていない機能 には次のものが含まれます。Features not supported on kubenet include:

IP アドレスの使用可能性と不足IP address availability and exhaustion

Azure CNI でよくある問題は、割り当てられている IP アドレス範囲が小さすぎて、クラスターをスケーリングまたはアップグレードするときにノードを追加できないことです。With Azure CNI, a common issue is the assigned IP address range is too small to then add additional nodes when you scale or upgrade a cluster. ネットワーク チームが、予想されるアプリケーションの需要をサポートするのに十分な大きさの IP アドレス範囲を発行できないこともあります。The network team may also not be able to issue a large enough IP address range to support your expected application demands.

妥協案として、kubenet を使用する AKS クラスターを作成し、既存の仮想ネットワーク サブネットに接続することができます。As a compromise, you can create an AKS cluster that uses kubenet and connect to an existing virtual network subnet. この方法では、ノードは定義済みの IP アドレスを受け取ることができ、クラスター内で実行される可能性のあるすべてのポッド用に多数の IP アドレスを事前に予約する必要はありません。This approach lets the nodes receive defined IP addresses, without the need to reserve a large number of IP addresses up front for all of the potential pods that could run in the cluster.

kubenet では、はるかに小さい IP アドレス範囲を使用して、大きなクラスターやアプリケーションの需要をサポートできます。With kubenet, you can use a much smaller IP address range and be able to support large clusters and application demands. たとえば、お使いのサブネットの /27 の IP アドレス範囲でも、20 から 25 ノードのクラスターを実行し、スケーリングやアップグレードのための十分な余裕を確保できます。For example, even with a /27 IP address range on your subnet, you could run a 20-25 node cluster with enough room to scale or upgrade. このクラスター サイズでは、最大で 2,200 ~ 2,750 個のポッドがサポートされます (既定では、ノードあたり最大 110 ポッド)。This cluster size would support up to 2,200-2,750 pods (with a default maximum of 110 pods per node). AKS において kubenet で構成できるノードあたりの最大ポッド数は 110 です。The maximum number of pods per node that you can configure with kubenet in AKS is 110.

次の基本的な計算では、ネットワーク モデルの違いを比較します。The following basic calculations compare the difference in network models:

  • kubenet - 単純な /24 の IP アドレス範囲で、クラスター内の最大 251 ノードをサポートできます (各 Azure 仮想ネットワーク サブネットでは、最初の 3 つの IP アドレスが管理操作用に予約されます)kubenet - a simple /24 IP address range can support up to 251 nodes in the cluster (each Azure virtual network subnet reserves the first three IP addresses for management operations)
    • このノード数では、最大で 27,610 個のポッドをサポートできます (kubenet の既定では、ノードあたり最大 110 ポッド)This node count could support up to 27,610 pods (with a default maximum of 110 pods per node with kubenet)
  • Azure CNI - 同じ基本的な /24 のサブネット範囲では、クラスター内の最大 8 ノードしかサポートできませんAzure CNI - that same basic /24 subnet range could only support a maximum of 8 nodes in the cluster
    • このノード数では、最大で 240 個のポッドしかサポートできません (Azure CNI の既定では、ノードあたり最大 30 ポッド)This node count could only support up to 240 pods (with a default maximum of 30 pods per node with Azure CNI)

注意

これらの最大値では、アップグレードまたはスケーリング操作は考慮されていません。These maximums don't take into account upgrade or scale operations. 実際には、サブネットの IP アドレス範囲でサポートされる最大数のノードを実行することはできません。In practice, you can't run the maximum number of nodes that the subnet IP address range supports. スケーリングまたはアップグレード操作の間に使用できるように、一部の IP アドレスを残しておく必要があります。You must leave some IP addresses available for use during scale of upgrade operations.

仮想ネットワーク ピアリングと ExpressRoute 接続Virtual network peering and ExpressRoute connections

オンプレミスの接続を提供するため、kubenet および Azure CNI のどちらのネットワーク アプローチでも、Azure 仮想ネットワーク ピアリングまたは ExpressRoute 接続を使用できます。To provide on-premises connectivity, both kubenet and Azure-CNI network approaches can use Azure virtual network peering or ExpressRoute connections. 重複および正しくないトラフィック ルーティングが発生しないように、慎重に IP アドレス範囲を計画する必要があります。Plan your IP address ranges carefully to prevent overlap and incorrect traffic routing. たとえば、多くのオンプレミス ネットワークでは、ExpressRoute 接続経由でアドバタイズされる 10.0.0.0/8 のアドレス範囲が使用されます。For example, many on-premises networks use a 10.0.0.0/8 address range that is advertised over the ExpressRoute connection. AKS クラスターをこのアドレス範囲外の Azure 仮想ネットワーク サブネット (172.16.0.0/16 など) に作成することをお勧めします。It's recommended to create your AKS clusters into Azure virtual network subnets outside of this address range, such as 172.16.0.0/16.

使用するネットワーク モデルを選択するChoose a network model to use

通常、AKS クラスターに使用するネットワーク プラグインは、柔軟性と高度な構成のニーズのバランスを考慮して選択します。The choice of which network plugin to use for your AKS cluster is usually a balance between flexibility and advanced configuration needs. 以下の考慮事項は、それぞれのネットワーク モデルが最も適切である可能性がある状況の概要を理解するのに役立ちます。The following considerations help outline when each network model may be the most appropriate.

kubenet を使用する場合:Use kubenet when:

  • IP アドレス空間が限られている。You have limited IP address space.
  • ポッドのほとんどの通信がクラスター内で行われる。Most of the pod communication is within the cluster.
  • 仮想ノードや Azure ネットワーク ポリシーなどの高度な AKS 機能を使用する必要がない。You don't need advanced AKS features such as virtual nodes or Azure Network Policy. Calico ネットワーク ポリシー を使用している。Use Calico network policies.

Azure CNI を使用する場合:Use Azure CNI when:

  • 使用可能な IP アドレス空間が十分にある。You have available IP address space.
  • ポッドの通信のほとんどが、クラスターの外部にあるリソースに対するものである。Most of the pod communication is to resources outside of the cluster.
  • ポッド接続用にユーザー定義ルートを管理したくない。You don't want to manage user defined routes for pod connectivity.
  • 仮想ノードや Azure ネットワーク ポリシーなどの高度な AKS 機能を使用する必要がある。You need AKS advanced features such as virtual nodes or Azure Network Policy. Calico ネットワーク ポリシー を使用している。Use Calico network policies.

どのネットワーク モデルを使用するかの決定に役立つ詳細については、ネットワーク モデルとそのサポート範囲の比較に関するページを参照してください。For more information to help you decide which network model to use, see Compare network models and their support scope.

仮想ネットワークとサブネットの作成Create a virtual network and subnet

kubenet と独自の仮想ネットワーク サブネットを使って作業を始めるには、最初に az group create コマンドを使用してリソース グループを作成します。To get started with using kubenet and your own virtual network subnet, first create a resource group using the az group create command. 次の例では、myResourceGroup という名前のリソース グループを eastus に作成します。The following example creates a resource group named myResourceGroup in the eastus location:

az group create --name myResourceGroup --location eastus

使用できる既存の仮想ネットワークとサブネットがない場合は、az network vnet create コマンドを使用してこれらのネットワーク リソースを作成します。If you don't have an existing virtual network and subnet to use, create these network resources using the az network vnet create command. 次の例では、192.168.0.0/16 のアドレス プレフィックスを持つ仮想ネットワークに myVnet という名前が付けられています。In the following example, the virtual network is named myVnet with the address prefix of 192.168.0.0/16. 192.168.1.0/24 のアドレス プレフィックスを持つ myAKSSubnet という名前のサブネットが作成されています。A subnet is created named myAKSSubnet with the address prefix 192.168.1.0/24.

az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24

サービス プリンシパルを作成してアクセス許可を割り当てるCreate a service principal and assign permissions

AKS クラスターが他の Azure リソースと対話できるようにするために、Azure Active Directory のサービス プリンシパルを使用します。To allow an AKS cluster to interact with other Azure resources, an Azure Active Directory service principal is used. サービス プリンシパルには、AKS ノードで使用される仮想ネットワークとサブネットを管理するためのアクセス許可が必要です。The service principal needs to have permissions to manage the virtual network and subnet that the AKS nodes use. サービス プリンシパルを作成するには、az ad sp create-for-rbac コマンドを使用します。To create a service principal, use the az ad sp create-for-rbac command:

az ad sp create-for-rbac --skip-assignment

次の出力例では、サービス プリンシパルのアプリケーション ID とパスワードが示されています。The following example output shows the application ID and password for your service principal. これらの値を後の手順で使用して、サービス プリンシパルにロールを割り当てた後、AKS クラスターを作成します。These values are used in additional steps to assign a role to the service principal and then create the AKS cluster:

az ad sp create-for-rbac --skip-assignment
{
  "appId": "476b3636-5eda-4c0e-9751-849e70b5cfad",
  "displayName": "azure-cli-2019-01-09-22-29-24",
  "name": "http://azure-cli-2019-01-09-22-29-24",
  "password": "a1024cd7-af7b-469f-8fd7-b293ecbb174e",
  "tenant": "72f998bf-85f1-41cf-92ab-2e7cd014db46"
}

後の手順で正しい委任を割り当てるため、az network vnet show コマンドと az network vnet subnet show コマンドを使用して、必要なリソース ID を取得します。To assign the correct delegations in the remaining steps, use the az network vnet show and az network vnet subnet show commands to get the required resource IDs. これらのリソース ID を変数に格納し、後の手順で参照します。These resource IDs are stored as variables and referenced in the remaining steps:

VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

次に、az role assignment create コマンドを使用して、AKS クラスターのサービス プリンシパルに、仮想ネットワークでの "ネットワーク共同作成者" アクセス許可を割り当てます。Now assign the service principal for your AKS cluster Network Contributor permissions on the virtual network using the az role assignment create command. 前のサービス プリンシパル作成コマンドの出力で示されている独自の <appId> を指定します。Provide your own <appId> as shown in the output from the previous command to create the service principal:

az role assignment create --assignee <appId> --scope $VNET_ID --role "Network Contributor"

仮想ネットワークに AKS クラスターを作成するCreate an AKS cluster in the virtual network

ここまで、仮想ネットワークとサブネットを作成し、サービス プリンシパルを作成して、それらのネットワーク リソースを使用するためのアクセス許可を割り当てました。You've now created a virtual network and subnet, and created and assigned permissions for a service principal to use those network resources. 次に、az aks create コマンドを使用して、仮想ネットワークとサブネット内に AKS クラスターを作成します。Now create an AKS cluster in your virtual network and subnet using the az aks create command. 前のサービス プリンシパル作成コマンドの出力で示されているように、独自のサービス プリンシパルの <appId><password> を定義します。Define your own service principal <appId> and <password>, as shown in the output from the previous command to create the service principal.

クラスター作成プロセスの一部として、次の IP アドレス範囲も定義します。The following IP address ranges are also defined as part of the cluster create process:

  • --service-cidr は、AKS クラスター内の内部サービスに IP アドレスを割り当てるために使用します。The --service-cidr is used to assign internal services in the AKS cluster an IP address. この IP アドレス範囲は、ネットワーク環境内の他の場所で使用されていないアドレス空間である必要があります。ExpressRoute またはサイト間 VPN 接続を使用して、お使いの Azure 仮想ネットワークを接続している場合、または接続する予定である場合は、すべてのオンプレミス ネットワーク範囲がこれに含まれます。This IP address range should be an address space that isn't in use elsewhere in your network environment, including any on-premises network ranges if you connect, or plan to connect, your Azure virtual networks using Express Route or a Site-to-Site VPN connection.

  • --dns-service-ip アドレスは、サービス IP アドレス範囲の .10 アドレスにする必要があります。The --dns-service-ip address should be the .10 address of your service IP address range.

  • --pod-cidr は、ネットワーク環境の他の場所で使われていない大きいアドレス空間にする必要があります。The --pod-cidr should be a large address space that isn't in use elsewhere in your network environment. ExpressRoute またはサイト間 VPN 接続を使用して、お使いの Azure 仮想ネットワークを接続している場合、または接続する予定である場合は、すべてのオンプレミス ネットワーク範囲がこの範囲に含まれます。This range includes any on-premises network ranges if you connect, or plan to connect, your Azure virtual networks using Express Route or a Site-to-Site VPN connection.

    • このアドレス範囲は、スケールアップ後に予想されるノードの数を格納するのに十分な大きさである必要があります。This address range must be large enough to accommodate the number of nodes that you expect to scale up to. 追加ノード用により多くのアドレスが必要になった場合でも、クラスターをデプロイした後では、このアドレス範囲を変更できません。You can't change this address range once the cluster is deployed if you need more addresses for additional nodes.
    • ポッドの IP アドレス範囲は、クラスター内の各ノードに /24 アドレス空間を割り当てるために使用されます。The pod IP address range is used to assign a /24 address space to each node in the cluster. 次の例では、10.244.0.0/16--pod-cidr によって、最初のノードに 10.244.0.0/24、2 番目のノードに 10.244.1.0/24、3 番目のノードに 10.244.2.0/24 が割り当てられます。In the following example, the --pod-cidr of 10.244.0.0/16 assigns the first node 10.244.0.0/24, the second node 10.244.1.0/24, and the third node 10.244.2.0/24.
    • クラスターをスケーリングまたはアップグレードすると、Azure プラットフォームによって引き続き新しい各ノードにポッドの IP アドレス範囲が割り当てられます。As the cluster scales or upgrades, the Azure platform continues to assign a pod IP address range to each new node.
  • --docker-bridge-address を使用すると、AKS ノードは基になる管理プラットフォームと通信できます。The --docker-bridge-address lets the AKS nodes communicate with the underlying management platform. この IP アドレスは、クラスターの仮想ネットワーク IP アドレス範囲に含まれていてはならず、ネットワークで使用されている他のアドレス範囲と重複していてもなりません。This IP address must not be within the virtual network IP address range of your cluster, and shouldn't overlap with other address ranges in use on your network.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal <appId> \
    --client-secret <password>

注意

AKS クラスターに Calico ネットワーク ポリシーを含めるには、次のコマンドを使用します。If you wish to enable an AKS cluster to include a Calico network policy you can use the following command.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet --network-policy calico \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal <appId> \
    --client-secret <password>

AKS クラスターを作成すると、ネットワーク セキュリティ グループとルート テーブルが自動的に作成されます。When you create an AKS cluster, a network security group and route table are automatically created. これらのネットワーク リソースは、AKS コントロール プレーンによって管理されます。These network resources are managed by the AKS control plane. ネットワーク セキュリティ グループは、ノードの仮想 NIC と自動的に関連付けられます。The network security group is automatically associated with the virtual NICs on your nodes. ルート テーブルは、仮想ネットワーク サブネットと自動的に関連付けられます。The route table is automatically associated with the virtual network subnet. サービスを作成して公開すると、ネットワーク セキュリティ グループ規則とルート テーブルが自動的に更新されます。Network security group rules and route tables are automatically updated as you create and expose services.

kubenet で独自のサブネットとルート テーブルを使用するBring your own subnet and route table with kubenet

kubenet では、ルート テーブルがクラスター サブネット上に存在している必要があります。With kubenet, a route table must exist on your cluster subnet(s). AKS では、独自の既存のサブネットとルート テーブルを使用することがサポートされています。AKS supports bringing your own existing subnet and route table.

カスタム サブネットにルート テーブルが含まれていない場合は、AKS によって作成され、クラスターのライフサイクル全体にわたってそれにルールが追加されます。If your custom subnet does not contain a route table, AKS creates one for you and adds rules to it throughout the cluster lifecycle. クラスターを作成するときにカスタム サブネットにルートテーブルが含まれている場合、クラスターの操作中に既存のルート テーブルが AKS で認識され、クラウド プロバイダーの操作に応じてルールが追加または更新されます。If your custom subnet contains a route table when you create your cluster, AKS acknowledges the existing route table during cluster operations and adds/updates rules accordingly for cloud provider operations.

警告

カスタム ルールをカスタム ルート テーブルに追加し、更新することができます。Custom rules can be added to the custom route table and updated. ただし、Kubernetes クラウド プロバイダーによって追加されたルールは、更新または削除してはなりません。However, rules are added by the Kubernetes cloud provider which must not be updated or removed. 0.0.0.0/0 などのルールは、特定のルート テーブルに常に存在し、NVA や他のエグレス ゲートウェイなどのインターネット ゲートウェイのターゲットにマップされている必要があります。Rules such as 0.0.0.0/0 must always exist on a given route table and map to the target of your internet gateway, such as an NVA or other egress gateway. ルールの更新でカスタム ルールのみが変更されている場合は注意が必要です。Take caution when updating rules that only your custom rules are being modified.

カスタム ルート テーブルのセットアップに関する詳細を参照してください。Learn more about setting up a custom route table.

Kubernet ネットワークで要求を正常にルーティングするには、整理されたルート テーブル ルールが必要です。Kubenet networking requires organized route table rules to successfully route requests. この設計のため、ルート テーブルはそれに依存するクラスターごとに慎重に保守する必要があります。Due to this design, route tables must be carefully maintained for each cluster which relies on it. 異なるクラスターからのポッド CIDR が重複し、予期しないルーティングや壊れたルーティングが発生する可能性があるため、複数のクラスターでルート テーブルを共有することはできません。Multiple clusters cannot share a route table because pod CIDRs from different clusters may overlap which causes unexpected and broken routing. 同じ仮想ネットワークで複数のクラスターを構成する場合、または仮想ネットワークを各クラスター専用にする場合は、次の制限事項を考慮してください。When configuring multiple clusters on the same virtual network or dedicating a virtual network to each cluster, ensure the following limitations are considered.

制限事項:Limitations:

  • クラスターを作成する前にアクセス許可を割り当てる必要があります。対象のカスタム サブネットおよびカスタム ルート テーブルへの書き込みアクセス許可を持つサービス プリンシパルを使用していることを確認してください。Permissions must be assigned before cluster creation, ensure you are using a service principal with write permissions to your custom subnet and custom route table.
  • AKS クラスターを作成する前に、カスタム ルート テーブルをサブネットに関連付ける必要があります。A custom route table must be associated to the subnet before you create the AKS cluster.
  • クラスターを作成した後で、関連付けられているルート テーブル リソースを更新することはできません。The associated route table resource cannot be updated after cluster creation. ルート テーブル リソースは更新できませんが、カスタム ルールはルート テーブルで変更できます。While the route table resource cannot be updated, custom rules can be modified on the route table.
  • 各 AKS クラスターでは、クラスターに関連付けられているすべてのサブネットに対して、一意のルート テーブルを 1 つだけ使用する必要があります。Each AKS cluster must use a single, unique route table for all subnets associated with the cluster. ポッドの CIDR が重複してルーティング規則が競合する可能性があるため、複数のクラスターでルート テーブルを再利用することはできません。You cannot reuse a route table with multiple clusters due to the potential for overlapping pod CIDRs and conflicting routing rules.

カスタム ルート テーブルを作成し、仮想ネットワーク内のサブネットにそれを関連付けた後は、ルート テーブルを使用する新しい AKS クラスターを作成できます。After you create a custom route table and associate it to your subnet in your virtual network, you can create a new AKS cluster that uses your route table. AKS クラスターをデプロイする予定の場所に対するサブネット ID を使用する必要があります。You need to use the subnet ID for where you plan to deploy your AKS cluster. このサブネットは、カスタム ルート テーブルに関連付けられている必要もあります。This subnet also must be associated with your custom route table.

# Find your subnet ID
az network vnet subnet list --resource-group
                            --vnet-name
                            [--subscription]
# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id MySubnetID

次のステップNext steps

既存の仮想ネットワーク サブネットに AKS クラスターをデプロイしたので、通常どおりクラスターを使用できます。With an AKS cluster deployed into your existing virtual network subnet, you can now use the cluster as normal. Azure Dev Spaces を使用してアプリを構築することから始めるか、Helm を使用して既存のアプリをデプロイするか、Helm を使用して新しいアプリを作成しますGet started with building apps using Azure Dev Spaces, deploy existing apps using Helm, or creating new apps using Helm.