UnitedDeploymentコントローラーを使用すると、複数のサブセットで同じタイプの複数のワークロードを柔軟かつ便利な方法で管理できます。 たとえば、複数のゾーンに同じデプロイメントをデプロイする場合は、各ゾーンのデプロイメントに個別のサブセットを作成できます。 次に、UnitedDeploymentコントローラーは、サブセットの構成に基づいて、複数のゾーンに展開を展開します。 これにより、きめ細かい方法でサブセットに基づいてリソースを更新およびデプロイできます。 展開ごとにYAMLファイルを作成する必要はありません。 UnitedDeploymentコントローラーをHorizontal Pod Autoscaler (HPA) と一緒に使用して、Elastic Compute Service (ECS) インスタンスとelasticコンテナインスタンスに配置されているアプリケーションをスケーリングできます。 ポッドは、指定されたリソースの優先度に基づいて降順でスケールアウトされます。 ポッドは、リソースの指定された優先度に基づいて昇順でスケールインされます。 これにより、リソースコストを削減できます。
UnitedDeploymentコントローラーの詳細については、Kruiseの公式ドキュメントUnitedDeploymentを参照してください。 このトピックでは、YAMLファイルを使用してUnitedDeploymentコントローラーを構成し、さまざまなシナリオの要件を満たす方法について説明します。
サポートされるワークロードの種類
UnitedDeploymentコントローラーは、StatefulSet、Advanced StatefulSet、CloneSet、およびDeploymentのワークロードタイプのみをサポートします。 詳細については、「OpenKruiseを使用したクラウドネイティブアプリケーションのデプロイ」をご参照ください。
前提条件
ack-kruiseコンポーネントがインストールされています。 詳細については、「コンポーネントの管理」をご参照ください。
弾性コンテナインスタンスを使用する場合、ACK仮想ノードコンポーネントがインストールされます。 詳細については、「コンポーネントの管理」をご参照ください。
kubectlクライアントがACKクラスターに接続されています。 詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。
シナリオ1: UnitedDeploymentコントローラーとHPA
クラスターに複数のタイプのリソースが含まれている場合、UnitedDeploymentのYAMLファイルでサブセットを設定して、1つのリソースタイプを選択できます。 maxReplicas
フィールドを追加して、ポッド数が上限に達した後にポッドをスケジュールする方法を指定することもできます。 HPAを使用してUnitedDeploymentの水平ポッド自動スケーリングを実装すると、ポッドは指定されたリソースの優先順位に基づいてスケーリングされます。 HPAを設定するときに、HPAのscaleTargetRef
フィールドをUnitedDeployment
に設定し、UnitedDeploymentの名前を設定します。
OpenKruise 1.5.0が必要です。 OpenKruiseのリリースノートの詳細については、「OpenKruise」をご参照ください。
この例では、クラスタに2つのノードプールが存在します。 ノードプールAはサブスクリプションECSインスタンスで構成され、ノードプールBはプリエンプティブルインスタンスで構成されます。 サブスクリプションECSインスタンス> プリエンプティブルインスタンス> エラスティックコンテナインスタンスの優先順位で、ポッドを異なるタイプのノードにスケジュールするようにシステムを設定できます。 1つのタイプのノードが在庫切れの場合、システムはより低い優先度のノードをポッドスケジューリングに使用します。
test.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。
test.yamlファイルは、UnitedDeploymentをオーケストレーションするために使用されます。 ファイル内の
template
パラメーターは、配置の設定を定義します。 ファイルはまた、3つのサブセットを定義する。サブセットaのポッドは、ノードプールAのサブスクリプションECSインスタンスにデプロイされます。サブセットbのポッドは、ノードプールBのプリエンプティブルインスタンスにデプロイされます。
subset-cは、エラスティックコンテナインスタンスの選択に使用される
nodeSelectorTerm
およびtolerations
パラメーターで設定されます。 この場合、サブセット-cのポッドはエラスティックコンテナインスタンスにデプロイされます。 サブセットc上のレプリカの数は3である。
apiVersion: apps.kruise.io/v1alpha1 kind: UnitedDeployment metadata: name: ud-nginx spec: replicas: 6 revisionHistoryLimit: 10 selector: matchLabels: app: ud-nginx template: deploymentTemplate: metadata: labels: app: ud-nginx spec: selector: matchLabels: app: ud-nginx template: metadata: labels: app: ud-nginx spec: containers: - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0 name: nginx topology: subsets: - name: subset-a nodeSelectorTerm: matchExpressions: - key: alibabacloud.com/nodepool-id operator: In values: - np92019eec42004d878fcdc990fcb9**** # Replace the value with the ID of Node Pool A. replicas: 1 - name: subset-b nodeSelectorTerm: matchExpressions: - key: alibabacloud.com/nodepool-id operator: In values: - np011de1f2de3d48bd8a92a015fc5c**** # Replace the value with the ID of Node Pool B. replicas: 1 - name: subset-c nodeSelectorTerm: matchExpressions: - key: type operator: In values: - virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists replicas: 3 updateStrategy: manualUpdate: partitions: subset-a: 0 subset-b: 0 subset-c: 0 type: Manual
次のコマンドを実行して、UnitedDeploymentをデプロイします。
kubectl apply -f test.yaml
期待される出力:
uniteddeployment.apps.kruise.io/ud-nginx created
次のコマンドを実行して、ポッドが作成されているかどうかを確認します。
kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ud-nginx-subset-a-7lbtd-5b5bd77549-5bw6l 1/1 Running 0 73s 192.XX.XX.126 cn-hangzhou.10.XX.XX.131 <none> <none> ud-nginx-subset-b-nvvfw-5c9bcd6766-lv6sp 1/1 Running 0 73s 192.XX.XX.239 cn-hangzhou.10.XX.XX.132 <none> <none> ud-nginx-subset-c-m78fd-7796b66fd8-7p52j 1/1 Running 0 73s 192.XX.XX.130 virtual-kubelet-cn-hangzhou-h <none> <none> ud-nginx-subset-c-m78fd-7796b66fd8-fd7f7 1/1 Running 0 73s 192.XX.XX.129 virtual-kubelet-cn-hangzhou-h <none> <none> ud-nginx-subset-c-m78fd-7796b66fd8-mn4qb 1/1 Running 0 73s 192.XX.XX.131 virtual-kubelet-cn-hangzhou-h <none> <none>
出力は、UnitedDeploymentの設定で定義されている異なるサブセットにポッドがデプロイされていることを示します。
シナリオ2: ゾーン全体にアプリケーションを展開する
アプリケーションの可用性を向上させるには、通常、複数のゾーンにコンピューティングまたはストレージリソースをデプロイする必要があります。 異なるゾーンのノードに異なるラベルを追加できます。 次に、UnitedDeploymentのYAMLファイルのサブセット設定でラベルセレクタを設定します。 このように、UnitedDeploymentは、異なるサブセットのポッドを、ラベルが一致する異なるゾーンにスケジュールします。
3つのノードが異なるゾーンに存在する。 次のコマンドを実行して、ノードが存在するゾーンを示すラベルを各ノードに追加します。
たとえば、
node=zone-a
ラベルがゾーンAのノードに追加され、node=Zone-b
ラベルがゾーンBのノードに追加され、node=zone-c
ラベルがゾーンCのノードに追加されます。kubectl label node cn-beijing.10.XX.XX.131 node=zone-a node/cn-beijing.10.80.20.131 labeled # Add the node=zone-a label to node 10.XX.XX.131. kubectl label node cn-beijing.10.XX.XX.132 node=zone-b node/cn-beijing.10.80.20.132 labeled # Add the node=zone-b label to node 10.XX.XX.132. kubectl label node cn-beijing.10.XX.XX.133 node=zone-c node/cn-beijing.10.80.20.133 labeled # Add the node=zone-c label to node 10.XX.XX.133.
test.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。
test.yamlファイルは、UnitedDeploymentをオーケストレーションするために使用されます。 ファイル内の
template
パラメーターは、StatefulSetの設定を定義します。 ファイルはまた、各ゾーンのサブセットを定義する。statefulSetTemplate
フィールドは、StatefulSetのテンプレートを定義します。 UnitedDeploymentは、テンプレートに基づいて各サブセットにStatefulSetを作成します。サブセット
セクションは、各ゾーンのサブセットを定義する。 subset-aのポッドは、ラベルがnode=zone-aのノードにデプロイされます。 サブセットbのポッドは、ラベルがnode=zone-bであるノードにデプロイされます。 サブセット-cのポッドは、ラベルがnode=zone-cのノードにデプロイされます。
apiVersion: apps.kruise.io/v1alpha1 kind: UnitedDeployment metadata: name: sample-ud spec: replicas: 6 revisionHistoryLimit: 10 selector: matchLabels: app: sample template: statefulSetTemplate: metadata: labels: app: sample spec: selector: matchLabels: app: sample template: metadata: labels: app: sample spec: containers: - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0 name: nginx topology: subsets: - name: subset-a nodeSelectorTerm: matchExpressions: - key: node operator: In values: - zone-a replicas: 1 - name: subset-b nodeSelectorTerm: matchExpressions: - key: node operator: In values: - zone-b replicas: 50% - name: subset-c nodeSelectorTerm: matchExpressions: - key: node operator: In values: - zone-c updateStrategy: manualUpdate: partitions: subset-a: 0 subset-b: 0 subset-c: 0 type: Manual
次のコマンドを実行して、UnitedDeploymentをデプロイします。
kubectl apply -f test.yaml
期待される出力:
uniteddeployment.apps.kruise.io/sample-ud created
次のコマンドを実行して、ポッドとStatefulSetsが作成されているかどうかを確認します。
kubectl get pod # Expected output: NAME READY STATUS RESTARTS AGE sample-ud-subset-a-cplwg-0 1/1 Running 0 6m5s sample-ud-subset-b-rj7kt-0 1/1 Running 0 6m4s sample-ud-subset-b-rj7kt-1 1/1 Running 0 5m49s sample-ud-subset-b-rj7kt-2 1/1 Running 0 5m43s sample-ud-subset-c-g6jvx-0 1/1 Running 0 6m5s sample-ud-subset-c-g6jvx-1 1/1 Running 0 5m51s kubectl get statefulset # Expected output: NAME READY AGE sample-ud-subset-a-cplwg 1/1 7m34s sample-ud-subset-b-rj7kt 3/3 7m34s sample-ud-subset-c-g6jvx 2/2 7m34s
出力は、ポッドとStatefulSetsが作成され、ゾーンA、ゾーンB、およびゾーンCのノードで実行されることを示します。
シナリオ3: UnitedDeploymentコントローラーを使用して、ECSインスタンスとelasticコンテナーインスタンス上のアプリケーションを同じ場所に配置する
ビジネスの急増に対処するには、クラスターノードのリソース供給とコストの管理を同時に行う必要があります。 この問題に対処するには、ポッドスケジューリングのECSインスタンスに優先順位を付け、ECSインスタンスの在庫切れ時に弾性コンテナインスタンスにアプリケーションを自動的にデプロイするようにACKを設定します。 ポッドがスケールインされると、ACKは最初にエラスティックコンテナインスタンスで実行されるポッドを削除します。
次の例では、レプリカのスケジュール方法を示すためにUnitedDeploymentが作成されています。 レプリカの数が4を超えない場合、レプリカはECSインスタンスにスケジュールされます。 レプリカの数が4〜10の場合、余分なポッドはエラスティックコンテナインスタンスにスケジュールされます。
test.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。
deploymentTemplate
フィールドは、Deploymentのテンプレートを定義します。 UnitedDeploymentは、テンプレートに基づいて各サブセットにDeploymentを作成します。サブセット
セクションは、2つのサブセットを定義する。 最初のサブセットのポッドはECSインスタンスにスケジュールされます。 2番目のサブセットのレプリカは、エラスティックコンテナインスタンスにスケジュールされます。 最初のサブセットは、最大4つのレプリカをサポートします。 UnitedDeploymentによってプロビジョニングされたレプリカの数が4を超えない場合、レプリカはECSインスタンスにスケジュールされます。 レプリカの数が4〜10の場合、余分なポッドはエラスティックコンテナインスタンスにスケジュールされます。
apiVersion: apps.kruise.io/v1alpha1 kind: UnitedDeployment metadata: name: ud-nginx spec: replicas: 6 selector: matchLabels: app: sample template: # statefulSetTemplate or advancedStatefulSetTemplate or cloneSetTemplate or deploymentTemplate deploymentTemplate: metadata: labels: app: sample spec: selector: matchLabels: app: sample template: metadata: labels: app: sample spec: containers: - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0 name: nginx resources: requests: cpu: "500m" topology: subsets: - name: ecs maxReplicas: 4 - name: eci maxReplicas: null --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: united-deployment-hpa spec: scaleTargetRef: apiVersion: apps.kruise.io/v1alpha1 kind: UnitedDeployment name: ud-nginx # Replace the value with the name of the UnitedDeployment. minReplicas: 4 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50
次のコマンドを実行して、UnitedDeploymentをデプロイします。
kubectl apply -f test.yaml
期待される出力:
horizontalpodautoscaler.autoscaling/united-deployment-hpa created
次のコマンドを実行して、ポッドのステータスを照会します。
kubectl get pod -o wide # Expected output: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ud-nginx-eci-dxfbz-864bdb77b-2d4t9 1/1 Running 0 3m9s 192.XX.XX.129 cn-hangzhou.192.XX.XX.120 <none> <none> ud-nginx-eci-dxfbz-864bdb77b-zppfh 1/1 Running 0 3m9s 192.XX.XX.11 cn-hangzhou.192.XX.XX.251 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-5mlgh 1/1 Running 0 3m9s 192.XX.XX.4 cn-hangzhou.192.XX.XX.251 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-6bdkz 1/1 Running 0 3m9s 192.XX.XX.145 cn-hangzhou.192.XX.XX.32 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-dnsfl 1/1 Running 0 3m9s 192.XX.XX.150 cn-hangzhou.192.XX.XX.20 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-mrzwc 1/1 Running 0 3m9s 192.XX.XX.128 cn-hangzhou.192.XX.XX.120 <none> <none>
出力は、UnitedDeploymentによって定義されたスケジューリングポリシーに基づいて、Deploymentのレプリカが動的にスケジュールされることを示します。 最初の4つのレプリカはECSインスタンスにスケジュールされます。 残りの2つのレプリカは、エラスティックコンテナインスタンスにスケジュールされます。
HPAをトリガーしてスケールインアクティビティを実行し、次のコマンドを実行してポッドのステータスを照会します。
kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ud-nginx-ecs-5lm7r-868c4ccd5d-5mlgh 1/1 Running 0 8m14s 192.168.8.4 cn-hangzhou.192.168.8.251 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-6bdkz 1/1 Running 0 8m14s 192.168.6.145 cn-hangzhou.192.168.6.32 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-dnsfl 1/1 Running 0 8m14s 192.168.6.150 cn-hangzhou.192.168.6.20 <none> <none> ud-nginx-ecs-5lm7r-868c4ccd5d-mrzwc 1/1 Running 0 8m14s 192.168.5.128 cn-hangzhou.192.168.5.120 <none> <none>
出力は、レプリカの数が6から4にスケーリングされることを示します。 弾性コンテナインスタンス上のポッドは削除されることが好ましい。
関連ドキュメント
スケールアウトアクティビティ中に複数のゾーンにノードを追加する方法の詳細については、「クロスゾーンデプロイの自動スケーリングの構成」をご参照ください。
クラスターのリソース容量がポッドスケジューリングの要件を満たさない場合にノードオートスケーリングを有効にするには、ACKが提供するノードスケーリングソリューションを参照することを推奨します。 詳細については、「ノードスケーリングの概要」をご参照ください。