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

ビジネスで迅速なワークロードの起動が必要で、ノードリソースの制約を考慮する必要がない場合は、ack-autoscaling-placeholder コンポーネントを使用します。このコンポーネントは、クラスターの自動スケーリングのためのバッファーを提供します。ノードリソースが不足している場合、実際のワークロードがプレースホルダーワークロードによって予約されたリソースをプリエンプトして迅速に起動します。これをノードの自動スケーリングと組み合わせることで、クラスター内のノードレベルの拡張をトリガーできます。このトピックでは、ack-autoscaling-placeholder を使用して数秒でコンテナのスケーリングを実現する方法について説明します。

操作フロー

前提条件

ACK クラスターの Auto Scaling を有効にし、弾性ノードプールを設定済みであること。詳細については、「ノードの自動スケーリングの有効化」をご参照ください。
ノードラベル (Labels) 設定項目を使用して、弾性ノードプールのノードラベルを設定済みであること。これにより、ワークロードが特定のノードプールにスケジュールされ、結果の検証に役立ちます。詳細については、「ノードプールの作成と管理」をご参照ください。

このトピックでは、demo=yes ラベルを例として使用します。

ステップ 1：ack-autoscaling-placeholder コンポーネントのデプロイとプレースホルダーワークロードの作成

ack-autoscaling-placeholder は、クラスターの自動スケーリングのためのバッファーを提供し、クラスターノードのオーバープロビジョニングとプレウォーミングを可能にします。これにより、新しいノードが作成されてクラスターに参加するのを待つことなく、ワークロードを迅速にスケールアウトできます。

Container Service for Kubernetes (ACK) コンソールにログインします。左側のナビゲーションウィンドウで、ストア > Marketplace をクリックします。
アプリカタログ タブで ack-autoscaling-placeholder を検索し、[ack-autoscaling-placeholder] をクリックします。
[ack-autoscaling-placeholder] ページで、デプロイ をクリックします。

作成パネルで、プロンプトに従って設定を完了し、OK をクリックします。

パラメーター の内容を、パラメータ タブで次の YAML の例に置き換えます。

YAML の例を表示

nameOverride: ""
fullnameOverride: ""
##
priorityClassDefault:
  enabled: true
  name: default-priority-class   # デフォルトの優先度は低いです。
  value: -1

##
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            # リソースは 4C8G を占有します。
             memory: 8Gi
     imagePullSecrets: {}
     annotations: {}
     nodeSelector:        # ノードセレクター。弾性ノードプールのラベルと一致させます。
       demo: "yes"  
     tolerations: []
     affinity: {}
     labels: {}

作成後、アプリケーション > Helm ページに移動し、アプリケーションのステータスが デプロイ済み であることを確認します。

ステップ 2：実際のワークロード用の PriorityClass の作成

次の YAML の例を使用して、priorityClass.yaml という名前のファイルを作成します。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000       # 優先度を設定します。前のステップのプレースホルダー Pod のデフォルト優先度よりも高くする必要があります。
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

次のコマンドを実行して、実際のワークロード用の PriorityClass をデプロイします。
```
kubectl apply -f priorityClass.yaml
```
想定される出力：
```
priorityclass.scheduling.k8s.io/high-priority created
```

ステップ 3：実際のワークロードの作成

次の YAML の例を使用して、workload.yaml という名前のファイルを作成します。

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         # 実際のワークロードのリソースリクエスト。
            memory: 5Gi

次のコマンドを実行して、実際のワークロードをデプロイします。
```
kubectl apply -f workload.yaml
```
想定される出力：
```
deployment.apps/placeholder-test created
```

結果の確認

プレースホルダーワークロード ack-place-holder が作成されると、その Pod のステータスは Running になります。
実際のワークロードがデプロイされると、優先度の高い PriorityClass が設定されているため、プレースホルダーワークロードからリソースをプリエンプトして迅速に起動します。プレースホルダーワークロードの Pod は排除され、ノードリソースの不足により Pending 状態のままになります。
- 実際のワークロード placeholder-test は、プレースホルダーワークロードが存在する同じノードに迅速にデプロイされます。
- プレースホルダーワークロードは排除され、Pending 状態になります。
ノードプールでは自動スケーリングが有効になっているため、ノードリソースが不足するとノードのスケールアウトがトリガーされます。プレースホルダーワークロードは新しくスケールアウトされたノードにスケジュールされ、そのステータスは Running になります。

参考文献

高可用性シナリオでのマルチゾーンでの弾性スケールアウトについては、「複数ゾーンでの高速な弾性スケールアウトの同時実現」をご参照ください。