Azure Kubernetes Service (AKS) でパブリック Standard Load Balancer を使用するUse a public Standard Load Balancer in Azure Kubernetes Service (AKS)

Azure Load Balancer では、開放型システム間相互接続 (OSI) モデルの L4 で、受信と送信の両方のシナリオがサポートされます。The Azure Load Balancer is an L4 of the Open Systems Interconnection (OSI) model that supports both inbound and outbound scenarios. これにより、ロード バランサーのフロントエンドに到着した受信フローが、バックエンド プールのインスタンスに分配されます。It distributes inbound flows that arrive at the load balancer's front end to the backend pool instances.

パブリック ロード バランサーを AKS と統合すると、次の 2 つの目的を達成することができます。A public Load Balancer when integrated with AKS serves two purposes:

  1. AKS 仮想ネットワーク内のクラスター ノードへの送信接続を提供します。To provide outbound connections to the cluster nodes inside the AKS virtual network. この目的は、ノードのプライベート IP アドレスを、"送信プール" の一部であるパブリック IP アドレスに変換することによって達成されます。It achieves this objective by translating the nodes private IP address to a public IP address that is part of its Outbound Pool.
  2. 種類が LoadBalancer の Kubernetes サービスを経由してアプリケーションにアクセスできるようにします。To provide access to applications via Kubernetes services of type LoadBalancer. これにより、ユーザーはアプリケーションを簡単にスケーリングしたり、高可用性のサービスを作成したりすることができます。With it, you can easily scale your applications and create highly available services.

内部 (プライベート) ロード バランサーは、プライベート IP のみがフロントエンドとして許可される場合に使用されます。An internal (or private) load balancer is used where only private IPs are allowed as frontend. 内部ロード バランサーは、仮想ネットワーク内でトラフィックを負荷分散させるために使用されます。Internal load balancers are used to load balance traffic inside a virtual network. ハイブリッド シナリオでは、オンプレミスのネットワークからもロード バランサーのフロントエンドにアクセスできます。A load balancer frontend can also be accessed from an on-premises network in a hybrid scenario.

このドキュメントでは、パブリック ロード バランサーとの統合について説明します。This document covers the integration with Public Load balancer. 内部ロード バランサーの統合については、AKS の内部ロード バランサーに関するドキュメントを参照してください。For internal Load Balancer integration, see the AKS Internal Load balancer documentation.

開始する前にBefore you begin

Azure Load Balancer は、BasicStandard の 2 つの SKU で使用できます。Azure Load Balancer is available in two SKUs - Basic and Standard. AKS クラスターを作成する場合、既定では Standard SKU が使用されます。By default, Standard SKU is used when you create an AKS cluster. Standard SKU を使用すると、より大きなバックエンド プール、複数のノード プールAvailability Zonesなどの追加機能にアクセスできます。Use the Standard SKU to have access to added functionality, such as a larger backend pool, multiple node pools, and Availability Zones. AKS の場合、この Load Balancer SKU が推奨されます。It's the recommended Load Balancer SKU for AKS.

BasicStandard SKU の詳細については、「Azure Load Balancer の SKU の比較」をご覧ください。For more information on the Basic and Standard SKUs, see Azure load balancer SKU comparison.

この記事では、AKS クラスターで Standard SKU Azure Load Balancer が使用されていることを前提として、ロード バランサーの一部の機能を構成および使用する方法について説明します。This article assumes you have an AKS cluster with the Standard SKU Azure Load Balancer and walks through how to use and configure some of the capabilities and features of the load balancer. AKS クラスターが必要な場合は、Azure CLI を使用した場合または Azure portal を使用した場合の AKS のクイックスタートを参照してください。If you need an AKS cluster, see the AKS quickstart using the Azure CLI or using the Azure portal.

重要

送信接続を提供するために、Azure Load Balancer ではなく、独自のゲートウェイ、ファイアウォールまたはプロキシを使用する場合、UserDefinedRouting (UDR) として送信の種類を使用することで、ロード バランサーの送信プールとそれぞれのフロントエンド IP の作成をスキップできます。If you prefer not to leverage the Azure Load Balancer to provide outbound connection and instead have your own gateway, firewall or proxy for that purpose you can skip the creation of the load balancer outbound pool and respective frontend IP by using Outbound type as UserDefinedRouting (UDR). 送信の種類では、クラスターのエグレス方法を定義します。既定の種類は、ロード バランサーです。The Outbound type defines the egress method for a cluster and it defaults to type: load balancer.

パブリック Standard Load Balancer を使用するUse the public standard load balancer

送信の種類としてロード バランサー (既定) に設定して AKS クラスターを作成すると、クラスターは、ロード バランサーを使用してサービスも公開できるようになります。After creating an AKS cluster with Outbound Type: Load Balancer (default), the cluster is ready to use the load balancer to expose services as well.

そのために、次の例に示すように、種類が LoadBalancer のパブリック サービスを作成できます。For that you can create a public Service of type LoadBalancer as shown in the following example. まず、public-svc.yaml という名前のサービス マニフェストを作成します。Start by creating a service manifest named public-svc.yaml:

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

kubectl apply を使用してパブリック サービス マニフェストをデプロイし、YAML マニフェストの名前を指定します。Deploy the public service manifest by using kubectl apply and specify the name of your YAML manifest:

kubectl apply -f public-svc.yaml

