Container Service for Kubernetes:複数ゾーンにわたる迅速なスケーリングの実装

この問題を解決するために、ACK は ack-autoscaling-placeholder コンポーネントを導入しました。このコンポーネントは、リソースの冗長性を利用することでこの問題を修正します。このコンポーネントは、複数ゾーンのelasticscaling を同時ノードプールの指示スケーリングに変換します。詳細については、「ack-autoscaling-placeholder を使用して Pod を数秒でスケーリングする」をご参照ください。原則は次のとおりです。

1. 各ゾーンにノードプールを作成し、ノードプールにラベルを追加します。ラベルは、ノードプールがデプロイされているゾーンを指定します。

2. ゾーンラベルに基づいて Pod をスケジュールするように nodeSelector を構成します。このように、ack-autoscaling-placehodler は各ゾーンにプレースホルダー Pod をスケジュールできます。デフォルトのプレースホルダー Pod には、アプリケーション Pod よりも重みが小さい PriorityClass があります。

3. これにより、保留中のアプリケーション Pod がプレースホルダー Pod を置き換えることができます。保留中のアプリケーション Pod が nodeSelector を使用してスケジュールされたプレースホルダー Pod を置き換えると、プレースホルダー Pod は保留中になります。ノード自動スケーリングコンポーネントで使用されるノードスケジューリングポリシーは、antiAffinity から nodeSelector に変更されます。このようにして、スケールアウトセクションからのノードリクエストを処理できます。

手順 1：各ゾーンのノードプールを作成し、カスタムノードラベルを構成する

1. ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスタ] をクリックします。

2. [クラスタ] ページで、管理するクラスタを見つけ、その名前をクリックします。左側のナビゲーションウィンドウで、[ノード] > [ノードプール] を選択します。

3. [ノードプールの作成] をクリックし、プロンプトに従ってノードプールの構成を完了します。

   この例では、ゾーン I で自動スケーリングが有効になっている auto-zone-I という名前のノードプールを作成する方法について説明します。次のセクションでは、主要なパラメータのみについて説明します。詳細については、「ノードプールの作成と管理」をご参照ください。

   パラメータ	説明
   ノードプール名	auto-zone-I
   スケーリングモード	[自動] を選択して、自動スケーリングを有効にします。
   vSwitch	ゾーン I の vSwitch を選択します。
   ノードラベル	ノードラベルの キー を available_zone に、値 を i に設定します。

   ノードプールリストで、auto-zone-I ノードプールのステータスが [アクティブ] になると、ノードプールが正常に作成されます。

4. 自動スケーリングが必要な各ゾーンに対して、上記の手順を繰り返して、自動スケーリングが有効になっているノードプールを作成します。

   

手順 2：プレースホルダーとプレースホルダーデプロイメントをデプロイする

1. ACK コンソールの左側のナビゲーションウィンドウで、[マーケットプレイス] > [マーケットプレイス] を選択します。

2. ack-autoscaling-placeholder を見つけてクリックします。 ack-autoscaling-placeholder ページで、[デプロイ] をクリックします。

3. [クラスタ] ドロップダウンリストからクラスタを、[名前空間] ドロップダウンリストから名前空間を選択し、[次へ] をクリックします。 [チャートバージョン] ドロップダウンリストからチャートバージョンを選択し、[パラメータ] を構成して、[OK] をクリックします。

   作成が成功したら、左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択すると、アプリケーションが [デプロイ済み] 状態になっていることがわかります。

4. 詳細ページの左側のナビゲーションウィンドウで、[アプリケーション] > [Helm] を選択します。

5. [Helm] ページで、ack-autoscaling-placeholder-default の 更新[アクション] 列の をクリックします。

