Solução de agendamento de nó virtual ACK - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Os métodos de agendamento para nós virtuais diferem entre clusters gerenciados ACK (edições Pro e Basic) e clusters dedicados ACK. Essas soluções atendem a cenários específicos, como agendar pods exclusivamente em nós virtuais ou distribuí-los entre zonas. Este tópico ajuda você a escolher o método de agendamento mais adequado com base no seu cenário e no tipo de cluster.

Cenários comuns de agendamento de nós virtuais

Agendar pods apenas em nós virtuais.
Priorizar o agendamento em nós ECS e usar nós virtuais somente quando os recursos dos nós ECS forem insuficientes.

Para um cluster gerenciado ACK (Basic Edition), recomendamos o uso do rótulo alibabacloud.com/eci=true no primeiro cenário. No segundo cenário, sugerimos atualizar o cluster para um cluster gerenciado ACK (Pro Edition).

Nota

Os clusters gerenciados ACK (Pro Edition) oferecem recursos de agendamento que atendem melhor aos requisitos do segundo cenário, proporcionando maior confiabilidade, garantias de Acordo de Nível de Serviço (SLA) e maior capacidade de cluster. O ACK permite migrar sem interrupções de um cluster gerenciado ACK (Basic Edition) para um cluster gerenciado ACK (Pro Edition). Para mais informações, consulte Migrar a quente um cluster gerenciado ACK (Basic Edition) para um cluster gerenciado ACK (Pro Edition).

Observações de uso

O uso do rótulo alibabacloud.com/eci=true tem a prioridade mais alta. Ao utilizar esse rótulo, você substitui os seguintes métodos de agendamento:
- Semântica nativa de agendamento do Kubernetes, como nodeSelector, afinidade e anti-afinidade, e restrições de distribuição de topologia de pod
- ResourcePolicy
- ElasticResource (Annotation: alibabacloud.com/burst-resource)
Não recomendamos o uso de ElasticWorkload e ElasticResource (Annotation: alibabacloud.com/burst-resource), pois estão em estado de desenvolvimento inativo.
O componente virtual-kubelet-autoscaler não recebe mais manutenção. Recomendamos atualizar seu cluster gerenciado ACK (Basic Edition) para um cluster gerenciado ACK (Pro Edition) e desinstalar esse componente para liberar recursos de nó. Implemente a implantação distribuída e baseada em afinidade para pods ECI usando a semântica nativa de agendamento do Kubernetes. Para mais informações, consulte Implementar implantação distribuída e agendamento baseado em afinidade para pods ECI entre zonas.
Se um pod agendado em um nó virtual precisar usar um volume de disco provisionado dinamicamente, StorageClasses do tipo WaitForFirstConsumer não são compatíveis com os seguintes métodos de agendamento:
- Uso de rótulos: alibabacloud.com/eci=true.
- Especificação de um nó virtual por meio de nodeName.

Comparação de soluções e recomendações de escolha

As tabelas de comparação utilizam os seguintes termos:

Agendamento baseado em prioridade: quando existem diferentes tipos de nós em um cluster, configure a prioridade para agendar pods nesses tipos. Por exemplo, priorize o agendamento em nós ECS e utilize nós virtuais apenas quando os recursos dos nós ECS forem insuficientes.

Caso um método não ofereça suporte a agendamento baseado em prioridade, não será possível orquestrar prioridades para diferentes conjuntos de nós. Se você usar o rótulo alibabacloud.com/eci=true, por exemplo, só poderá agendar pods específicos em nós virtuais. Não há como configurar o sistema para priorizar nós ECS e recorrer aos virtuais apenas na falta de recursos ECS.
Política de agendamento estrita: define se as regras para agendamento em diferentes tipos de pools de nós são restrições rígidas.
- Uma política não estrita atua como restrição flexível. O campo preferredDuringSchedulingIgnoredDuringExecution da afinidade de nó, por exemplo, prioriza o agendamento em nós ECS. Contudo, devido à política abrangente de pontuação de nós, os pods ainda podem ser agendados em nós virtuais mesmo com recursos ECS disponíveis.
- Uma política estrita funciona como restrição rígida. O ResourcePolicy, por exemplo, garante que os pods sejam agendados em nós ECS desde que estes tenham recursos suficientes para atender aos requisitos do pod.