Azure Load Balancer が、この新しいサービスを公開する新しいパブリック IP で構成されます。The Azure Load Balancer will be configured with a new public IP that will front this new service. Azure Load Balancer では複数のフロントエンド IP を持つことができるため、デプロイされたそれぞれの新しいサービスによって、一意にアクセスされる新しい専用のフロントエンド IP が取得されます。Since the Azure Load Balancer can have multiple Frontend IPs, each new service deployed will get a new dedicated frontend IP to be uniquely accessed.

たとえば、次を実行して、サービスが作成され、ロード バランサーが構成されたことを確認できます。You can confirm your service is created and the load balancer is configured by running for example:

kubectl get service public-svc
NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

サービスの詳細を表示すると、ロード バランサー上のこのサービス用に作成されたパブリック IP アドレスが、EXTERNAL-IP 列に表示されます。When you view the service details, the public IP address created for this service on the load balancer is shown in the EXTERNAL-IP column. IP アドレスが、次の例に示すように <pending> から実際のパブリック IP アドレスに変わるまで、1 から 2 分かかることがあります。It may take a minute or two for the IP address to change from <pending> to an actual public IP address, as shown in the above example.

パブリック Standard Load Balancer を構成するConfigure the public standard load balancer

Standard SKU パブリック ロード バランサーを使用する場合、作成時、またはクラスターの更新時にカスタマイズできる一連のオプションがあります。When using the Standard SKU public load balancer, there's a set of options that can be customized at creation time or by updating the cluster. これらのオプションを使用すると、ワークロードのニーズに合わせて Load Balancer をカスタマイズできます。適宜確認する必要があります。These options allow you to customize the Load Balancer to meet your workloads needs and should be reviewed accordingly. Standard Load Balancer を使用すると、次の操作を行うことができます。With the Standard load balancer you can:

  • マネージド送信 IP の数の設定またはスケーリングSet or scale the number of Managed Outbound IPs
  • 独自のカスタム送信 IP または送信 IP プレフィックスの使用Bring your own custom Outbound IPs or Outbound IP Prefix
  • クラスターの各ノードに割り当てられる送信ポートの数のカスタマイズCustomize the number of allocated outbound ports to each node of the cluster
  • アイドル状態の接続のタイムアウト設定の構成Configure the timeout setting for idle connections

マネージド送信パブリック IP の数のスケーリングScale the number of managed outbound public IPs

Azure Load Balancer は、アウトバウンドだけでなく、仮想ネットワークからのインバウンド接続も提供します。Azure Load Balancer provides outbound connectivity from a virtual network in addition to inbound. アウトバウンド規則を使用すると、パブリック Standard Load Balancer の送信ネットワーク アドレス変換の構成を簡素化できます。Outbound rules make it simple to configure public Standard Load Balancer's outbound network address translation.

すべてのロード バランサー規則と同様に、アウトバウンド規則は、負荷分散規則およびアウトバウンド NAT 規則と同じ構文に従います。Like all Load Balancer rules, outbound rules follow the same familiar syntax as load balancing and inbound NAT rules:

フロントエンド IP + パラメーター + バックエンド プールfrontend IPs + parameters + backend pool

アウトバウンド規則では、フロントエンドに変換され、バックエンド プールによって識別されるすべての仮想マシンの送信 NAT を構成します。An outbound rule configures outbound NAT for all virtual machines identified by the backend pool to be translated to the frontend. また、パラメーターにより、送信 NAT アルゴリズムをさらに細かく制御できます。And parameters provide additional fine grained control over the outbound NAT algorithm.

アウトバウンド規則は 1 つのパブリック IP アドレスでのみ使用できますが、アウトバウンド規則によって、アウトバウンド NAT をスケーリングするための構成の負担が軽減されます。While an outbound rule can be used with just a single public IP address, outbound rules ease the configuration burden for scaling outbound NAT. 複数の IP アドレスを使用することで、大規模なシナリオを計画できます。また、アウトバウンド規則を使用して、SNAT が枯渇しやすいパターンを緩和することもできます。You can use multiple IP addresses to plan for large-scale scenarios and you can use outbound rules to mitigate SNAT exhaustion prone patterns. フロントエンドによって提供される追加の IP アドレスごとに、Load Balancer で SNAT ポートとして使用される 64,000 個の一時的なポートが提供されます。Each additional IP address provided by a frontend provides 64k ephemeral ports for Load Balancer to use as SNAT ports.

既定で作成されるマネージド送信パブリック IP で Standard SKU ロード バランサーを使用する場合、 load-balancer-managed-ip-count パラメーターを使用して、マネージド送信パブリック IP の数をスケーリングすることができます。When using a Standard SKU load balancer with managed outbound public IPs, which are created by default, you can scale the number of managed outbound public IPs using the load-balancer-managed-ip-count parameter.

既存のクラスターを更新するには、次のコマンドを実行します。To update an existing cluster, run the following command. このパラメーターをクラスター作成時に設定し、複数の管理対象送信パブリック IP を与えることもできます。This parameter can also be set at cluster create-time to have multiple managed outbound public IPs.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

上の例では、myResourceGroupmyAKSCluster クラスターに対して、管理対象の送信パブリック IP の数が 2 に設定されます。The above example sets the number of managed outbound public IPs to 2 for the myAKSCluster cluster in myResourceGroup.

また、 --load-balancer-managed-outbound-ip-count パラメーターを追加し、それを目的の値に設定してクラスターを作成する場合、 load-balancer-managed-ip-count パラメーターを使用して、マネージド送信パブリック IP の初期数を設定することもできます。You can also use the load-balancer-managed-ip-count parameter to set the initial number of managed outbound public IPs when creating your cluster by appending the --load-balancer-managed-outbound-ip-count parameter and setting it to your desired value. 管理対象の送信パブリック IP の既定数は 1 です。The default number of managed outbound public IPs is 1.

