次の方法で共有

Azure Kubernetes Service (AKS) でのアプリケーションのスケーリング オプション

  • [アーティクル]

Azure Kubernetes Service (AKS) でアプリケーションを実行する場合、コンピューティング リソースの量の増減が必要になることがあります。 所有するアプリケーション インスタンスの数が変わると、基になる Kubernetes ノードの数も変更する必要が生じます。 また、他のアプリケーション インスタンスを多数プロビジョニングすることが必要になる場合もあります。

この記事では、ポッドまたはノードの手動スケーリング、ポッドの水平オート スケーラの使用、クラスター オート スケーラーの使用、Azure Container Instances (ACI) との統合など、AKS アプリケーションでのスケーリングの主要な概念について説明します。

ポッドまたはノードを手動でスケーリングする

レプリカ、つまり、ポッドとノードを手動でスケーリングし、使用可能なリソースと状態の変化に対するアプリケーションの対応をテストできます。 手動によるリソースのスケーリングでは、ノード数などの固定費を維持するために、使用する一定量のリソースを定義することができます。 手動でスケーリングするには、レプリカまたはノードの数を定義します。 その後、そのレプリカまたはノードの数に基づき、Kubernetes API によって、さらにポッドを作成するかノードをドレインするスケジュールが設定されます。

ノードをスケールダウンすると、Kubernetes API によって、クラスターで使用されるコンピューティングの種類に関連付けられている Azure コンピューティング API が呼び出されます。 たとえば、Virtual Machine Scale Sets 上に構築されたクラスターの場合は、Virtual Machine Scale Sets API によって、削除するノードが決定されます。 スケールダウン時に削除対象のノードがどのように選択されるかの詳細については、「Virtual Machine Scale Sets の FAQ」を参照してください。

ノードの手動スケーリングを始めるには、AKS クラスターでのノードの手動スケーリングに関する記事をご覧ください。 ポッドの数の手動スケーリングについては、kubectl scale コマンドに関するページをご覧ください。

ポッドの水平オートスケーラー

Kubernetes は、ポッドの水平オートスケーラー (HPA) を使用して、リソース需要を監視し、ポッドの数を自動的にスケーリングします。 既定では、HPA は、必要なレプリカ数の変更についてメトリック API を 15 秒ごとに確認します。メトリック API は、Kubelet からデータを 60 秒ごとに取得します。 つまり、HPA は 60 秒ごとに更新されます。 変更が必要な場合、それに応じてレプリカの数が増減されます。 HPA は、Kubernetes 1.8 以降用のメトリック サーバーをデプロイした AKS クラスターで動作します。

Kubernetes のポッドの水平オートスケーリング

所定のデプロイ用に HPA を構成する場合、実行できるレプリカの最小値と最大数を定義します。 また、CPU 使用率など、監視するメトリックで、スケーリングの決定の基になるメトリックも定義します。

AKS でポッドの水平オートスケーラーを開始するには、「ポッドを自動スケールする」を参照してください。

スケーリング イベントのクールダウン

HPA は実質的に 60 秒ごとに更新されるため、前のスケーリング イベントが正しく完了していないうちに、別のチェックが行われる可能性があります。 この動作のため、前のスケーリング イベントでアプリケーションのワークロードとリソースの需要を受け取ってそれに応じて調整できるようになる前に、HPA によってレプリカの数が変更される可能性があります。

競合イベントを最小限に抑えるために、遅延値が設定されます。 この値は、HPA がスケーリング イベント後に別のスケーリング イベントをトリガーできるまで待機する必要のある時間を定義します。 この動作により、新しいレプリカ数が有効になり、メトリックの API で配分されたワークロードを反映できるようになります。 Kubernetes 1.12 時点でスケールアップ イベントの遅延はありませんが、スケールダウン イベントの遅延は既定で 5 分です。

クラスター オートスケーラー

ポッドの需要の変化に対応するために、Kubernetes クラスター オートスケーラーは、ノード プール内で要求されるコンピューティング リソースに基づいてノードの数を調整します。 既定では、クラスター オートスケーラーは、必要なノード数の変更についてメトリック API サーバーを 10 秒ごとに確認します。 クラスター オートスケーラーで変更が必要だと判断されると、それに応じて AKS クラスター内のノードの数が増減されます。 クラスターオートスケーラーは、Kubernetes 1.10.x 以降を実行する Kubernetes RBAC 対応 AKS クラスターで動作します。

Kubernetes クラスター オートスケーラー

クラスター オートスケーラーは通常、ポッドの水平オートスケーラーと一緒に使用されます。 組み合わせると、水平ポッド オートスケーラーでは、アプリケーションの需要に基づいてポッドの数が増減し、クラスター オートスケーラーによって、追加のポッドを実行するためにノードの数が調整されます。

AKS でクラスター オートスケーラーを開始するには、「Azure Kubernetes Service のクラスター オートスケーラー (AKS) - プレビュー」を参照してください。

