Azure Kubernetes Service (AKS) の Basic Load Balancer からのアップグレード

この記事では、Basic Load Balancer インスタンスを Azure Kubernetes Services (AKS) 上の Standard Load Balancer にアップグレードする方法について説明します。 すべての運用インスタンスに Standard Load Balancer を使用することをお勧めします。 あなたのインフラストラクチャに多くの重要な違いをもたらします。 AKS の外部の Basic Load Balancer から Standard Load Balancer へのアップグレードに関するガイダンスについては、 Basic Load Balancer のアップグレードに関する公式ガイダンスを参照してください。

Important

2025 年 9 月 30 日から、Azure Kubernetes Service (AKS) は Basic Load Balancer をサポートしなくなりました。 潜在的なサービス中断を回避するために、新しいデプロイに Standard Load Balancer を使用し、 既存のデプロイを Standard Load Balancer にアップグレードすることをお勧めします。 この提供終了の詳細については、 廃止に関する GitHub の問題 と Azure 更新プログラムの提供終了に関する発表を参照してください。 お知らせや更新情報を常に把握するには、 AKS のリリース ノートに従ってください。

Note

可用性セットと Basic Load Balancer の両方を使用するクラスターでは、両方の移行を一度に実行するために実行する必要がある個別の az aks update コマンドがあります (可用性セットから仮想マシン ノード プール、Basic Load Balancer から Standard Load Balancer)。 この移行を実行する手順については、 可用性セットの移行 ガイダンスを参照してください。

開始する前に

移行を開始する前に、次の情報を確認してください。

  • 移行中にダウンタイムが発生します。 それに応じてダウンタイムを計画します。
  • 移行が開始されると、ロールバックは許可されません。
  • このプロセスでは、Basic IP を Standard IP に移行し、ロード バランサーに関連付けられている受信 IP アドレスも同じままにします。 クラスターエグレス トラフィックを処理するために、新しいパブリック IP が作成され、Standard Load Balancer の送信規則に関連付けられます。

[前提条件]

移行を実行するには、クラスターが次の前提条件を満たしている必要があります。

  • このスクリプトの最小 Kubernetes バージョンは 1.27 です。 AKS クラスターをアップグレードする必要がある場合は、「 AKS クラスターのアップグレード」を参照してください。
  • Azure CLI がインストールされている必要があります。 必要な最小バージョンは 2.76.0 です。
  • クラスターで秘密キー コンテナーを使用して Key Management Service を実行する場合は、移行を実行する前に Key Management Service を無効にする必要があります。 詳細については、「 KMS をオフにする」を参照してください。
  • 移行を実行する前に、 ValidatingAdmissionWebhooks または MutatingAdmissionWebhooks を無効にする必要があります。

Basic Load Balancer を Standard Load Balancer にアップグレードする

  1. az aks update フラグが --load-balancer-sku に設定されている Standard コマンドを使用して、Basic Load Balancer を Standard Load Balancer にアップグレードします。

    az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku=Standard

  2. az aks show コマンドを使用して、移行が成功したことを確認します。

    az aks show \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP

    出力で、 load-balancer の種類が Standard に設定されていることを確認します。

  3. kubectl get podsコマンドとkubectl get svc コマンドを使用して、すべてのポッドとサービスが正常に実行されていることを確認します。

    kubectl get svc -A
kubectl get pods -A

新しい送信 IP アドレスを確認する

送信規則に関連付けられている新しい IP アドレスを確認するには、IP アドレスのリソース ID を確認してから、IP アドレスを一覧表示します。

  1. az aks show コマンドを使用して、送信 IP アドレスのリソース ID を取得します。

    az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

  2. az network public-ip show コマンドを使用して、各リソース ID の新しい IP アドレスを取得します。

    az network public-ip show --ids $IP_RESOURCE_ID --query ipAddress -o tsv

FAQ

新しい AKS クラスターの作成またはアップグレード時に Error: “Load Balancer SKU 'basic' is invalid; must use 'standard'. が発生する理由

特定の AKS 操作で Basic Load Balancer SKU が非推奨になり、一部のリージョンで作成がブロックされるようになりました。

この問題を解決するには、新しいクラスターを作成するときに --load-balancer-sku standard を指定してください。 例えば次が挙げられます。

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --load-balancer-sku standard

Basic Load Balancer を Standard Load Balancer にそのまま変更できないのはなぜですか?

Load Balancer SKU は、クラスターによって所有されるマネージド リソースであるため、AKS での作成後は変更できません。