独自の送信パブリック IP またはプレフィックスを提供するProvide your own outbound public IPs or prefixes

Standard SKU ロード バランサーを使用する場合、既定で、AKS クラスターにより AKS で管理されるインフラストラクチャ リソース グループに、パブリック IP が自動的に作成され、それがロード バランサーの送信プールに割り当てられます。When you use a Standard SKU load balancer, by default the AKS cluster automatically creates a public IP in the AKS-managed infrastructure resource group and assigns it to the load balancer outbound pool.

AKS によって作成されるパブリック IP は、AKS 管理対象リソースと見なされます。A public IP created by AKS is considered an AKS managed resource. つまり、そのパブリック IP のライフサイクルは、AKS によって管理され、ユーザーがパブリック IP リソースを直接操作する必要はありません。This means the lifecycle of that public IP is intended to be managed by AKS and requires no user action directly on the public IP resource. 代わりに、クラスターの作成時に独自のカスタム パブリック IP またはパブリック IP プレフィックスを割り当てることもできます。Alternatively, you can assign your own custom public IP or public IP prefix at cluster creation time. また、既存のクラスターのロード バランサーのプロパティでカスタム IP を更新することもできます。Your custom IPs can also be updated on an existing cluster's load balancer properties.

注意

カスタム パブリック IP アドレスは、ユーザーが作成して所有する必要があります。Custom public IP addresses must be created and owned by the user. 管理の競合が発生するため、AKS によって作成されるマネージド パブリック IP アドレスを独自のカスタム IP として再使用することはできません。Managed public IP addresses created by AKS cannot be reused as a bring your own custom IP as it can cause management conflicts.

この操作を行う前に、送信 IP または送信 IP プレフィックスを構成するために必要な前提条件と制約を満たしていることをご確認ください。Before you do this operation, make sure you meet the pre-requisites and constraints necessary to configure Outbound IPs or Outbound IP prefixes.

クラスターを独自の送信パブリック IP で更新するUpdate the cluster with your own outbound public IP

az network public-ip show コマンドを使用すると、パブリック IP の ID が一覧表示されます。Use the az network public-ip show command to list the IDs of your public IPs.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

上のコマンドでは、myResourceGroup リソース グループの myPublicIP パブリック IP の IP が表示されます。The above command shows the ID for the myPublicIP public IP in the myResourceGroup resource group.

お使いのパブリック IP でクラスターを更新するには、 load-balancer-outbound-ips パラメーターを指定した az aks update コマンドを使用します。Use the az aks update command with the load-balancer-outbound-ips parameter to update your cluster with your public IPs.

次の例では、前のコマンドで得られた ID を指定した load-balancer-outbound-ips パラメーターを使用しています。The following example uses the load-balancer-outbound-ips parameter with the IDs from the previous command.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

独自の送信パブリック IP プレフィックスでクラスターを更新するUpdate the cluster with your own outbound public IP prefix

Standard SKU ロード バランサーと共に、エグレス用のパブリック IP プレフィックスを使用することもできます。You can also use public IP prefixes for egress with your Standard SKU load balancer. 次の例では、az network public-ip prefix show コマンドを使用し、パブリック IP プレフィックスの IP が一覧表示されます。The following example uses the az network public-ip prefix show command to list the IDs of your public IP prefixes:

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

上のコマンドでは、myResourceGroup リソース グループの myPublicIPPrefix パブリック IP プレフィックスの IP が表示されます。The above command shows the ID for the myPublicIPPrefix public IP prefix in the myResourceGroup resource group.

次の例では、load-balancer-outbound-ip-prefixes パラメーターと前のコマンドからの ID が使用されています。The following example uses the load-balancer-outbound-ip-prefixes parameter with the IDs from the previous command.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

独自のパブリック IP またはプレフィックスでクラスターを作成するCreate the cluster with your own public IP or prefixes

エグレス エンドポイントを許可リストに追加するといったシナリオをサポートする目的で、クラスター作成時に、エグレス用に独自の IP アドレスや IP プレフィックスを導入することがあります。You may wish to bring your own IP addresses or IP prefixes for egress at cluster creation time to support scenarios like adding egress endpoints to an allow list. クラスター作成手順に上のコードと同じパラメーターを追加し、クラスターのライフサイクルの開始時に独自のパブリック IP と IP プレフィックスを定義します。Append the same parameters shown above to your cluster creation step to define your own public IPs and IP prefixes at the start of a cluster's lifecycle.

load-balancer-outbound-ips パラメーターを指定して az aks create コマンドを使用し、開始時に自分のパブリック IP で新しいクラスターを作成します。Use the az aks create command with the load-balancer-outbound-ips parameter to create a new cluster with your public IPs at the start.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

load-balancer-outbound-ip-prefixes パラメーターを指定して az aks create コマンドを使用し、開始時に自分のパブリック IP プレフィックスで新しいクラスターを作成します。Use the az aks create command with the load-balancer-outbound-ip-prefixes parameter to create a new cluster with your public IP prefixes at the start.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

割り当てられた送信ポートを構成するConfigure the allocated outbound ports

重要

