Quando picos de tráfego excedem a capacidade dos nós do Elastic Compute Service (ECS), os pods do gateway de entrada do ASM precisam de um local para transbordar. Ao agendar pods de gateway em nós virtuais com suporte do Elastic Container Instance (ECI), os pods escalam automaticamente para a infraestrutura serverless, sem provisionamento ou manutenção de nós.
Em condições normais, os pods de gateway são executados em um nó ECS rotulado. Quando esse nó atinge a capacidade máxima, os pods transbordam para o ECI por meio de nós virtuais. Essa configuração utiliza primitivas de agendamento do Kubernetes — afinidade de nó, taints e tolerations — para controlar onde os pods são alocados.
Se o gateway ASM for executado em um cluster Serverless Kubernetes (ASK), os pods já rodam no ECI por padrão. Ignore este tópico e consulte Criar um serviço de gateway de entrada.
Como funciona
A configuração depende de três mecanismos de agendamento do Kubernetes que trabalham em conjunto:
|
Mecanismo |
Função |
|
Taint + Toleration |
Nós virtuais possuem um taint padrão |
|
Afinidade de nó obrigatória |
Restrição rígida que limita a alocação de pods a dois tipos de nó: o nó ECS rotulado ou nós virtuais. Os pods não podem ser alocados em nós não relacionados. |
|
Afinidade de nó preferencial |
Restrição flexível com pesos. O nó ECS recebe peso 80 (fortemente preferido) e o nó virtual recebe peso 20 (fallback). Quando o ECS tem capacidade, os pods rodam nele. Caso contrário, os pods transbordam para o ECI. |
Para mais detalhes, consulte a documentação do Kubernetes sobre Taints e Tolerations e Atribuição de Pods a Nós.
Pré-requisitos
Antes de começar, verifique se você possui:
Um cluster do Container Service for Kubernetes (ACK) (ACK standard, ACK Pro ou ACK dedicated) adicionado à instância ASM
O componente ack-virtual-node implantado no cluster ACK
Um gateway de entrada implantado na instância ASM
Configure o transbordo elástico para o gateway
Este procedimento consiste em quatro partes: rotular um nó ECS para pods de gateway, aplicar um taint no nó para excluir outras cargas de trabalho, configurar o YAML do gateway com regras de afinidade e tolerations e verificar a implantação.
Etapa 1: Rotular o nó de destino
Adicione um rótulo ao nó ECS onde os pods de gateway devem ser executados por padrão.
-
Obtenha os nomes dos nós no cluster:
kubectl get nodes -
Adicione um rótulo ao nó de destino: substitua
<node-name>pelo nome real do nó obtido na etapa 1.# Syntax kubectl label nodes <node-name> <label-key>=<label-value> # Example kubectl label nodes node1 mykey4pod=asmgateway
Etapa 2: Aplicar taint ao nó
Adicione um taint personalizado para garantir que apenas pods com uma toleration correspondente sejam executados neste nó:
kubectl taint nodes node1 mykey=myvalue:NoSchedule
Esse taint usa a chave mykey, o valor myvalue e o efeito NoSchedule. Apenas pods que toleram explicitamente esse taint podem ser agendados no node1.
Etapa 3: Adicionar afinidade de nó e tolerations ao gateway
Atualize o YAML do gateway para direcionar os pods ao nó ECS rotulado por padrão, com transbordo automático para o ECI quando o nó atingir a capacidade máxima.
Faça login no console ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.
Na página Mesh Management, clique em no nome da instância ASM. No painel de navegação à esquerda, escolha ASM Gateways > Ingress Gateway.
Localize o gateway de destino e clique em YAML.
-
Na caixa de diálogo Edit, adicione o seguinte conteúdo ao campo
spece clique em OK. A tabela abaixo explica o comportamento de agendamento:ImportanteCertifique-se de que o par chave-valor do rótulo em
matchExpressionscorresponda ao rótulo adicionado na Etapa 1 e que o par chave-valor da toleration corresponda ao taint adicionado na Etapa 2. Valores incompatíveis fazem com que os pods permaneçam no estado Pending.Campo
Funcionalidade
preferredDuringSchedulingIgnoredDuringExecutionDefine preferências de agendamento flexíveis com pesos relativos. O nó ECS (peso 80) é fortemente preferido em relação ao ECI (peso 20). Quando o nó ECS tem capacidade, os pods rodam nele. Se estiver cheio, os pods transbordam para o ECI via nós virtuais.
requiredDuringSchedulingIgnoredDuringExecutionEstabelece restrições rígidas. Os pods só podem ser agendados em nós que correspondam ao rótulo personalizado (
mykey4pod=asmgateway) ou ao rótulo do nó virtual (type=virtual-kubelet). Isso impede a alocação de pods em nós não relacionados.tolerations[0]Permite a execução de pods em nós virtuais ao tolerar o taint padrão
virtual-kubelet.io/provider=alibabacloud:NoSchedule. Sem essa toleration, os pods não conseguem usar o ECI.tolerations[1]Corresponde ao taint personalizado (
mykey=myvalue:NoSchedule) adicionado na Etapa 2, permitindo a execução de pods no nó ECS rotulado.affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - preference: matchExpressions: - key: type operator: In values: - virtual-kubelet weight: 20 - preference: matchExpressions: - key: mykey4pod operator: In values: - asmgateway weight: 80 requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: mykey4pod operator: In values: - asmgateway - matchExpressions: - key: type operator: In values: - virtual-kubelet tolerations: - effect: NoSchedule key: virtual-kubelet.io/provider operator: Equal value: alibabacloud - effect: NoSchedule key: mykey operator: Equal value: myvalue
Etapa 4: Verifique a implantação
Confirme se os pods de gateway estão sendo executados nos nós esperados.
Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do cluster. No painel de navegação à esquerda, escolha Workloads > Pods.
Na página Pods, selecione istio-system na lista suspensa Namespace.
-
Verifique a coluna Node dos pods de gateway:
Sob carga normal, os pods devem aparecer no nó ECS rotulado (
node1).Quando a capacidade do ECS se esgotar, os pods devem aparecer em um nó virtual.