これは、次のいずれかのオプションを使用して解決できます。

  • オプション 1: az aks update run コマンドを使用して、Basic Load Balancer を Standard にアップグレードします。 詳細については、「 Azure Kubernetes Service (AKS) での Basic Load Balancer のアップグレード」を参照してください。
  • オプション 2: Standard Load Balancer (ブルーグリーン移行) を使用して新しい AKS クラスターを作成し、既存のワークロードを移動します。

Basic から Standard Load Balancer にアップグレードした後にパブリック IP が見つからないのはなぜですか?

Load Balancer オブジェクトは、移行中にパブリック IP リソースへの参照を失いました。 これは、IP が Basic SKU Load Balancer に関連付けられ、リバインドされなかった場合に発生する可能性があります。

この問題を解決するには、次の手順を実行します。

  1. 新しい Standard パブリック IP が正しいリソース グループに存在することを確認します。

  2. 次の構成を使用して、サービス マニフェストで再関連付けを行います。

    annotations:
  service.beta.kubernetes.io/azure-load-balancer-ipv4: <your-ip>

パブリック IP を使用せずにプライベート クラスター上のロード バランサーを移行する場合、移行中にパブリック IP がまだ作成されるのはなぜですか?

outboundTypeがLoadBalancerされている場合、AKS は、Load Balancer SKU に関係なく、パブリック IP (PIP) を自動的にプロビジョニングします。

この問題を解決するには、次の手順を実行します。

  1. 完全プライベート クラスターの outboundType を userDefinedRouting に変更します。
  2. カスタム送信ルーティングが Azure Firewall/NVA 経由で構成されていることを確認します。

内部 Load Balancer のセットアップで移行が失敗する理由

現在の移行ツールでは、Basic から Standard へのインプレースでの内部仮想ネットワーク (VNet) ロード バランサーはサポートされていません。

この問題を解決するには、次の手順を実行します。

  1. Standard Load Balancer を使用して、同じ VNet 内にクラスターを再作成します。
  2. ワークロードをデプロイし、内部の名前解決を検証します。

私のノード プールは可用性セットを使用しています。 Load Balancer の移行後も問題が発生しますか?

Yes. ノード プールで可用性セットを使用している場合、2025 年 9 月 30 日以降の AKS でも非推奨となります。

この問題を解決するには、次の手順を実行します。

  1. 可用性セットと Basic Load Balancer の両方を使用するクラスターでは、両方の移行を一度に実行するために実行する必要がある個別の az aks update コマンドがあります (可用性セットから仮想マシン ノード プール、Basic Load Balancer から Standard Load Balancer)。 この移行を実行する手順については、 可用性セットの移行 ガイダンスを参照してください。
  2. アップグレード後、AZURE CLI または REST API を使用して CRUD 操作を実行するか、プールを管理する必要があります。 制限事項を確認します。

アップグレードする前に既定の Webhook を削除する必要がありますか?

No. クラスターに他の ValidatingAdmissionWebhooks または MutatingAdmissionWebhooks が存在しない場合は、コントロール プレーン内の既定の Webhook を移行中に保持しても問題ありません。

既定の Webhook には、次のものが含まれます。

  • aks-node-mutating-webhook
  • webhook-admission-controller
  • node-validating-webhook

移行コマンドを実行するために必要なアクセス権は何ですか?

移行コマンドを実行するには、次のものが必要です。

  • サブスクリプションまたはリソース グループの共同作成者ロールまたは所有者ロール。
  • Azure CLI のバージョンは、≥ 2.72.0 である必要があります。
  • AKS プレビュー拡張機能のバージョンは、≥ 0.5.170 である必要があります。

キー管理サービス (KMS) 暗号化が無効になっているかどうかを確認するにはどうすればよいですか?

az aks list コマンドを使用して、AKS クラスターで KMS 暗号化が有効になっているかどうかを確認できます。

az aks list --query "[].{Name:name, KmsEnabled:securityProfile.azureKeyVaultKms.enabled, KeyId:securityProfile.azureKeyVaultKms.keyId}"

  • 出力に "KmsEnabled": nullが表示されている場合は、そのクラスターに対して KMS 暗号化が有効になっていないことを意味し、無効にする手順はスキップできます。 例えば次が挙げられます。

      {

    "KeyId": null,

    "KmsEnabled": null,

    "Name": "myAKSCluster"

  },
...

  • KMS が有効になっていて、無効にする場合は、「 KMS 暗号化を無効にする」を参照してください。

次のステップ

AKS ネットワークの詳細については、「 Azure Kubernetes Service (AKS) のネットワークの概念」を参照してください。

  • Last updated on