Cluster gerenciado ACK (Pro Edition)

Método de agendamento		Cenário típico	Agendamento baseado em prioridade	Reduzir escala de pods ECI prioritariamente	Recomendado	Operações relacionadas
labels: `alibabacloud.com/eci=true`		Agenda pods apenas em nós virtuais. Não é possível especificar qual nó virtual receberá os pods.	Não suportado	N/A	Recomendado	Agendar pods para execução no ECI
Semântica nativa de agendamento do Kubernetes	nodeSelector	Após adicionar uma tolerância, é possível agendar pods apenas em nós virtuais e especificar qual nó virtual receberá os pods.	Não suportado	N/A	Recomendado	nodeSelector
	Afinidade e anti-afinidade	Use Taint, Toleration e NodeAffinity para definir que os pods sejam agendados apenas em ECI, apenas em ECS ou preferencialmente em ECS (por exemplo, agendar em nós virtuais quando os recursos dos nós ECS forem insuficientes). Trata-se de uma política de agendamento elástica. Este método também suporta (e somente suporta) reduzir a escala do ECI primeiro e depois a do ECS.	Suportado (política de agendamento não estrita)	Suportado	Recomendado	Especificar alocação de recursos para ECS e ECI
	Restrições de distribuição de topologia de pod	Distribui pods entre zonas para atender aos requisitos de alta disponibilidade e agendamento de alto desempenho.	Não suportado	Suportado	Recomendado	Implementar implantação distribuída e agendamento baseado em afinidade para pods ECI entre zonas
ResourcePolicy Importante Na versão v1.20, o agendador ignora a verificação de não agendabilidade de pods para nós virtuais durante o processamento desses nós. A partir da v1.22, apenas a verificação de taint em nós virtuais é ignorada. Para manter o comportamento da v1.20, desative a capacidade de agendamento de nós virtuais nos parâmetros do agendador.		Oferece suporte a agendamento baseado em prioridade por pools de nós. Por exemplo, priorize o agendamento no Pool de Nós A e utilize o Pool de Nós B quando os recursos forem insuficientes. Em cenários com co-implantação de ECS e ECI, também é possível configurar métodos de faturamento de recursos. Priorize, por exemplo, o agendamento em ECS por assinatura, seguido por ECS pago conforme o uso e, por fim, ECI. Este método também permite reduzir a escala dos pods na ordem inversa do agendamento. Reduza primeiro o ECI, depois o ECS pago conforme o uso e, finalmente, o ECS por assinatura.	Suportado (política de agendamento estrita)	Suportado	Recomendado	Personalizar agendamento baseado em prioridade para recursos elásticos
UnitedDeployment		Permite criar uma política para agendar pods em ECS ou nós virtuais com base no número de réplicas de uma implantação. Se houver menos de 10 réplicas, recursos ECS por assinatura têm preferência. Entre 11 e 20 réplicas, recursos Spot são utilizados. Acima de 20 réplicas, recursos ECI são empregados.	Suportado	Suportado	Recomendado	UnitedDeployment Cenários onde recursos ECS e ECI são usados juntos
ElasticWorkload (Em estado de desenvolvimento inativo. Recomendamos o uso do UnitedDeployment.)		Agenda réplicas de uma implantação em ECS ou nós virtuais em grupos.	Suportado	Suportado	Não recomendado	Agendar pods de workloads elásticos para ECI usando Elastic Workload (descontinuado)
ElasticResource (Annotation: `alibabacloud.com/burst-resource`) (Em estado de desenvolvimento inativo)		Apenas duas políticas de agendamento elástico são suportadas: Agendar em nós virtuais quando os recursos dos nós ECS forem insuficientes (a política de agendamento elástico é `eci`). Agendar apenas em nós virtuais (a política de agendamento elástico é `eci_only`).	Suportado	Suportado	Não recomendado	Implementar agendamento elástico baseado em ECI usando ElasticResource (descontinuado)
Componente virtual-kubelet-autoscaler (Descontinuado)		Suporta apenas priorizar o agendamento em nós ECS e usar nós virtuais somente quando os recursos dos nós ECS forem insuficientes.	Suportado	Suportado	Não recomendado	Nenhuma