クラスター上に、少数の宛先に対して多数の接続を確立することが想定されるアプリケーションがある場合If you have applications on your cluster which are expected to establish a large number of connection to small set of destinations, eg. (たとえば、多数のフロントエンド インスタンスを 1 つの SQL DB に接続する場合)、SNAT ポートの枯渇 (接続元のポートの不足) が検出される可能性が非常に高くなります。many frontend instances connecting to an SQL DB, you have a scenario very susceptible to encounter SNAT Port exhaustion (run out of ports to connect from). このようなシナリオでは、ロード バランサーに割り当てられる送信ポートと送信フロントエンド IP を増加することを強くお勧めします。For these scenarios it's highly recommended to increase the allocated outbound ports and outbound frontend IPs on the load balancer. 増加する場合、1 つの追加 IP アドレスに対して 64,000 個のポートを追加し、すべてのクラスター ノード間で分散させることを考慮する必要があります。The increase should consider that one (1) additional IP address adds 64k additional ports to distribute across all cluster nodes.

特に指定がない限り、AKS では、構成時に Standard Load Balancer で定義される割り当て送信ポート数の既定値が使用されます。Unless otherwise specified, AKS will use the default value of Allocated Outbound Ports that Standard Load Balancer defines when configuring it. 次のコマンドで示すように、この値は、AKS API の場合は null で、SLB API の場合は 0 です。This value is null on the AKS API or 0 on the SLB API as shown by the below command:

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

上記のコマンドを実行すると、次の例に示すように、ロード バランサーのアウトバウンド規則が一覧表示されます。The previous commands will list the outbound rule for your load balancer, for example:

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus  

この出力は、ポート数が 0 であることを意味しているものではなく、バックエンド プールのサイズに基づく自動送信ポート割り当てを利用していることを意味しています。したがって、たとえば、クラスターのノード数が 50 以下の場合、各ノードに 1,024 個のポートが割り当てられます。その個数からノード数を増やしていくと、ノードあたりのポート数が徐々に削減されます。This output does not mean that you have 0 ports but instead that you are leveraging the automatic outbound port assignment based on backend pool size, so for example if a cluster has 50 or less nodes, 1024 ports for each node are allocated, as you increase the number of nodes from there you'll gradually get fewer ports per node.

割り当て送信ポート数を定義または増加するには、次の例のようにします。To define or increase the number of Allocated Outbound ports, you can follow the below example:

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

この例では、クラスター内の各ノードの割り当て送信ポート数が 4000 に設定され、IP 数は 7 個です。"ノードあたり 4000 ポート * 100 ノード = 合計 400,000 ポート < = 合計 448,000 ポート = 7 個の IP * IP あたり 64,000 ポート" になります。This example would give you 4000 Allocated Outbound Ports for each node in my cluster, and with 7 IPs you would have 4000 ports per node * 100 nodes = 400k total ports < = 448k total ports = 7 IPs * 64k ports per IP. これにより、100 ノードに安全にスケーリングすることができ、既定のアップグレード操作を行うことができます。This would allow you to safely scale to 100 nodes and have a default upgrade operation. アップグレードやその他の操作に必要な追加ノードに十分な数のポートを割り当てることが重要です。It is critical to allocate sufficient ports for additional nodes needed for upgrade and other operations. AKS では、アップグレード用のバッファー ノード数の既定値として 1 が使用されます。このため、この例では、任意の時点で 4,000 個の空きポートが必要です。AKS defaults to one buffer node for upgrade, in this example this requires 4000 free ports at any given point in time. maxSurge 値を使用する場合、ノードあたりの送信ポート数に maxSurge 値を乗算します。If using maxSurge values, multiply the outbound ports per node by your maxSurge value.

ノード数を 100 以上に安全にスケーリングするために、IP をさらに追加する必要があります。To safely go above 100 nodes, you'd have to add more IPs.

重要

接続またはスケーリングの問題を回避するために allocatedOutboundPorts をカスタマイズする前に、必要なクォータを計算し、要件を確認する必要があります。You must calculate your required quota and check the requirements before customizing allocatedOutboundPorts to avoid connectivity or scaling issues.

また、クラスターの作成時に load-balancer-outbound-ports パラメーターを使用することもできます。ただし、 load-balancer-managed-outbound-ip-countload-balancer-outbound-ips 、または load-balancer-outbound-ip-prefixes のいずれかも指定する必要があります。You can also use the load-balancer-outbound-ports parameters when creating a cluster, but you must also specify either load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips, or load-balancer-outbound-ip-prefixes as well. 次に例を示します。For example:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-sku standard \
    --load-balancer-managed-outbound-ip-count 2 \
    --load-balancer-outbound-ports 1024 

ロード バランサーのアイドル タイムアウトを構成するConfigure the load balancer idle timeout

SNAT ポート リソースがなくなると、既存のフローによって SNAT ポートが解放されない限り、送信フローは失敗します。When SNAT port resources are exhausted, outbound flows fail until existing flows release SNAT ports. Load Balancer は、フローが終了すると SNAT ポートを回収します。また、AKS で構成されたロード バランサーは、30 分間のアイドル タイムアウトを使用して、アイドル フローから SNAT ポートを回収します。Load Balancer reclaims SNAT ports when the flow closes and the AKS-configured load balancer uses a 30-minute idle timeout for reclaiming SNAT ports from idle flows. さあに、トランスポート (たとえば、 TCP keepalives ) または application-layer keepalives を使用して、アイドル フローを更新し、必要に応じて、このアイドル タイムアウトをリセットすることもできます。You can also use transport (for example, TCP keepalives) or application-layer keepalives to refresh an idle flow and reset this idle timeout if necessary. このタイムアウトは、次の例で示すように構成することができます。You can configure this timeout following the below example:

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

