Container Service for Kubernetes:ack-autoscaling-placeholder を使用した数秒でのコンテナスケーリング

前提条件

• ACK クラスターでノードの自動スケーリングが有効になっており、伸縮自在なノードプールが設定されていること。

• 伸縮自在なノードプールに [Node Label] でノードラベルが設定されていること。このガイドでは demo=yes を使用します。

仕組み

これら 3 つのステップはすべて、Kubernetes の優先度付きプリエンプションを通じて連携します：

1. プレースホルダーは低い PriorityClass (値 -1) で実行され、ノードリソースを予約します。

2. 実際のワークロードが高い PriorityClass (値 1000000) でデプロイされると、スケジューラーはプレースホルダーを排除し、そのワークロードを解放されたリソース上に即座に配置します。

3. Pending 状態になったプレースホルダーは CA をトリガーして新しいノードをプロビジョニングします。ノードの準備が完了すると、プレースホルダーは再スケジュールされ、バッファが復元されます。

ack-autoscaling-placeholder のデプロイ

1. コンテナサービス管理コンソールにログインします。左側のナビゲーションペインで、 [Marketplace] > [Marketplace] を選択します。

2. [App Catalog] タブで、 ack-autoscaling-placeholder を検索し、 [ack-autoscaling-placeholder] をクリックします。

3. [ack-autoscaling-placeholder] ページで、 [Deploy] をクリックします。

4. 作成パネルで [Parameters] タブをクリックし、 [Parameters] を次の YAML に置き換えて、 [OK] をクリックします。

   resources.requests は、ターゲットノードの合計キャパシティではなく、割り当て可能なリソースに一致するように設定します。ノードは、kubelet、オペレーティングシステム、および kube-proxy 用にキャパシティを予約します。 kubectl describe node <node-name> コマンドを実行し、 Allocatable で確認してください。

   nameOverride: ""
   fullnameOverride: ""
   
   priorityClassDefault:
     enabled: true
     name: default-priority-class   # プレースホルダー Pod 用の低優先度クラス。
     value: -1                      # CA の expendable-pod のカットオフ値より高く、実際のワークロードの優先度より低くする必要があります。
   
   deployments:
      - name: ack-place-holder
        replicaCount: 1
        containers:
          - name: placeholder
            image: registry-vpc.cn-shenzhen.aliyuncs.com/acs/pause:3.1
            pullPolicy: IfNotPresent
            resources:
              requests:
                cpu: 4             # これらのリクエストは、割り当て可能なノードリソースに一致するように設定します。
                memory: 8Gi        # (kubelet、OS、kube-proxy のオーバーヘッドを差し引いた) ノードの合計キャパシティではありません。
        imagePullSecrets: {}
        annotations: {}
        nodeSelector:              # 伸縮自在なノードプールのラベルと一致する必要があります。
          demo: "yes"
        tolerations: []
        affinity: {}
        labels: {}

5. [Applications] > [Helm] を選択し、 アプリケーションのステータスが [Deployed] であることを確認します。

ワークロード用の PriorityClass の作成

1. 次の内容で priorityClass.yaml を作成します。

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: high-priority
   value: 1000000       # プレースホルダーの PriorityClass の値 (-1) よりも高い必要があります。
   globalDefault: false
   description: "本番ワークロード用の高優先度クラス。"

2. PriorityClass を適用します。

   kubectl apply -f priorityClass.yaml

   期待される出力：

   priorityclass.scheduling.k8s.io/high-priority created

ワークロードのデプロイ

1. 次の内容で workload.yaml を作成します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: placeholder-test
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:              # 伸縮自在なノードプールのラベルと一致する必要があります。
           demo: "yes"
         priorityClassName: high-priority   # 前の手順で作成した PriorityClass を参照します。
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
           ports:
           - containerPort: 80
           resources:
             requests:
               cpu: 3             # プレースホルダーの CPU リクエスト (4) 以下にする必要があります
               memory: 5Gi        # これにより、実際のワークロードが予約されたスペース内に収まります。

2. Deployment を適用します。

   kubectl apply -f workload.yaml

   期待される出力：

   deployment.apps/placeholder-test created

結果の確認

1. デプロイ後、 ack-place-holder Pod のステータスは Running になります。

   

2. ワークロードがプレースホルダーをプリエンプトし、同じノードで開始します。プレースホルダーは Pending 状態に移行します。

   • ワークロード placeholder-test は、以前プレースホルダーが占有していたノードで Running になっています。

   • リソース不足のため、プレースホルダー Pod は Pending 状態になります。

3. CA は Pending 状態のプレースホルダーを検出し、新しいノードをプロビジョニングします。準備が完了すると、プレースホルダーは再スケジュールされ、バッファが復元されます。

   

次のステップ

複数ゾーンにまたがるオーバープロビジョニングについては、「複数ゾーンでの高速なエラスティックスケールアウトの同時実現」をご参照ください。