UnitedDeployment カスタムリソースは、複数の同種のワークロードを Subsets と呼ばれる柔軟なユニットにグループ化することで、管理を簡素化します。例えば、アプリケーションを複数のアベイラビリティゾーンにデプロイする必要がある場合、各ゾーンの Deployment に対して Subset を定義できます。UnitedDeployment は、各 Subset の詳細な更新とデプロイメントを管理するため、個別の Deployment YAML ファイルを手動で設定・維持する必要がなくなります。
さらに、UnitedDeployment を Horizontal Pod Autoscaler (HPA) と組み合わせることで、複数のコンピューティングリソースを使用するクラスターで順序付きスケーリングを実現できます。これにより、Pod を特定の順序 (例えば、最も安価なリソースから最も高価なリソースへ) でスケールアップし、その逆の順序でスケールダウンすることが可能になり、リソースコストを大幅に最適化できます。
詳細については、Kruise の公式ドキュメント「UnitedDeployment」をご参照ください。本トピックでは、さまざまなシナリオの要件を満たすために、YAML ファイルを使用して UnitedDeployment コントローラーを設定する方法について説明します。
サポートされているワークロードタイプ
UnitedDeployment コントローラーは、StatefulSet、Advanced StatefulSet、CloneSet、Deployment のワークロードタイプのみをサポートします。詳細については、「OpenKruise を使用したクラウドネイティブアプリケーションのデプロイ」をご参照ください。
前提条件
`ack-kruise` アドオンがインストールされていること。詳細については、「アドオンの管理」をご参照ください。
`ACK Virtual Node` アドオンがインストールされていること。このアドオンは Elastic Container Instance (ECI) の利用を可能にします。詳細については、「アドオンの管理」をご参照ください。
`kubectl` クライアントが Container Service for Kubernetes (ACK) クラスターに接続されていること。詳細については、「クラスターの kubeconfig を取得し、kubectl を使用してクラスターに接続する」をご参照ください。
シナリオ 1：UnitedDeployment コントローラーと HPA の併用
ご利用のクラスターに複数のリソースタイプが含まれている場合、UnitedDeployment の YAML ファイルでサブセットを設定し、リソースタイプを選択します。また、maxReplicas フィールドを追加して、Pod 数が上限に達した後の Pod のスケジュール方法を指定することもできます。HPA を使用して UnitedDeployment の水平ポッド自動スケーリングを実装すると、Pod は指定されたリソースの優先度に基づいてスケーリングされます。HPA を設定する際、HPA の scaleTargetRef フィールドを UnitedDeployment とその UnitedDeployment の名前に設定します。
OpenKruise 1.5.0 が必要です。OpenKruise のリリースノートの詳細については、「OpenKruise」をご参照ください。
この例では、クラスター内に 2 つのノードプールが存在します。ノードプール A はサブスクリプション ECS インスタンスで構成され、ノードプール B はスポットインスタンスで構成されています。システムが、サブスクリプション ECS インスタンス > スポットインスタンス > ECI の優先順位で、異なるタイプのノードに Pod をスケジュールするように設定します。あるタイプのリソースが不足した場合、システムはより低い優先度のノードを Pod のスケジューリングに使用します。
test.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。
test.yaml ファイルは、UnitedDeployment をオーケストレーションするために使用されます。ファイル内の
templateパラメーターは、Deployment の設定を定義します。このファイルでは、3 つのサブセットも定義されています。subset-a の Pod はノードプール A のサブスクリプション ECS インスタンスにデプロイされ、subset-b の Pod はノードプール B のスポットインスタンスにデプロイされます。subset-a と subset-b の両方でレプリカ数は
1です。subset-c には、ECI を選択するための
nodeSelectorTermおよびtolerationsパラメーターが設定されています。この場合、subset-c の Pod は ECI にデプロイされます。subset-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**** # 値をノードプール A の ID に置き換えます。 replicas: 1 - name: subset-b nodeSelectorTerm: matchExpressions: - key: alibabacloud.com/nodepool-id operator: In values: - np011de1f2de3d48bd8a92a015fc5c**** # 値をノードプール B の ID に置き換えます。 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次のコマンドを実行して、Pod が作成されたかどうかを確認します。
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>この出力は、Pod が UnitedDeployment の設定で定義されているように、異なるサブセットにデプロイされていることを示しています。
シナリオ 2：ゾーンをまたいだアプリケーションのデプロイ
アプリケーションの可用性を向上させるには、通常、コンピューティングリソースやストレージリソースを複数のゾーンにまたがってデプロイする必要があります。異なるゾーンのノードに異なるラベルを追加できます。次に、UnitedDeployment の YAML ファイルのサブセット設定でラベルセレクターを設定します。これにより、UnitedDeployment は、異なるサブセットの Pod を、一致するラベルを持つ異なるゾーンにスケジュールします。
3 つのノードが異なるゾーンに存在します。次のコマンドを実行して、各ノードにそのノードが存在するゾーンを示すラベルを追加します。
例えば、ゾーン A のノードには
node=zone-aラベル、ゾーン B のノードにはnode=zone-bラベル、ゾーン C のノードにはnode=zone-cラベルが追加されます。kubectl label node cn-beijing.10.XX.XX.131 node=zone-a node/cn-beijing.10.80.20.131 labeled # ノード 10.XX.XX.131 に node=zone-a ラベルを追加します。 kubectl label node cn-beijing.10.XX.XX.132 node=zone-b node/cn-beijing.10.80.20.132 labeled # ノード 10.XX.XX.132 に node=zone-b ラベルを追加します。 kubectl label node cn-beijing.10.XX.XX.133 node=zone-c node/cn-beijing.10.80.20.133 labeled # ノード 10.XX.XX.133 に node=zone-c ラベルを追加します。test.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。
test.yaml ファイルは、UnitedDeployment をオーケストレーションするために使用されます。ファイル内の
templateパラメーターは、StatefulSet の設定を定義します。このファイルでは、ゾーンごとにサブセットも定義されています。statefulSetTemplateフィールドは StatefulSet のテンプレートを定義します。UnitedDeployment は、このテンプレートに基づいて各サブセットに StatefulSet を作成します。subsetsセクションでは、各ゾーンのサブセットを定義します。subset-a のポッドは、ラベルがnode=zone-aであるノードにデプロイされます。subset-bのポッドは、ラベルがnode=zone-bであるノードにデプロイされます。subset-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次のコマンドを実行して、Pod と StatefulSet が作成されたかどうかを確認します。
kubectl get pod # 想定される出力： 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 # 想定される出力： 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この出力は、Pod と StatefulSet が作成され、ゾーン A、ゾーン B、ゾーン C のノードで実行されていることを示しています。
シナリオ 3：UnitedDeployment コントローラーを使用した ECS インスタンスと ECI でのアプリケーションのコロケーション
ビジネスの急増に対応するため、クラスターノードのリソース供給を確保しつつ、同時にコストを管理する必要がある場合があります。この問題に対処するために、Pod スケジューリングで ECS インスタンスを優先し、ECS インスタンスが不足したときに ACK が自動的に ECI にアプリケーションをデプロイするように設定できます。Pod がスケールインされると、ACK はまず ECI 上で実行されている Pod を削除します。
次の例では、レプリカがどのようにスケジュールされるかを示すために UnitedDeployment が作成されます。レプリカ数が 4 を超えない場合、レプリカは ECS インスタンスにスケジュールされます。レプリカ数が 4 から 10 の間の場合、超過した Pod は ECI にスケジュールされます。
test.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。
deploymentTemplateフィールドは Deployment のテンプレートを定義します。UnitedDeployment は、このテンプレートに基づいて各サブセットに Deployment を作成します。subsetsセクションでは 2 つのサブセットを定義します。最初のサブセットの Pod は ECS インスタンスにスケジュールされます。2 番目のサブセットのレプリカは ECI にスケジュールされます。最初のサブセットは最大 4 つのレプリカをサポートします。UnitedDeployment によってプロビジョニングされるレプリカ数が 4 を超えない場合、レプリカは ECS インスタンスにスケジュールされます。レプリカ数が 4 から 10 の間の場合、超過した Pod は ECI にスケジュールされます。
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 # 値を 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次のコマンドを実行して、Pod のステータスをクエリします。
kubectl get pod -o wide # 想定される出力： 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>出力は、Deployment のレプリカが UnitedDeployment によって定義されたスケジューリングポリシーに基づいて動的にスケジュールされていることを示しています。最初の 4 つのレプリカは ECS インスタンスにスケジュールされ、残りの 2 つのレプリカは ECI にスケジュールされます。
HPA をトリガーしてスケールインアクティビティを実行し、次のコマンドを実行して Pod のステータスをクエリします。
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 にスケールダウンされたことを示しています。ECI 上の Pod が優先的に削除されます。
関連ドキュメント
スケールアウト時に複数のゾーンにノードを追加する方法の詳細については、「複数のゾーンにまたがる迅速なスケーリングの実装」をご参照ください。
クラスターのリソース容量が Pod スケジューリングの要件を満たせない場合にノードの自動スケーリングを有効にするには、ACK が提供するノードスケーリングソリューションを参照することを推奨します。詳細については、「ノードスケーリング」をご参照ください。