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

Azure Load Balancer は、受信と送信の両方のシナリオがサポートされる開放型システム間相互接続 (OSI) モデルのレイヤー 4 上で動作します。 これにより、ロード バランサーのフロントエンドに到着した受信フローが、バックエンド プールのインスタンスに分配されます。

パブリック ロード バランサーを AKS と統合すると、次の 2 つの目的を達成することができます。

  • プライベート IP アドレスを送信プールのパブリック IP アドレス部分に変換して、AKS 仮想ネットワーク (VNet) 内のクラスター ノードへの 送信接続を提供します。
  • LoadBalancerの種類の Kubernetes サービスを介してアプリケーションへのアクセスを提供することで、アプリケーションを簡単にスケーリングし、高可用性サービスを作成できます。

この記事では、AKS でのパブリック ロード バランサーとの統合について説明します。 内部ロード バランサーの統合については、「AKS で内部ロード バランサーを使用する」を参照してください。

[前提条件]

  • AKS では Standard SKU Azure Load Balancerがサポートされています。これは、AKS クラスターの作成時に既定で使用されます。 Standard SKU を使用すると、大規模なバックエンド プール、複数のノード プール、Availability Zonesなどの機能にアクセスでき、既定でセキュリティで保護されます。 Basic SKU は 2025 年 9 月 30 日に廃止され、AKS ではサポートされなくなりました。 Basic SKU を使用する既存の AKS クラスターがある場合は、「AKS での Basic Load Balancer からのアップグレード」を参照してください。 Load Balancer SKU の詳細については、Azure Load Balancer SKU の比較をご覧ください。
  • 型 LoadBalancerを持つ Kubernetes サービスでサポートされている注釈の完全なリストについては、「LoadBalancer 注釈」を参照してください。
  • この記事では、Standard SKU Azure Load Balancer を持つ AKS クラスターがあることを前提としています。 AKS クラスターが必要な場合は、 Azure CLI、 Azure PowerShell、または Azure portal を使用して作成できます。
  • AKS クラスターに接続するには、 kubectl インストールして構成する必要があります。 kubectlをインストールし、クラスターの資格情報をダウンロードし、接続を確認するには、「クラスターへの接続」を参照してください。

Important

独自のゲートウェイ、ファイアウォールまたはプロキシを使用してアウトバウンド接続を行いたい場合は、アウトバウンドの種類を UserDefinedRouting (UDR) として使用することで、ロード バランサーのアウトバウンド プールとそれぞれのフロントエンド IP の作成をスキップできます。 送信の種類では、クラスターのエグレス方法を定義します。既定の種類は、LoadBalancer です。

Limitations

Standard SKU を使用するロード バランサーをサポートする AKS クラスターを作成し、管理する場合、次の制限が適用されます。

  • AKS は、エージェント ノードのライフサイクルと操作を管理します。 エージェント ノードに関連付けられている IaaS リソースの変更はサポートされていません。 サポートされていない操作の例として、ロード バランサー リソース グループに手動で変更を加えるというものがあります。

  • AKS クラスターからのエグレス トラフィックを許可するために、パブリック IP または IP プレフィックスが少なくとも 1 つ必要です。 パブリック IP または IP プレフィックスは、コントロール プレーンとエージェント ノードの間の接続を維持し、前のバージョンの AKS との互換性を維持するために必要です。 Standard SKU ロード バランサーを使用してパブリック IP または IP プレフィックスを指定するには、次のオプションがあります。

    • 独自のパブリック IP を指定する。
    • 独自のパブリック IP プレフィックスを指定する。
    • 最大 100 までの数字を指定し、それだけの数の Standard SKU パブリック IP を、AKS クラスターと同じリソース グループで作成することを AKS クラスターに許可します。 このリソース グループは、通常、先頭に MC_ で名前が付けられます。 AKS により、パブリック IP が Standard SKU ロード バランサーに割り当てられます。 既定では、パブリック IP、パブリック IP プレフィックス、または IP の数が指定されていない場合、AKS クラスターと同じリソース グループに 1 つのパブリック IP が自動的に作成されます。 また、パブリック アドレスを許可する必要があり、IP 作成を禁止する Azure ポリシーは作成しないようにする必要があります。

  • AKS によって作成されたパブリック IP は、カスタム Bring Your Own (BYO) パブリック IP アドレスとして再利用できません。 すべてのカスタム IP アドレスを作成して管理する必要があります。

  • AKS で管理されるロード バランサー リソースを直接変更して、ロード バランサー SKU を変更することはできません。 廃止された Basic SKU から Standard SKU に既存の AKS クラスターを移行するには、サポートされている AKS アップグレード プロセスを使用します。 移行によってダウンタイムが発生し、開始後にロールバックすることはできません。

  • Standard SKU ロード バランサーでは、Standard SKU IP アドレスのみがサポートされています。

  • ロード バランサーのバックエンド プールの種類が に設定されている場合、nodeIPはサポートされません。

