次の方法で共有

大規模な AKS クラスターを実行またはスケーリングするときの一般的な問題に関する FAQ

  • [アーティクル]

この記事では、Microsoft Azure Kubernetes Service (AKS) で大規模なクラスターを実行またはスケーリングするときに発生する可能性がある一般的な問題に関してよく寄せられる質問に回答します。 大規模なクラスターは、500 ノードスケールを超えるクラスターです。

作成時、スケールアップ、またはアップグレード中に "クォータ超過" エラーが発生する

この問題を解決するには、作成、スケーリング、またはアップグレードしようとしているサブスクリプションにサポート要求を作成し、対応するリソースの種類のクォータを要求します。 詳細については、「 リージョンのコンピューティング クォータ」を参照してください。

高度なネットワークを使用する AKS クラスターをデプロイすると"insufficientSubnetSize" エラーが発生する

このエラーは、クラスターで使用されているサブネットに、リソースの割り当てを成功させるために CIDR 内で使用可能な IP がなくなったことを示します。 この問題は、アップグレード、スケールアウト、またはノード プールの作成時に発生する可能性があります。 この問題は、サブネット内の空き IP の数が次の式の結果より少ないために発生します。

要求されたノードの数 * ノード プール --max-pod の値

前提条件

ソリューション

既存のサブネットの CIDR 範囲を更新できないため、この問題を解決するには、新しいサブネットを作成するためのアクセス許可が必要です。 次の手順を実行します。

  1. 操作の目標に十分な CIDR 範囲を持つ新しいサブネットを再構築します。

  2. 新しい重複しない範囲を持つ新しいサブネットをCreateします。

  3. 新しいサブネット上の新しいノード プールをCreateします。

  4. 置き換えられる古いサブネットに存在する古いノード プールからポッドをドレインします。

  5. 古いサブネットと古いノード プールを削除します。

SNAT ポートの枯渇のために、散発的なエグレス接続エラーが発生しています

比較的大規模 (500 ノードを超えるノード) で実行されるクラスターの場合は、スケーラビリティを高める AKS マネージド ネットワーク アドレス変換 (NAT) ゲートウェイ を使用することをお勧めします。 Azure NAT Gateway では、IP アドレスあたり最大 64,512 の送信 UDP および TCP トラフィック フロー、および最大 16 個の IP アドレスが許可されます。

マネージド NAT を使用していない場合は、「 ソース ネットワーク アドレス変換 (SNAT) の枯渇と接続タイムアウトのトラブルシューティング」 を参照して、SNAT ポートの枯渇の問題を理解して解決します。

Azure portalを使用して最大 5,000 ノードにスケールアップできない

Azure CLI を使用して、次の手順に従って最大 5,000 ノードにスケールアップします。

  1. 次のコマンドを実行して、クラスター内のノード プールの最小数をCreateします (ノード プールノードの最大数は 1,000 であるため)。

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. ノード プールを一度に 1 つずつスケールアップします。 理想的には、連続するスケールアップの間に 5 分間の睡眠時間を 1,000 に設定します。 次のコマンドを実行します。

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

アップグレードが実行されているが、遅い

既定の構成では、AKS はアップグレード中に次のアクションを実行して急増します。

  • 1 つの新しいノードを作成します。
  • ノード プールを目的のノード数を超えて 1 ノードずつスケーリングします。

最大サージ設定の場合、1 ノードの既定値は、AKS が既存のアプリケーションをドレインし、以前のバージョンのノードを置き換える前に 1 つの新しいノードを作成することを意味します。 この追加ノードにより、AKS はワークロードの中断を最小限に抑えることができます。

多数のノードを持つクラスターをアップグレードする場合、既定値の を使用する場合、クラスター全体の max-surgeアップグレードに数時間かかることがあります。 ノード プールごとのプロパティを max-surge カスタマイズして、アップグレード速度とアップグレードの中断のトレードオフを有効にすることができます。 最大サージ値を増やすことで、アップグレード プロセスをより早く完了できます。 ただし、最大サージの値が大きいと、アップグレード プロセス中に中断が発生する可能性もあります。

次のコマンドを実行して、既存のノード プールの最大サージを増やすかカスタマイズします。

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

アップグレードがクォータ (5,000 クラスター) の制限に達しています

この問題を解決するには、「 リージョン vCPU クォータを増やす」を参照してください。

750 を超えるノードでの内部サービスの作成が、タイムアウト エラーのために低速または失敗する

Standard Load Balancer (SLB) バックエンド プールの更新は、既知のパフォーマンスのボトルネックです。 私たちは、大規模なサービスとSLBの迅速な作成を可能にする新しい機能に取り組んでいます。 この問題に関するフィードバックをお寄せください。 IP ベースのバックエンド プールを使用したロード バランサーに対する Azure Kubernetes サポートに関するページを参照してください。

ソリューション

クラスターを 750 ノード未満にスケールダウンしてから、クラスターの内部ロード バランサーを作成することをお勧めします。 内部ロード バランサーを作成するには、次の LoadBalancer 例の手順に従って、サービスの種類と azure-load-balancer-internal 注釈を作成します。

手順 1: 内部ロード バランサーをCreateする

内部ロード バランサーを作成するには、次の例に示すように、internal-lb.yaml という名前のサービス マニフェストを作成し、サービスの種類と注釈をazure-load-balancer-internal含みますLoadBalancer。

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

手順 2: 内部ロード バランサーをデプロイする

コマンドを使用して内部ロード バランサーを kubectl apply デプロイし、次の例に示すように YAML マニフェストの名前を指定します。

kubectl apply -f internal-lb.yaml

クラスターが作成されたら、内部ロード バランサー (この手順に従って) をプロビジョニングし、内部負荷分散サービスを実行したままにすることもできます。 これにより、大規模にロード バランサーにサービスを追加できます。

大規模な SLB サービスの作成には、実行に数時間かかります

SLB バックエンド プールの更新は、既知のパフォーマンスのボトルネックです。 作成、更新、削除操作のパフォーマンスを大幅に向上させ、負荷分散されたサービスを大規模に実行できる新しい機能に取り組んでいます。 フィードバックをお寄せください。 IP ベースのバックエンド プールを使用したロード バランサーに対する Azure Kubernetes サポートに関するページを参照してください。

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。