存続期間が短い接続が多数あることが想定される場合、および存続期間が長く、アイドル時間が長い可能性のある接続がない場合 (kubectl proxy または kubectl port-forward を利用する場合など)、4 分などの短いタイムアウト値の使用を検討してください。If you expect to have numerous short lived connections, and no connections that are long lived and might have long times of idle, like leveraging kubectl proxy or kubectl port-forward consider using a low timeout value such as 4 minutes. また、TCP keepalives を使用する場合、接続の一方の側でそれを有効にするだけで十分です。Also, when using TCP keepalives, it's sufficient to enable them on one side of the connection. たとえば、フローのアイドル タイマーをリセットするには、TCP keepalives をサーバー側でのみ有効にすれば十分であり、両側で開始する必要はありません。For example, it's sufficient to enable them on the server side only to reset the idle timer of the flow and it's not necessary for both sides to start TCP keepalives. データベースのクライアント/サーバー構成など、アプリケーション レイヤーにも同様の概念があります。Similar concepts exist for application layer, including database client-server configurations. サーバー側で、アプリケーション固有のキープアライブのどのようなオプションが存在するかを確認します。Check the server side for what options exist for application-specific keepalives.

重要

AKS では、既定で、アイドル時の TCP リセットが有効になっています。この構成を維持して、ご自分のシナリオでのアプリケーションの動作をより予測可能にするために使用することをお勧めします。AKS enables TCP Reset on idle by default and recommends you keep this configuration on and leverage it for more predictable application behavior on your scenarios. TCP RST は、ESTABLISHED 状態の TCP 接続時のみ送信されます。TCP RST is only sent during TCP connection in ESTABLISHED state. 詳細については、こちらを参照してください。Read more about it here.

割り当て送信ポート数とアイドル タイムアウトをカスタマイズするための要件Requirements for customizing allocated outbound ports and idle timeout

  • allocatedOutboundPorts に指定する値は、8 の倍数である必要もあります。The value you specify for allocatedOutboundPorts must also be a multiple of 8.
  • ノードの VM の数と割り当てる必要がある送信ポートの数に基づいた十分な送信 IP 容量が必要です。You must have enough outbound IP capacity based on the number of your node VMs and required allocated outbound ports. 送信 IP 容量が十分であることを確認するには、次の式を使用します。To validate you have enough outbound IP capacity, use the following formula:

outboundIPs * 64,000 > nodeVMs * desiredAllocatedOutboundPortsoutboundIPs * 64,000 > nodeVMs * desiredAllocatedOutboundPorts.

たとえば、nodeVMs が 3 で、desiredAllocatedOutboundPorts が 50,000 の場合、必要な outboundIPs は 3 以上です。For example, if you have 3 nodeVMs, and 50,000 desiredAllocatedOutboundPorts, you need to have at least 3 outboundIPs. 必要最低限の量より多くの送信 IP 容量を組み込むことをお勧めします。It is recommended that you incorporate additional outbound IP capacity beyond what you need. また、送信 IP 容量を計算するときは、クラスター オートスケーラーと、ノード プールのアップグレードの可能性を考慮する必要があります。Additionally, you must account for the cluster autoscaler and the possibility of node pool upgrades when calculating outbound IP capacity. クラスター オートスケーラーについては、現在のノード数と最大ノード数を確認し、高い方の値を使用します。For the cluster autoscaler, review the current node count and the maximum node count and use the higher value. アップグレードについては、アップグレードが可能なすべてのノード プールに対して追加のノード VM を考慮します。For upgrading, account for an additional node VM for every node pool that allows upgrading.

  • IdleTimeoutInMinutes を既定の 30 分とは異なる値に設定する場合は、ワークロードで送信接続が必要な時間を考慮します。When setting IdleTimeoutInMinutes to a different value than the default of 30 minutes, consider how long your workloads will need an outbound connection. また、AKS の外部で使用される Standard SKU ロード バランサーの既定のタイムアウト値が 4 分であることを考慮します。Also consider the default timeout value for a Standard SKU load balancer used outside of AKS is 4 minutes. 特定の AKS ワークロードをより正確に反映するように IdleTimeoutInMinutes の値を設定すると、使用されなくなった接続と関連付けられることによる SNAT の枯渇を減らすのに役立ちます。An IdleTimeoutInMinutes value that more accurately reflects your specific AKS workload can help decrease SNAT exhaustion caused by tying up connections no longer being used.

警告

AllocatedOutboundPortsIdleTimeoutInMinutes の値を変更すると、ロード バランサーの動作が大幅に変更される可能性があるため、トレードオフおよびアプリケーションの接続パターンをよく理解してから変更してください。これらの値を変更する前に、後の SNAT のトラブルシューティングに関するセクションを確認し、Load Balancer のアウトバウンド規則およびAzure での送信接続を確認して、変更の影響を完全に理解してください。Altering the values for AllocatedOutboundPorts and IdleTimeoutInMinutes may significantly change the behavior of the outbound rule for your load balancer and should not be done lightly, without understanding the tradeoffs and your application's connection patterns, check the SNAT Troubleshooting section below and review the Load Balancer outbound rules and outbound connections in Azure before updating these values to fully understand the impact of your changes.

受信トラフィックを特定の IP 範囲に制限するRestrict inbound traffic to specific IP ranges

既定では、ロード バランサーの仮想ネットワークに関連付けられているネットワーク セキュリティ グループ (NSG) には、すべての受信外部トラフィックを許可する規則があります。The Network Security Group (NSG) associated with the virtual network for the load balancer, by default, has a rule to allow all inbound external traffic. この規則を更新して、受信トラフィックに特定の IP 範囲のみを許可することができます。You can update this rule to only allow specific IP ranges for inbound traffic. 次のマニフェストでは loadBalancerSourceRanges を使用して、受信外部トラフィックの新しい IP 範囲を指定します。The following manifest uses loadBalancerSourceRanges to specify a new IP range for inbound external traffic:

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