AKS でロード バランサー サービスを作成する

アウトバウンドのタイプとして LoadBalancer (既定) に設定して AKS クラスターを作成した後に、クラスターは、ロード バランサーを使用してサービスを公開できるようになります。

  1. クラスターで少なくとも 1 つの実行済みポッドと app: public-app ラベルがあることを確認します。 次の手順のサービス マニフェストでは、このラベルを持つポッドが選択されますが、デプロイは作成されません。

    kubectl get pods -l app=public-app

  2. public-svc.yaml という名前のサービス マニフェストを作成します。これにより、 タイプが LoadBalancer のパブリック サービスが作成されます。

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

ロード バランサーの IP アドレスを指定する

ロード バランサーで特定の IP アドレスを使用する場合は、IP アドレスを指定する 2 つのオプションがあります。

  • サービス注釈を設定する (推奨): service.beta.kubernetes.io/azure-pip-name を使用して、既存のパブリック IP リソースを名前で指定します。 このアノテーションは最も効率的な選択肢であり、スロットリングが発生する可能性を回避するのに役立ちます。 IPv4 アドレスには service.beta.kubernetes.io/azure-load-balancer-ipv4 を使用し、IPv6 アドレスには service.beta.kubernetes.io/azure-load-balancer-ipv6 を使用することもできます。 パブリック IP リソース、リソース グループ、ID の要件については、「 AKS ロード バランサーで静的パブリック IP アドレスを使用する」を参照してください。
  • LoadBalancerIP プロパティをロード バランサーの YAML マニフェストに追加する: Service.Spec.LoadBalancerIP プロパティをロード バランサーの YAML マニフェストに追加します。 このフィールドは 、アップストリームの Kubernetes に続いて非推奨となり、デュアル スタックはサポートされていません。 現在の使用方法は変わらず、既存のサービスは変更せずに動作することが期待されます。

ロード バランサー サービス マニフェストをデプロイする

  1. kubectl apply を使用してパブリック サービス マニフェストをデプロイし、YAML マニフェストの名前を指定します。

    kubectl apply -f public-svc.yaml

    Azure Load Balancer は、新しいサービスの前に新しいパブリック IP を使用して構成されます。 Azure Load Balancer には複数のフロントエンド IP を含めることができるため、デプロイする新しいサービスごとに、新しい専用フロントエンド IP が一意にアクセスされます。

  2. サービスが作成され、 kubectl get service コマンドを使用してロード バランサーが構成されていることを確認します。

    kubectl get service public-svc

    サービスの詳細を表示すると、ロード バランサーでこのサービス用に作成されたパブリック IP アドレスが出力の EXTERNAL-IP 列に表示されます。 IP アドレスが "<保留中>" から実際のパブリック IP アドレスに変わるまで、数分かかることがあります。 次の出力例は、サービスの正常な作成を示しています。

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

  3. kubectl describe service コマンドを使用して、サービスに関する詳細情報を取得します。

    kubectl describe service public-svc

    次の出力例は、kubectl describe service を実行した後の出力の圧縮バージョンです。 "LoadBalancer イングレス" には、サービスによって公開される外部 IP アドレスが表示されます。 IP には内部アドレスが表示されます。

    Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        203.0.113.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

次のステップ

AKS でパブリック標準ロード バランサーを設定する

  • Last updated on