O componente ack-kubernetes-elastic-workload monitora um workload do Kubernetes e distribui réplicas entre os workloads de origem e as unidades elásticas com base em políticas de agendamento. Quando a contagem de réplicas ultrapassa um limiar configurado, o sistema agenda as réplicas adicionais em nós virtuais com suporte do Elastic Container Instance (ECI).
Você ainda pode usar o Elastic Workload. No entanto, esse recurso está com desenvolvimento inativo desde junho de 2024. Recomendamos o uso do UnitedDeployment como alternativa. Para comparar as soluções de agendamento em nós virtuais, consulte Agendar um pod em um nó virtual.
Pré-requisitos
Antes de começar, verifique se você possui:
Um cluster ACK gerenciado ou dedicado
O componente ack-virtual-node (v2.0.0.102-045a06eb4-aliyun ou posterior) implantado no cluster. Para mais informações, consulte Agendar pods em instâncias de contêiner elásticas por meio de nós virtuais.
Limitações
O ack-kubernetes-elastic-workload não oferece suporte a workloads do OpenKruise. Utilize o controlador UnitedDeployment como alternativa.
Instale o ack-kubernetes-elastic-workload
Faça login no Container Service Management Console.
No painel de navegação à esquerda, escolha .
Na página Marketplace, clique na aba App Catalog. Localize e clique em ack-kubernetes-elastic-workload.
Clique em Deploy.
No painel Deploy, selecione um cluster e namespace e clique em Next.
Na etapa Parameters, configure os parâmetros e clique em OK.
Verifique a instalação: Acesse a página de detalhes do cluster. No painel de navegação à esquerda, escolha Applications > Helm. Confirme se o ack-kubernetes-elastic-workload aparece na lista.
Agendar réplicas elásticas em nós virtuais
Este exemplo ilustra o planejamento de capacidade para uma aplicação com os seguintes requisitos:
Até 4 réplicas executadas em instâncias do Elastic Compute Service (ECS)
Manutenção de 2 réplicas durante horários de baixa demanda
Agendamento de réplicas excedentes a 4 em nós virtuais (ECI)
Etapa 1: Crie um Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-basic
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
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"Etapa 2: Definir um ElasticWorkload
apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
metadata:
name: elasticworkload-sample
spec:
sourceTarget:
name: nginx-deployment-basic
kind: Deployment
apiVersion: apps/v1
min: 2 # The minimum number of replicas.
max: 4 # The maximum number of replicas.
replicas: 6
elasticUnit:
- name: virtual-kubelet
labels:
alibabacloud.com/eci: "true"O ack-kubernetes-elastic-workload é implantado como um complemento externo e não afeta seus negócios existentes.
A definição de recurso personalizado (CRD) ElasticWorkload possui duas seções principais:
|
Campo |
Descrição |
|
|
Define o tipo de workload de origem e o intervalo de réplicas. As réplicas dentro do intervalo |
|
|
Um array de políticas de agendamento para unidades elásticas. Para definir políticas para múltiplas unidades elásticas, especifique os parâmetros relacionados na ordem definida. Quando as réplicas excedem |
Neste exemplo:
sourceTargetlimita o workload de origem (nginx-deployment-basic) a 2-4 réplicas em instâncias ECS.A contagem total de réplicas (6) supera o valor
max(4). As 2 réplicas restantes são agendadas para a unidade elástica virtual-kubelet com o rótuloalibabacloud.com/eci=true.
Etapa 3: Verifique a implantação
Verifique o status do elastic workload:
kubectl describe ew elasticworkload-sampleA saída mostra Desired Replicas tanto para o workload de origem quanto para a unidade elástica:
Status:
Elastic Units Status:
Desired Replicas: 2
Name: nginx-deployment-basic-unit-virtual-kubelet
Replicas: 6
Source Target:
Desired Replicas: 4
Kind: Deployment
Name: nginx-deployment-basicVerifique a distribuição dos pods entre os nós:
kubectl get pod -o wideSaída esperada:
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-basic-5bf87f5f59-22jnw 1/1 Running 0 16m 10.34.0.131 cn-beijing.172.16.0.1
nginx-deployment-basic-5bf87f5f59-gfp24 1/1 Running 0 13m 10.34.0.133 cn-beijing.172.16.0.1
nginx-deployment-basic-5bf87f5f59-pw2zx 1/1 Running 0 13m 10.34.0.134 cn-beijing.172.16.0.1
nginx-deployment-basic-5bf87f5f59-qvh7m 1/1 Running 0 16m 10.34.0.132 cn-beijing.172.16.0.1
nginx-deployment-basic-unit-virtual-kubelet-65fb6f4cd7-48ssb 1/1 Running 0 13m 172.16.22.157 virtual-kubelet-cn-beijing-e
nginx-deployment-basic-unit-virtual-kubelet-65fb6f4cd7-gjqhm 1/1 Running 0 13m 172.16.22.158 virtual-kubelet-cn-beijing-eOs primeiros 4 pods executam em nós ECS. Os 2 pods restantes executam em nós virtuais (ECI).
Usar HPA com elastic workloads
O Horizontal Pod Autoscaler (HPA) pode ter como alvo recursos ElasticWorkload diretamente. Durante a redução de escala, as réplicas das unidades elásticas diminuem primeiro.
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: 50Quando o HPA reduz as réplicas (por exemplo, de 6 para 4), o elastic workload remove primeiro as réplicas das unidades elásticas e mantém estáveis as réplicas do workload de origem.