インバウンド接続時にクライアントの IP を維持するMaintain the client's IP on inbound connections

既定では、Kubernetes および AKS 内の LoadBalancer 型のサービスは、ポッドへの接続時にクライアントの IP アドレスを保持しません。By default, a service of type LoadBalancer in Kubernetes and in AKS won't persist the client's IP address on the connection to the pod. ポッドに配信されるパケットの送信元 IP は、ノードのプライベート IP になります。The source IP on the packet that's delivered to the pod will be the private IP of the node. クライアントの IP アドレスを維持するには、サービス定義で service.spec.externalTrafficPolicylocal に設定する必要があります。To maintain the client’s IP address, you must set service.spec.externalTrafficPolicy to local in the service definition. 次のマニフェストに例を示します。The following manifest shows an example:

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Kubernetes 注釈による追加のカスタマイズAdditional customizations via Kubernetes Annotations

Kubernetes サービスでサポートされている、種類が LoadBalancer である注釈の一覧を次に示します。これらの注釈は、INBOUND フローにのみ適用されます。Below is a list of annotations supported for Kubernetes services with type LoadBalancer, these annotations only apply to INBOUND flows:

AnnotationAnnotation Value 説明Description
service.beta.kubernetes.io/azure-load-balancer-internal true または falsetrue or false ロード バランサーが内部である必要があるかどうかを指定します。Specify whether the load balancer should be internal. 設定しない場合、既定で public が使用されます。It’s defaulting to public if not set.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet サブネットの名前Name of the subnet 内部ロード バランサーをバインドする必要があるサブネットを指定します。Specify which subnet the internal load balancer should be bound to. 設定しない場合、既定で、クラウド構成ファイルで構成されているサブネットが使用されます。It’s defaulting to the subnet configured in cloud config file if not set.
service.beta.kubernetes.io/azure-dns-label-name パブリック IP 上の DNS ラベルの名前Name of the DNS label on Public IPs パブリック サービスの DNS ラベル名を指定します。Specify the DNS label name for the public service. 空の文字列に設定すると、パブリック IP の DNS エントリは使用されません。If it is set to empty string, the DNS entry in the Public IP will not be used.
service.beta.kubernetes.io/azure-shared-securityrule true または falsetrue or false 別のサービスと共有される可能性のある Azure セキュリティ規則を使用してサービスを公開する必要があることを指定します。公開できるサービス数が増えるとサービスの特異性は低下します。Specify that the service should be exposed using an Azure security rule that may be shared with another service, trading specificity of rules for an increase in the number of services that can be exposed. この注釈は、ネットワーク セキュリティ グループの Azure 拡張セキュリティ規則機能に依存します。This annotation relies on the Azure Augmented Security Rules feature of Network Security groups.
service.beta.kubernetes.io/azure-load-balancer-resource-group リソース グループの名前Name of the resource group クラスター インフラストラクチャと同一のリソース グループ (ノード リソース グループ) 内にないロード バランサーのパブリック IP のリソース グループを指定します。Specify the resource group of load balancer public IPs that aren't in the same resource group as the cluster infrastructure (node resource group).
service.beta.kubernetes.io/azure-allowed-service-tags 許可されるサービス タグの一覧List of allowed service tags 許可されるサービス タグをコンマで区切った一覧指定します。Specify a list of allowed service tags separated by comma.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout TCP アイドル タイムアウト (分)TCP idle timeouts in minutes ロード バランサーで TCP 接続のアイドル タイムアウトが発生するまでの時間を分数で指定します。Specify the time, in minutes, for TCP connection idle timeouts to occur on the load balancer. 既定値は 4 で、これが最小値です。Default and minimum value is 4. 最大値は 30 です。Maximum value is 30. 整数を指定する必要があります。Must be an integer.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true SLB の enableTcpReset を無効にします。Disable enableTcpReset for SLB

SNAT のトラブルシューティングTroubleshooting SNAT

同じ宛先 IP アドレスとポートに対して多数の TCP 送信接続または UDP 送信接続が開始されることがわかっている場合、送信接続エラーが発生する場合、または SNAT ポート (PAT によって使用される一時的なポート) が不足しているとサポートから指摘された場合、一般的な軽減策としていくつかの選択肢があります。If you know that you're starting many outbound TCP or UDP connections to the same destination IP address and port, and you observe failing outbound connections or are advised by support that you're exhausting SNAT ports (preallocated ephemeral ports used by PAT), you have several general mitigation options. これらのオプションを確認し、使用可能であり、実際のシナリオに最適な選択肢を判断してください。Review these options and decide what is available and best for your scenario. それらを 1 つまたは複数組み合わせることが状況改善に役立つ場合もあります。It's possible that one or more can help manage this scenario. 詳細については、アウトバウンド接続のトラブルシューティング ガイドに関するページをご確認ください。For detailed information, review the Outbound Connections Troubleshooting Guide.

多くの場合、SNAT が枯渇する根本的な原因は、アウトバウンド接続の確立方法と管理方法、または構成可能なタイマーの既定値に対する変更のアンチパターンです。Frequently the root cause of SNAT exhaustion is an anti-pattern for how outbound connectivity is established, managed, or configurable timers changed from their default values. このセクションの内容を慎重に検討してください。Review this section carefully.