6. [リリースの更新] パネルで、次の例に基づいて YAML ファイルを更新し、[OK] をクリックします。各ゾーンにプレースホルダーをデプロイし、各ゾーンにプレースホルダーデプロイメントを定義します。

   この例では、ゾーン I、K、および H にプレースホルダーデプロイメントを作成する方法を示しています。

   deployments:
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m     # プレースホルダーデプロイメントの CPU リクエスト。
           memory: 6      # プレースホルダーデプロイメントのメモリリクエスト。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-I             # プレースホルダーデプロイメントの名前。
     nodeSelector: {"avaliable_zone":i}   # ゾーンラベル。このラベルは、手順 1 でノードプールを作成したときに指定したラベルと同じである必要があります。
     replicaCount: 10                     # 各スケールアウトアクティビティで作成される Pod の数。
     tolerations: []
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m    # プレースホルダーデプロイメントの CPU リクエスト。
           memory: 6     # プレースホルダーデプロイメントのメモリリクエスト。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-K            # プレースホルダーデプロイメントの名前。
     nodeSelector: {"avaliable_zone":k}  # ゾーンラベル。このラベルは、手順 1 でノードプールを作成したときに指定したラベルと同じである必要があります。
     replicaCount: 10                    # 各スケールアウトアクティビティで作成される Pod の数。
     tolerations: []
   - affinity: {}
     annotations: {}
     containers:
     - image: registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.1
       imagePullPolicy: IfNotPresent
       name: placeholder
       resources:
         requests:
           cpu: 3500m   # プレースホルダーデプロイメントの CPU リクエスト。
           memory: 6    # プレースホルダーデプロイメントのメモリリクエスト。
     imagePullSecrets: {}
     labels: {}
     name: ack-place-holder-H           # プレースホルダーデプロイメントの名前。
     nodeSelector: {"avaliable_zone":h} # ゾーンラベル。このラベルは、手順 1 でノードプールを作成したときに指定したラベルと同じである必要があります。
     replicaCount: 10                   # 各スケールアウトアクティビティで作成される Pod の数。
     tolerations: []
   fullnameOverride: ""
   nameOverride: ""
   podSecurityContext: {}
   priorityClassDefault:
     enabled: true
     name: default-priority-class
     value: -1

   更新が成功すると、各ゾーンにプレースホルダーデプロイメントが作成されます。

手順 3：ワークロードの PriorityClass を作成する

1. priorityClass.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: high-priority
   value: 1000000              # 優先度の値を指定します。この値は、手順 2 で作成したワークロードのデフォルトの優先度の値よりも大きい必要があります。
   globalDefault: false
   description: "この優先度クラスは、XYZ サービス Pod のみに使用する必要があります。"

   Pod に個別の PriorityClass を構成する必要がない場合は、グローバル PriorityClass をデフォルト構成として構成できます。構成が有効になると、PriorityClass が指定されていない Pod は自動的にこの優先度の値を採用し、プリエンプション機能が自動的に有効になります。

   apiVersion: scheduling.k8s.io/v1
   kind: PriorityClass
   metadata:
     name: global-high-priority
   value: 1                              # 優先度の値を指定します。この値は、手順 2 で作成したワークロードのデフォルトの優先度の値よりも大きい必要があります。
   globalDefault: true
   description: "この優先度クラスは、XYZ サービス Pod のみに使用する必要があります。"

2. ワークロードの PriorityClass を作成します。

   kubectl apply -f priorityClass.yaml

   予期される出力：

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

手順 4：ワークロードを作成する

この例では、ゾーン I を使用します。

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:                        # ノードの選択に使用するルールを指定します。
           avaliable_zone: "i"
         priorityClassName: high-priority     # 手順 3 で構成した PriorityClass の名前。グローバル構成が有効になっている場合は、これはオプションです。
         containers:
         - name: nginx
           image: nginx:1.7.9
           ports:
           - containerPort: 80
           resources:
             requests:
               cpu: 3                         # ワークロードのリソースリクエストを指定します。
               memory: 5

2. ワークロードをデプロイします。

   kubectl apply -f workload.yaml

   予期される出力：

   deployment.apps/placeholder-test created

   デプロイ後、[ワークロード] > [Pod] ページで、ワークロードの PriorityClass がプレースホルダー Pod の PriorityClass よりも高く、プレースホルダー Pod がスケールアウトされたノードで実行されていることがわかります。プレースホルダー Pod は、ノード自動スケーリングコンポーネントの同時スケーリングをトリガーして、次のワークロードスケーリングに備えます。

   [ノード] > [ノード] を選択します。 [ノード] ページで、ワークロード Pod がプレースホルダー Pod をホストしているノードで実行されていることがわかります。