スケールアップ/スケールダウンについて

クラスター自動スケーリング機能は、クラスターを定期的にスキャンし、ユーザーが構成したワークロード・リソース要求やカスタム設定 (スキャン間隔など) に応じて、管理対象のワーカー・プール内のワーカー・ノードの数を調整します。 クラスター自動スケーリング機能は、毎分、以下の状況が発生していないか検査します。

• スケールアップすべき保留ポッド: ワーカー・ノードにポッドをスケジュールできるだけの十分なコンピュート・リソースが存在しない場合、そのポッドは保留ポッドと見なされます。 クラスター自動スケーリング機能は保留ポッドを検出すると、ワークロード・リソース要求を満たすために、ゾーン間で均等にワーカー・ノード数を増やします。
• スケールダウンすべき低使用率のワーカー・ノード: デフォルトでは、ワーカー・ノードが、要求された合計コンピュート・リソースの 50% 未満の状態で 10 分以上実行されていて、ワークロードを他のワーカー・ノードにスケジュール変更できる場合、このワーカー・ノードを、低使用率のワーカー・ノードと見なします。 クラスター自動スケーリング機能は、低使用率のワーカー・ノードを検出すると、必要なコンピュート・リソースだけを使用するように、ワーカー・ノードを 1 つずつ減らしていきます。 必要に応じて、デフォルトのスケールダウン使用率しきい値 (50% が 10 分間) をカスタマイズできます。

スキャンとスケールアップ/スケールダウンは一定の間隔で継続して行われ、ワーカー・ノード数によっては、完了までに長い時間がかかることがあります (30 分など)。

クラスタオートスケーラは、実際のワーカーノードの使用量ではなく、デプロイメント用に定義した リソース要求を考慮してワーカーノードの数を調整します。 ポッドとデプロイメントから適切な量のリソースが要求されない場合は、ユーザーがそれらの構成ファイルを調整する必要があります。 クラスター自動スケーリング機能でそれらを自動的に調整することはできません。 また、ワーカーノードは、基本的なクラスタ機能、デフォルトおよびカスタムの アドオン、 リソースのリザーブの ために、いくつかの計算リソースを使用することに留意してください。

スケールアップ/スケールダウンとはどのようなものですか?

一般的に、クラスター自動スケーリング機能は、クラスターのワークロードを実行するために必要なワーカー・ノード数を計算します。 クラスターのスケールアップ/スケールダウンは、以下のようなさまざまな要因によって決定されます。

• ユーザーが設定した 1 ゾーンあたりの最小および最大ワーカー・ノード・サイズ。
• 保留中のポッドリソースリクエストと、アンチアフィニティ、特定のフレーバーにのみポッドを配置するラベル、 ポッド中断バジェットなど、ワークロードに関連付ける特定のメタデータ。
• クラスタオートスケーラが管理するワーカープールで、マルチゾーンクラスタのゾーンにまたがる可能性があります。

詳細については、 Kubernetes Cluster Autoscaler FAQの「 スケールアップはどのように機能しますか 」および「 スケールダウンはどのように機能しますか 」を参照してください。

スケールアップとスケールダウンの仕組みを変更できますか?

設定をカスタマイズしたり、スケールアップ/スケールダウンの仕組みに影響を及ぼす他の Kubernetes リソースを使用したりできます。

スケールアップ

クラスター自動スケーリング機能の構成マップ値をカスタマイズする(scanInterval、expander、 skipNodes、maxNodeProvisionTimeなど)。 ワーカー・プールのリソースが不足する前にワーカー・ノードをスケールアップできるように、 ワーカー・ノードのオーバープロビジョンの方法を検討します。 また、Kubernetes のポッド中断の割り当て量とポッド優先度のカットオフを設定して、スケールアップの仕組みに影響を与えることができます。

スケールダウン

クラスター自動スケーリング機能の構成マップ値をカスタマイズする(scaleDownUnneededTime、scaleDownDelayAfterAdd、 scaleDownDelayAfterDelete、scaleDownUtilizationThresholdなど)。

ゾーンあたりの最小サイズを増やすことで、クラスターをそのサイズにスケールアップできますか?

いいえ。minSize を設定しても、自動的にスケールアップはトリガーされません。 minSize はしきい値で、クラスタ・オートスケーラがゾーンあたりのワーカーノード数が一定数を下回らないようにする。 クラスターで、ゾーンあたりの数がまだこれに達していない場合は、より多くのリソースを必要とするワークロード・リソース要求が発生するまで、クラスター自動スケーリング機能によってスケールアップされることはありません。 例えば、3 つのゾーンあたり 1 つのワーカー・ノードが含まれた 1 つのワーカー・プールがある場合に (合計 3 つのワーカー・ノード)、minSize をゾーンあたり 4 に設定した場合は、クラスター自動スケーリング機能によって、ゾーンあたりの追加の 3 つのワーカー・ノード (合計 12 個のワーカー・ノード) が即時にプロビジョンされることはありません。 代わりに、リソース要求によってスケールアップがトリガーされます。 15 個のワーカー・ノードのリソースを要求するワークロードを作成した場合、クラスター自動スケーリング機能はこの要求を満たすようにワーカー・プールをスケールアップします。 今、 minSize は、その量を要求するワークロードを削除しても、クラスタ・オートスケーラがゾーンあたり4ワーカーノード未満にスケールダウンしないことを意味する。

この動作は、クラスター自動スケーリング機能によって管理されないワーカー・プールとどのように異なりますか?