手順Steps

  1. 接続のアイドル状態が長時間続いているかどうか、および既定のアイドル タイムアウトに基づいてそのポートが解放されているかどうかを確認します。Check if your connections remain idle for a long time and rely on the default idle timeout for releasing that port. そうである場合は、ご使用のシナリオのタイムアウト値を既定の 30 分より短くする必要があります。If so the default timeout of 30 min might need to be reduced for your scenario.
  2. 対象のアプリケーションで送信接続をどのように作成しているかを調査します (たとえば、コード レビューやパケット キャプチャ)。Investigate how your application is creating outbound connectivity (for example, code review or packet capture).
  3. このアクティビティが予期される動作であるかどうか、またはアプリケーションが誤動作しているかどうかを判断します。Determine if this activity is expected behavior or whether the application is misbehaving. Azure Monitor でメトリックログを使用して、調査結果を実証します。Use metrics and logs in Azure Monitor to substantiate your findings. たとえば、SNAT 接続メトリックの "失敗" カテゴリを使用します。Use "Failed" category for SNAT Connections metric for example.
  4. 適切なパターンに従っているかどうかを評価します。Evaluate if appropriate patterns are followed.
  5. SNAT ポートの枯渇が、送信 IP アドレスの追加と割り当て送信ポート数の追加によって軽減されるかどうかを評価します。Evaluate if SNAT port exhaustion should be mitigated with additional Outbound IP addresses + additional Allocated Outbound Ports .

設計パターンDesign patterns

可能な場合は常に、接続の再利用と接続プールを利用してください。Always take advantage of connection reuse and connection pooling whenever possible. これらのパターンは、リソース枯渇の問題を回避し、予測可能な動作をもたらします。These patterns will avoid resource exhaustion problems and result in predictable behavior. これらのパターンのプリミティブは、多くの開発ライブラリとフレームワークに含まれています。Primitives for these patterns can be found in many development libraries and frameworks.

  • 通常、アトミック要求 (接続ごとに 1 つの要求) は、設計の選択肢として適切ではありません。Atomic requests (one request per connection) are generally not a good design choice. そのようなアンチパターンにより規模が制限され、パフォーマンスと信頼性が低下されます。Such anti-pattern limits scale, reduces performance, and decreases reliability. 代わりに、HTTP/S 接続を再利用し、接続と関連付けられている SNAT ポートの数を減らします。Instead, reuse HTTP/S connections to reduce the numbers of connections and associated SNAT ports. TLS を利用すると、ハンドシェイク、オーバーヘッド、暗号化操作による代償が減るため、アプリケーションのスケールとパフォーマンスが向上します。The application scale will increase and performance improve because of reduced handshakes, overhead, and cryptographic operation cost when using TLS.
  • クラスター外、またはカスタム DNS を使用している場合、または coreDNS 上でカスタム アップストリーム サーバーを使用している場合は、クライアントが DNS リゾルバーの結果をキャッシュしていないときに、DNS で大量の個別フローが発生する可能性があることにご注意ください。If you're using out of cluster/custom DNS, or custom upstream servers on coreDNS have in mind that DNS can introduce many individual flows at volume when the client isn't caching the DNS resolvers result. カスタム DNS サーバーを使用する代わりに、まず、coreDNS をカスタマイズして、適切なキャッシュ値を定義してください。Make sure to customize coreDNS first instead of using custom DNS servers, and define a good caching value.
  • UDP フロー (DNS 参照など) によって、アイドル時間中、SNAT ポートが割り当てられます。UDP flows (for example DNS lookups) allocate SNAT ports for the duration of the idle timeout. アイドル時間が長くなると、SNAT ポートにかかる圧力がそれだけ高くなります。The longer the idle timeout, the higher the pressure on SNAT ports. 短いアイドル タイムアウト (4 分など) を使用します。Use short idle timeout (for example 4 minutes). 接続プールを使用し、接続ボリュームを形成します。Use connection pools to shape your connection volume.
  • 警告なしで TCP フローを破棄し、TCP タイマーに依存してフローを消去することは決してしないでください。Never silently abandon a TCP flow and rely on TCP timers to clean up flow. TCP で明示的に接続を閉じなかった場合、中間システムとエンドポイントで状態が割り当てられたままになり、他の接続に SNAT ポートを利用できなくなります。If you don't let TCP explicitly close the connection, state remains allocated at intermediate systems and endpoints and makes SNAT ports unavailable for other connections. このパターンによって、アプリケーション エラーと SNAT 枯渇がトリガーされる可能性があります。This pattern can trigger application failures and SNAT exhaustion.
  • OS レベルの TCP 終了関連のタイマー値は、影響が専門的にわからない場合、変更しないでください。Don't change OS-level TCP close related timer values without expert knowledge of impact. TCP スタックの復旧中、接続のエンドポイントで期待値が一致しない場合、アプリケーションのパフォーマンスが低下する可能性があります。While the TCP stack will recover, your application performance can be negatively affected when the endpoints of a connection have mismatched expectations. タイマーの変更が必要になる場合、通常、基になる設計に問題があることを示しています。Wishing to change timers is usually a sign of an underlying design problem. 次の推奨事項をご確認ください。Review following recommendations.

上の例では、MY_EXTERNAL_IP_RANGE 範囲からの外部トラフィックのみを許可するように規則を更新します。The above example updates the rule to only allow inbound external traffic from the MY_EXTERNAL_IP_RANGE range. MY_EXTERNAL_IP_RANGE を内部サブネットの IP アドレスに置き換えると、トラフィックはクラスターの内部 IP のみに制限されます。If you replace MY_EXTERNAL_IP_RANGE with the internal subnet IP address, traffic is restricted to cluster internal IPs only. これにより、Kubernetes クラスター外部のクライアントは、ロード バランサーにアクセスできなくなります。This will not allow clients from outside of your Kubernetes cluster to access the load balancer.

