ack-kubernetes-elastic-workload コンポーネントは Kubernetes ワークロードを監視し、Elastic ユニットの定義済みスケジューリングポリシーに基づいてワークロードを複製および生成します。 Elastic ワークロードのレプリカ数がしきい値に達すると、ソースワークロードと Elastic ユニットにスケジュールされるレプリカ数が動的に調整されます。 このトピックでは、Container Service for Kubernetes (ACK) クラスタに ack-kubernetes-elastic-workload をインストールして使用する方法について説明します。
Elastic ワークロードは引き続き使用できます。 ただし、Elastic ワークロードは 2024 年 6 月以降、非アクティブな開発状態になっています。 代わりに UnitedDeployment を使用することをお勧めします。
仮想ノードスケジューリングソリューション、比較、および選択に関する推奨事項の詳細については、「仮想ノードにポッドをスケジュールする」をご参照ください。
前提条件
ack-virtual-node コンポーネントがクラスタにデプロイされており、バージョンが v2.0.0.102-045a06eb4-aliyun 以降であること。 詳細については、「仮想ノードを介して Elastic Container Instance にポッドをスケジュールする」をご参照ください。
制限事項
ack-kubernetes-elastic-workload は OpenKruise ワークロードをサポートしていません。 UnitdDeployment コントローラーを使用することをお勧めします。
ack-kubernetes-elastic-workload のデプロイ
ACK コンソール にログインします。
ACK コンソールの左側のナビゲーションウィンドウで、 を選択します。
[マーケットプレイス] ページで、[アプリカタログ] タブをクリックします。 [ack-kubernetes-elastic-workload] を見つけてクリックします。
[ack-kubernetes-elastic-workload] ページで、[デプロイ] をクリックします。
[デプロイ] パネルで、クラスタと名前空間を選択し、[次へ] をクリックします。
[パラメーター] ステップで、パラメーターを設定し、[OK] をクリックします。
ack-kubernetes-elastic-workload をデプロイした後、クラスタの詳細ページに移動します。 左側のナビゲーションウィンドウで、 を選択します。 ack-kubernetes-elastic-workload がクラスタにデプロイされていることがわかります。
Elastic ワークロードの使用
たとえば、アプリケーションのキャパシティが計画されており、アプリケーションは Elastic Compute Service (ECS) インスタンス上で最大 4 つのレプリカを実行することが想定されているとします。 オフピーク時には 2 つのレプリカが保持されます。 レプリカ数が 4 を超える場合、追加のレプリカは仮想ノードにスケジュールされます。 これにより、ECS インスタンス上の他のアプリケーションへの影響を防ぎます。
Kubernetes を使用してポッドをスケジュールし、ポッドのライフサイクルを管理する場合、次の問題を解決する必要があります。上記のシナリオを実装するには、次の操作を実行する必要があります。
レプリカ数が特定の値に達したときに、スケジューリングポリシーがどのように変化するかを制御します。
Kubernetes がポッドのライフサイクルを管理するときに、特定のポッドにどのように優先順位を付けるか。
このセクションでは、ack-kubernetes-elastic-workload を使用して、Elastic ワークロードに対して上記の操作を実行する方法について説明します。
デプロイメントを作成します。
apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment metadata: name: nginx-deployment-basic labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: # nodeSelector: # env: test-team containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 ports: - containerPort: 80 resources: limits: cpu: "500m"Elastic ワークロードを定義します。
apiVersion: autoscaling.alibabacloud.com/v1beta1 kind: ElasticWorkload metadata: name: elasticworkload-sample spec: sourceTarget: name: nginx-deployment-basic kind: Deployment apiVersion: apps/v1 min: 2 # 最小レプリカ数 max: 4 # 最大レプリカ数 replicas: 6 elasticUnit: - name: virtual-kubelet labels: alibabacloud.com/eci: "true"ack-kubernetes-elastic-workload は HPA と同様に使用されます。 ack-kubernetes-elastic-workload は外部アドオンとしてデプロイされ、既存のビジネスには影響しません。