ワーカー・プールを作成するときには、1 ゾーンあたりのワーカー・ノード数を指定します。 ワーカー・プールのワーカー・ノード数は、ユーザーがワーカー・プールのサイズを変更するか、または 再バランス化するまで変わりません。 ワーカー・プールがワーカー・ノードを自動的に追加/削除することはありません。 スケジュールできる数より多くのポッドがある場合は、ユーザーがワーカー・プールのサイズを変更するまで、余分なポッドは保留状態のままです。 ワーカー・プールに対してクラスター自動スケーリング機能を有効にすると、ポッドの仕様の設定とリソース要求に応じてワーカー・ノード数が増減されます。 手動でワーカー・プールをサイズ変更したり再バランス化したりする必要はありません。

スケーラブル・デプロイメントの実践の遵守

ワーカー・ノード戦略とワークロード・デプロイメント戦略に従うことによって、クラスター自動スケーリング機能を最大限に活用します。 詳細については、 Kubernetes Cluster Autoscaler FAQを参照してください。

いくつかのテスト・ワークロードを使用してクラスター自動スケーリング機能を試す ことで、 スケールアップとスケールダウンの仕組み、構成すること、および ワーカー・ノードのオーバープロビジョン や アプリの制限 など、必要なその他の側面を把握できます。 その後、テスト環境をクリーンアップして、クラスター自動スケーリング機能のフレッシュ・インストールでこれらのカスタム値や追加設定を組み込む計画を立てます。

自動スケーリングされたワーカー・プールの再バランスまたはサイズ変更

ワーカー・プールを再バランスまたはサイズ変更する前に、自動スケーリング機能の構成マップからワーカー・プールを削除して、自動スケーリングを無効にする必要があります。

1. iks-ca-configmap を編集し、サイズ変更またはリバランスしたいワーカープールを workerPoolsConfig.json セクションから削除して無効にする。

   oc edit cm -n kube-system iks-ca-configmap
   

   出力例

   apiVersion: v1
   data:
     workerPoolsConfig.json: |
       [
        {"name": "","minSize": 1,"maxSize": 2,"enabled":false}
       ]
   kind: ConfigMap
   

2. iks-ca-configmap を保存します。

3. ワーカー・プールのサイズ変更またはリバランスを実行します。

4. オプション VPC ワーカー・ノードを更新します。

5. iks-ca-configmap にワーカー・プールを追加します。

   oc edit cm -n kube-system iks-ca-configmap
   

   例

   apiVersion: v1
   data:
     workerPoolsConfig.json: |
       [
        {"name": "<worker_pool>","minSize": 1,"maxSize": 2,"enabled":false}
       ]
   kind: ConfigMap
   

自動スケーリングのためのクラシック・クラスター、または VPC Gen 2 クラスターの準備

IBM Cloud のクラスター自動スケーリング機能アドオンをインストールする前に、自動スケーリングを可能にするためのクラスターの準備を行うことができます。

クラスター自動スケーリング機能アドオンは、ベアメタル・ワーカー・ノードではサポートされません。

1. 始める前に、必要な CLI とプラグインをインストールします。

   • IBM Cloud CLI (ibmcloud)
   • IBM Cloud Kubernetes Service プラグイン (ibmcloud oc)
   • IBM Cloud Container Registry プラグイン (ibmcloud cr)
   • Kubernetes (kubectl)

2. 標準クラスターを作成します。

3. Red Hat OpenShift クラスターにアクセスします。

4. IBM Cloud の ID/アクセス管理の資格情報がクラスターに保管されていることを確認します。 クラスター自動スケーリング機能はこのシークレットを使用して資格情報を認証します。 シークレットが欠落している場合は、資格情報をリセットすることでシークレットを作成します。

   oc get secrets -n kube-system | grep storage-secret-store
   

5. default ワーカー・プール以外のワーカー・プールで自動スケーリングを行うことを計画します。default ワーカー・プールには、自動スケール・ダウンを防止する可能性のあるシステム・コンポーネントが含まれているためです。 ワーカープールのラベルを含めることで、オートスケーリングが有効になっているワーカープールにデプロイするワークロードの ノードアフィニティを設定できます。 例えば、app: nginx などのラベルを使用します。 次のオプションから選択します。

   • default ワーカー・プール以外の VPC または クラシック・ワーカー・プールを、オートスケールされたワーカー・プールで実行するワークロードで使用するラベルで作成します。
   • default ワーカープール以外の 既存のワーカープールにラベルを追加する。

6. 自動スケーリング機能に必要なラベルがワーカー・プールに付加されていることを確認します。 出力には、必須の ibm-cloud.kubernetes.io/worker-pool-id ラベルと、ノード・アフィニティー用に以前に作成したラベルが表示されます。 これらのラベルが表示されない場合は、ワーカー・プールを追加してから、 ノード・アフィニティ用のラベルを追加して ください。

   ibmcloud oc worker-pool get --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID> | grep Labels
   

   ラベル付きのワーカー・プールの出力例。

   Labels:             ibm-cloud.kubernetes.io/worker-pool-id=a1aa111111b22b22cc3c3cc444444d44-4d555e5
   

7. 自動スケーリングするワーカー・プールにテイントを設定して、自動スケーリングするワーカー・プールで実行したいワークロード以外を、このワーカー・プールが受け入れないようにします。 テインツとトレランスについては、 コミュニティ Kubernetes のドキュメントを参照してください。 例として、use=autoscale:NoExecute のテイントを設定することが考えられます。 この例では、 NoExecute テイントは、このテイントに対応するトレレーションを持たないポッドを退去させます。

8. クラスター自動スケーリング機能アドオンをインストールします。

アドオンをインストールした後、Configmap の値を クラスターで自動スケーリングを有効にするに更新します。