スケールアウト イベント

ノードに、要求されたポッドを実行するために十分なコンピューティング リソースがない場合、そのポッドではスケジューリング プロセスを進めることができません。 ノード プール内で使用可能なコンピューティング リソースが増えない限り、ポッドは起動できません。

ノード プールのリソース制約のためにスケジュール設定できないポッドが、クラスター オートスケーラーによって検出されると、追加のコンピューティング リソースを提供するため、ノード プール内のノードの数が増やされます。 ノードが正常にデプロイされ、ノード プール内で使用できるようになると、それらで実行するようにポッドがスケジュールされます。

アプリケーションの速やかなスケーリングが必要な場合、クラスター オートスケーラーによってデプロイされた追加ノードがスケジュールされたポッドを受け入れられるようになるまで、一部のポッドがスケジュール待ち状態のままになることがあります。 高いバースト需要のあるアプリケーションの場合、仮想ノードと Azure Container Instances でスケーリングできます。

スケールイン イベント

クラスター オートスケーラーでは、最近新しいスケジュール要求を受け取っていないノードのポッド スケジューリング状態も監視されます。 このシナリオでは、ノード プールに必要以上のコンピューティング リソースがあり、ノードの数を削減できることが示されます。 既定で 10 分間、不要であるかどうかのしきい値を超えたノードは、削除対象としてスケジュールされます。 このような状況が発生した場合、ポッドは、ノード プール内の他のノードで実行するようにスケジュール設定され、クラスター オートスケーラーは、ノードの数を減らします。

クラスター オートスケーラーがノードの数を減らしたときに、ポッドは別のノード上にスケジュール設定されるので、アプリケーションに何からの中断が発生することがあります。 中断を最小限に抑えるには、単一のポッド インスタンスを使用するアプリケーションを使用しないでください。

Kubernetes Event-driven Autoscaling (KEDA)

Kubernetes Event-driven Autoscaling (KEDA) は、ワークロードのイベントドリブン自動スケーリング用のオープンソース コンポーネントです。 受け取ったイベントの数に基づいてワークロードを動的にスケーリングします。 KEDA は、ScaledObject と呼ばれるカスタム リソース定義 (CRD) を使用して、特定のトラフィックに応じてどのようにアプリケーションをスケーリングするかを記述するよう Kubernetes を拡張します。

KEDA スケーリングは、ワークロードでトラフィックのバーストが発生したり、大量のデータを処理したりするシナリオで役立ちます。 KEDA はイベントドリブンであり、イベントの数に基づいてスケーリングされるのに対し、HPA はリソース使用率 (CPU やメモリなど) に基づいたメトリクスドリブンであるため、ポッドの水平オートスケーラーとは異なります。

AKS で KEDA アドオンの使用を開始するには、KEDA の概要に関する記事を参照してください。

Azure Container Instances (ACI) へのバースト

AKS クラスターを迅速にスケーリングするために、Azure Container Instances (ACI) と統合できます。 Kubernetes には、レプリカおよびノード数をスケーリングするコンポーネントが組み込まれています。 ただし、アプリケーションが迅速なスケーリングを必要としている場合、ポッドの水平オートスケーラーは、ノード プール内の既存のコンピューティング リソースが提供できる数より多くのポッドをスケジュール設定できます。 構成されている場合、このシナリオでは、クラスター オートスケーラーがトリガーされて、ノード プールにさらにノードがデプロイされますが、それらのノードが正常にプロビジョニングされ、Kubernetes スケジューラがそれらの上でポッドを実行できるようになるまで、数分かかることがあります。

ACI への Kubernetes バースト スケーリング

ACI を使うと、インフラストラクチャのオーバーヘッドを増やすことなく、コンテナー インスタンスを迅速にデプロイできます。 AKS で接続する場合、ACI は、AKS クラスターのセキュリティ保護された論理拡張機能になります。 仮想ノード コンポーネントは仮想 Kubelet に基づいており、仮想 Kubernetes ノードとして ACI を提示する AKS クラスターにインストールされます。 Kubernetes は続いて、直接 AKS クラスター内にある VM ノード上のポッドとしてではなく、仮想ノードを通じた ACI インスタンスとして実行するポッドをスケジュール設定できます。

アプリケーションは、仮想ノードを使用するために変更は不要です。 クラスター オートスケーラーが AKS クラスター内に新しいノードをデプロイするときに、デプロイは AKS と ACI にわたって遅延なくスケーリングできます。

仮想ノードは、AKS クラスターと同じ仮想ネットワーク内の別のサブネットにデプロイされます。 この仮想ネットワーク構成は、ACI と AKS 間のトラフィックをセキュリティで保護します。 AKS クラスターと同様に、ACI インスタンスは、他のユーザーから分離されたセキュリティ保護された論理的なコンピューティング リソースです。

次のステップ

アプリケーションのスケーリングを始めるには、次のリソースを参照してください。

Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。