Cluster gerenciado ACK (Basic Edition) e Cluster dedicado ACK

Método de agendamento		Cenário típico	Agendamento baseado em prioridade	Reduzir escala de pods ECI prioritariamente	Recomendado	Operações relacionadas
labels: `alibabacloud.com/eci=true`		Agenda pods apenas em nós virtuais. Não é possível especificar qual nó virtual receberá os pods.	Não suportado	N/A	Recomendado	Agendar pods para execução no ECI
UnitedDeployment		Permite criar uma política para agendar pods em ECS ou nós virtuais com base no número de réplicas de uma implantação. Se houver menos de 10 réplicas, recursos ECS por assinatura têm preferência. Entre 11 e 20 réplicas, recursos Spot são utilizados. Acima de 20 réplicas, recursos ECI são empregados.	Suportado	Suportado	Recomendado	UnitedDeployment
Semântica nativa de agendamento do Kubernetes	nodeSelector	Após adicionar uma tolerância, é possível agendar pods apenas em nós virtuais e especificar qual nó virtual receberá os pods.	Não suportado	Suportado	Não recomendado Em comparação com um cluster gerenciado ACK (Pro Edition), o kube-scheduler em um cluster gerenciado ACK (Basic Edition) e em um cluster dedicado ACK não consegue perceber o inventário subjacente durante o agendamento de pods. Consequentemente, a certeza de criação bem-sucedida é reduzida.	nodeSelector
	Afinidade e anti-afinidade	Use Taint, Toleration e NodeAffinity para definir que os pods sejam agendados apenas em ECI, apenas em ECS ou preferencialmente em ECS (por exemplo, agendar em nós virtuais quando os recursos dos nós ECS forem insuficientes). Trata-se de uma política de agendamento elástica.	Suportado (política de agendamento não estrita)	Suportado		Afinidade e anti-afinidade
	Restrições de distribuição de topologia de pod	Distribui pods entre zonas para atender aos requisitos de alta disponibilidade e agendamento de alto desempenho.	Não suportado	Suportado		Restrições de distribuição de topologia de pod
ElasticWorkload (Em estado de desenvolvimento inativo. Recomendamos o uso do UnitedDeployment.)		Agenda réplicas de uma implantação em ECS ou nós virtuais em grupos.	Suportado	Suportado	Não recomendado	Agendar pods de workloads elásticos para ECI usando Elastic Workload (descontinuado)
ElasticResource (Annotation: `alibabacloud.com/burst-resource`) (Em estado de desenvolvimento inativo)		Apenas duas políticas de agendamento elástico são suportadas: Agendar em nós virtuais quando os recursos dos nós ECS forem insuficientes (a política de agendamento elástico é `eci`). Agendar apenas em nós virtuais (a política de agendamento elástico é `eci_only`).	Suportado	Suportado	Não recomendado	Implementar agendamento elástico baseado em ECI usando ElasticResource (descontinuado)
Componente virtual-kubelet-autoscaler (Descontinuado)		Suporta apenas priorizar o agendamento em nós ECS e usar nós virtuais somente quando os recursos dos nós ECS forem insuficientes.	Suportado	Suportado	Não recomendado	Nenhuma