ack-kubernetes-elastic-workload コンポーネントは Kubernetes ワークロードを監視し、Elastic ユニットの定義済みスケジューリングポリシーに基づいてワークロードを複製および生成します。 Elastic ワークロードのレプリカ数がしきい値に達すると、ソースワークロードと Elastic ユニットにスケジュールされるレプリカ数が動的に調整されます。
通常、Elastic ワークロードは次の 2 つの部分で構成されます。
sourceTarget: ソースワークロードのタイプとレプリカ数の範囲を定義します。
elasticUnit: Elastic ユニットのスケジューリングポリシーを定義する配列。 複数の Elastic ユニットのスケジューリングポリシーを定義するには、テンプレートに示されている順序で関連パラメーターを指定します。
この例では、次のようになります。
sourceTarget で定義されているように、ソースワークロードのレプリカ数は 2 から 4 の範囲です。 この場合、Elastic ワークロードに 2 ~ 4 つのレプリカがある場合、レプリカはソースワークロードにスケジュールされます。 レプリカ数が 4 を超える場合、追加のレプリカは Elastic ユニット (仮想ノード virtual-kubelet) にスケジュールされます。
elasticUnit では、Elastic ユニットは virtual-kubelet 仮想ノードとして定義されており、
labels: alibabacloud.com/eci=trueスケジューリングポリシーに対応しています。
デプロイ結果を表示します。
Elastic ワークロードのステータスを表示します。
kubectl describe ew elasticworkload-sample # kubectl get elasticworkload と同じです以下のようなコマンド出力が返されます。 Status セクションの Desired Replicas の値は、Elastic ユニットにスケジュールされているレプリカ数を示します。
Name: elasticworkload-sample Namespace: default Labels: <none> Annotations: <none> API Version: autoscaling.alibabacloud.com/v1beta1 Kind: ElasticWorkload Metadata: Creation Timestamp: 2021-05-21T01:53:58Z Generation: 4 Managed Fields: API Version: autoscaling.alibabacloud.com/v1beta1 Fields Type: FieldsV1 fieldsV1: f:spec: .: f:elasticUnit: f:replicas: f:sourceTarget: .: f:apiVersion: f:kind: f:max: f:min: f:name: Manager: Apache-HttpClient Operation: Update Time: 2021-05-21T01:53:58Z API Version: autoscaling.alibabacloud.com/v1beta1 Fields Type: FieldsV1 fieldsV1: f:status: .: f:elasticUnitsStatus: f:replicas: f:selector: f:sourceTarget: .: f:apiVersion: f:desiredReplicas: f:kind: f:name: f:updateTimestamp: Manager: manager Operation: Update Time: 2021-05-21T01:56:45Z Resource Version: 8727 Self Link: /apis/autoscaling.alibabacloud.com/v1beta1/namespaces/default/elasticworkloads/elasticworkload-sample UID: c4a508aa-2702-4d17-ac25-e6a207c0761a Spec: Elastic Unit: Labels: alibabacloud.com/eci: true Name: virtual-kubelet Replicas: 6 Source Target: API Version: apps/v1 Kind: Deployment Max: 4 Min: 2 Name: nginx-deployment-basic Status: Elastic Units Status: Desired Replicas: 2 Name: nginx-deployment-basic-unit-virtual-kubelet Update Timestamp: 2021-05-21T01:56:45Z Replicas: 6 Selector: app=nginx Source Target: API Version: apps/v1 Desired Replicas: 4 Kind: Deployment Name: nginx-deployment-basic Update Timestamp: 2021-05-21T01:56:45Z Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SourceUpdate 12m ElasticWorkload Source Target scale from 2 to 4 Normal UnitCreation 12m ElasticWorkload ElasticWorkloadUnit nginx-deployment-basic-unit-virtual-kubelet created Normal ElasticWorkloadUpdate 9m27s (x9 over 12m) ElasticWorkload ElasticWorkload update Normal UnitUpdate 9m27s (x8 over 12m) ElasticWorkload ElasticWorkloadUnit virtual-kubelet has been updatedポッドのステータスを表示します。
kubectl get pod -o wide以下のようなコマンド出力が返されます。 出力は、Elastic ワークロードがデプロイメントとポッドを複製し、これらのデプロイメントのポッドレプリカが定義済みのスケジューリングポリシーに基づいて動的にスケジュールされていることを示しています。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-deployment-basic-5bf87f5f59-22jnw 1/1 Running 0 16m 10.34.0.131 cn-beijing.172.16.0.1 <none> <none> nginx-deployment-basic-5bf87f5f59-gfp24 1/1 Running 0 13m 10.34.0.133 cn-beijing.172.16.0.1 <none> <none> nginx-deployment-basic-5bf87f5f59-pw2zx 1/1 Running 0 13m 10.34.0.134 cn-beijing.172.16.0.1 <none> <none> nginx-deployment-basic-5bf87f5f59-qvh7m 1/1 Running 0 16m 10.34.0.132 cn-beijing.172.16.0.1 <none> <none> nginx-deployment-basic-unit-virtual-kubelet-65fb6f4cd7-48ssb 1/1 Running 0 13m 172.16.22.157 virtual-kubelet-cn-beijing-e <none> <none> nginx-deployment-basic-unit-virtual-kubelet-65fb6f4cd7-gjqhm 1/1 Running 0 13m 172.16.22.158 virtual-kubelet-cn-beijing-e <none> <none>
さらに、HPA は Elastic ワークロードに使用できます。 Elastic ワークロードは、HPA のステータスに基づいて、各 Elastic ユニットにスケジュールされるレプリカ数を動的に調整できます。 たとえば、Elastic ワークロードのデプロイメントのレプリカ数が 6 から 4 に変更された場合、Elastic ワークロードは優先的に Elastic ユニットのレプリカを削減します。 次の図は例です。
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: elastic-workload-demo
namespace: default
spec:
scaleTargetRef:
apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
name: elasticworkload-sample
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50結論として、Elastic ワークロードは、スケジューリングポリシーを複製およびオーバーライドすることにより、デプロイメントを生成できます。 これにより、スケジューリングポリシーを管理できます。 また、Elastic ワークロードは、ソースワークロードにスケジュールされるレプリカ数を調整し、指定された範囲内で Elastic ユニットにスケジュールされるレプリカ数を調整することもできます。 これにより、ライフサイクル管理のために特定のポッドに優先順位を付けることができます。