As versões 1,18 a 1,24 do Kubernetes mantêm a capacidade de agendamento elástico no Elastic Container Instance (ECI). Desde maio de 2023, o Container Service for Kubernetes (ACK) descontinuou a manutenção desse recurso para clusters que executam o Kubernetes v1.24 ou posterior. Utilize uma das alternativas abaixo:
Configure alocação de recursos com base em instâncias ECS e elastic container instances: Aplique agendamento exclusivo para ECI, exclusivo para ECS ou com preferência por ECS usando taints, tolerations e afinidade de nó nativos do Kubernetes.
Configure agendamento de recursos baseado em prioridade: Use ResourcePolicy para estratégias avançadas, incluindo agendamento por prioridade entre ECS por assinatura, ECS com pagamento conforme o uso e ECI; redução de escala em ordem inversa; e migração não intrusiva de pods.
Para comparar as soluções de agendamento em nós virtuais, consulte Agendar um pod em um nó virtual.
O agendamento baseado em Elastic Container Instance permite controlar qual backend de computação executa seus pods adicionando uma única anotação aos metadados do pod. Dependendo do valor da anotação, os pods são executados exclusivamente em nós do Elastic Compute Service (ECS), exclusivamente em elastic container instances ou em elastic container instances apenas quando a capacidade de ECS no cluster se esgota.
Pré-requisitos
Antes de começar, verifique se você possui:
Um cluster ACK gerenciado Pro
-
Uma versão compatível do scheduler para sua versão do Kubernetes: Para detalhes sobre as versões do scheduler, consulte kube-scheduler.
Versão do Kubernetes
Versão mínima do scheduler
1,18
v1.18-ack-3.0
1,20
v1.20.4-ack-4.0
1,22
v1.22.3-ack-1.0
1,24
v1.24.3-ack-2.0
O componente
ack-virtual-nodeimplantado no cluster. Para instruções de configuração, consulte Agendar pods em elastic container instances por meio de nós virtuais.
Configure o modo de agendamento
Adicione a anotação alibabacloud.com/burst-resource à seção metadata do pod. Em um Deployment, insira a anotação em spec.template.metadata.
A tabela a seguir resume como cada valor de anotação afeta o comportamento de agendamento:
|
Valor da anotação |
Comportamento de agendamento |
Requer nó virtual |
Falha se |
|
(não definido) |
Utilizar apenas os nós ECS existentes no cluster (padrão) |
Não |
— |
|
|
Priorizar nós ECS; recorrer ao ECI quando a capacidade de ECS for insuficiente |
— |
— |
|
|
Usar somente ECI; nunca utilizar nós ECS |
Sim |
Não existir nenhum nó virtual no cluster |
|
Qualquer outro valor |
— |
— |
Sempre falhar; valor inválido |
A configuração alibabacloud.com/burst-resource: eci entra em conflito com alibabacloud.com/fluid-sidecar-target: eci. Para exemplos de uso de alibabacloud.com/fluid-sidecar-target, consulte Acelerar o acesso a dados em computação em nuvem serverless e tópicos relacionados.
Aplicar a anotação
-
Crie um arquivo chamado
nginx-deployment.yamlcom o seguinte conteúdo:apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: app: nginx spec: replicas: 4 selector: matchLabels: app: nginx template: metadata: name: nginx annotations: alibabacloud.com/burst-resource: eci # Fall back to ECI when ECS capacity is insufficient labels: app: nginx spec: containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 resources: limits: cpu: 2 requests: cpu: 2 -
Execute o manifesto:
kubectl apply -f nginx-deployment.yaml
Cenários de falha
O agendamento do pod falha nas seguintes situações:
O valor da anotação não é
ecinemeci_only. A mensagem do PodStatus érequesttypemustbeeci,eci_onlyorecs(Kubernetes v1.22.15 e v1.24.6).A anotação está definida como
eci_only, mas não há nenhum nó virtual no cluster. Nesse caso, a mensagem do PodStatus exibedoesn'tfitecitype:eci_only(Kubernetes v1.22.15 e v1.24.6).