ロード バランサーを Basic SKU から Standard SKU に移行するMoving from a basic SKU load balancer to standard SKU

既存のクラスターに Basic SKU ロード バランサーが与えられている場合、Standard SKU ロード バランサーでクラスターを使用する目的で移行するとき、動作に重大な違いがあることにご留意ください。If you have an existing cluster with the Basic SKU Load Balancer, there are important behavioral differences to note when migrating to use a cluster with the Standard SKU Load Balancer.

たとえば、load-balancer-sku 型のクラスターをクラスターの作成時にのみ定義できる場合、一般的に blue/green のデプロイでクラスターを移行します。For example, making blue/green deployments to migrate clusters is a common practice given the load-balancer-sku type of a cluster can only be defined at cluster create time. ただし、Basic SKU ロード バランサーでは、Basic SKU IP アドレスが使用され、Standard SKU IP アドレスを必要とする Standard SKU ロード バランサーと互換性がありません。However, Basic SKU Load Balancers use Basic SKU IP Addresses, which aren't compatible with Standard SKU Load Balancers as they require Standard SKU IP Addresses. クラスターを移行してロード バランサー SKU をアップグレードするとき、IP アドレス SKU に互換性がある新しい IP アドレスが必須となります。When migrating clusters to upgrade Load Balancer SKUs, a new IP address with a compatible IP Address SKU will be required.

クラスターの移行方法に関して他に注意すべき事項については、移行時の考慮事項に関するドキュメントを参照してください。移行時に考慮すべき重要なトピックが一覧表示されています。For more considerations on how to migrate clusters, visit our documentation on migration considerations to view a list of important topics to consider when migrating. 以下の制限事項も、AKS で Standard SKU ロード バランサーを使用するときに注意すべき、動作上の重要な違いです。The below limitations are also important behavioral differences to note when using Standard SKU Load Balancers in AKS.

制限事項Limitations

Standard SKU を使用するロード バランサーをサポートする AKS クラスターを作成し、管理する場合、次の制限が適用されます。The following limitations apply when you create and manage AKS clusters that support a load balancer with the Standard SKU:

  • AKS クラスターからのエグレス トラフィックを許可するために、パブリック IP または IP プレフィックスが少なくとも 1 つ必要です。At least one public IP or IP prefix is required for allowing egress traffic from the AKS cluster. パブリック IP または IP プレフィックスは、コントロール プレーンとエージェント ノードの間の接続を維持するため、および前のバージョンの AKS との互換性を維持するためにも必要です。The public IP or IP prefix is also required to maintain connectivity between the control plane and agent nodes and to maintain compatibility with previous versions of AKS. Standard SKU ロード バランサーでパブリック IP または IP プレフィックスを指定するための次のオプションがあります:You have the following options for specifying public IPs or IP prefixes with a Standard SKU load balancer:
    • 独自のパブリック IP を指定する。Provide your own public IPs.
    • 独自のパブリック IP プレフィックスを指定する。Provide your own public IP prefixes.
    • 最大 100 までの数字を指定し、AKS クラスターとして作成された同じリソース グループでそれだけの数の Standard SKU パブリック IP を作成することを AKS クラスターに許可します。名前は通常、MC_ で始まります。Specify a number up to 100 to allow the AKS cluster to create that many Standard SKU public IPs in the same resource group created as the AKS cluster, which is usually named with MC_ at the beginning. AKS により、パブリック IP が Standard SKU ロード バランサーに割り当てられます。AKS assigns the public IP to the Standard SKU load balancer. 既定では、パブリック IP、パブリック IP プレフィックス、または IP の数が指定されていない場合、同じリソース グループでパブリック IP が 1 つ自動的に作成されます。By default, one public IP will automatically be created in the same resource group as the AKS cluster, if no public IP, public IP prefix, or number of IPs is specified. また、パブリック アドレスを許可する必要があり、IP 作成を禁止する Azure Policy は作成しないようにする必要があります。You also must allow public addresses and avoid creating any Azure Policy that bans IP creation.
  • AKS によって作成されるパブリック IP は、独自のカスタム パブリック IP アドレスとして再使用することはできません。A public IP created by AKS cannot be reused as a custom bring your own public IP address. すべてのカスタム IP アドレスは、ユーザーによって作成され、管理される必要があります。All custom IP addresses must be created and managed by the user.
  • ロード バランサー SKU は、AKS クラスターの作成時にのみ定義できます。Defining the load balancer SKU can only be done when you create an AKS cluster. AKS クラスターが作成された後にロード バランサー SKU を変更することはできません。You can't change the load balancer SKU after an AKS cluster has been created.
  • 1 つのクラスターで使用できるロード バランサー SKU (Basic または Standard) の種類は 1 つのみです。You can only use one type of load balancer SKU (Basic or Standard) in a single cluster.
  • Standard SKU ロード バランサーでは、Standard SKU IP アドレスのみがサポートされています。Standard SKU Load Balancers only support Standard SKU IP Addresses.

次のステップNext steps

Kubernetes サービスのドキュメントで Kubernetes サービスについて学習する。Learn more about Kubernetes services at the Kubernetes services documentation.

受信トラフィックに内部 Load Balancer を使用する方法の詳細については、AKS の内部ロード バランサーに関するドキュメントを参照してください。Learn more about using Internal Load Balancer for Inbound traffic at the AKS Internal Load Balancer documentation.