Schedule pods to an x86-based virtual node - Elastic Container Instance: Central de Documentação do Alibaba Cloud

Em clusters ACK que combinam nós reais do Elastic Compute Service (ECS) com nós virtuais do Elastic Container Instance (ECI), os pods são agendados para os nós reais por padrão. Para executar pods específicos no ECI, adicione um rótulo a esses pods ou ao namespace correspondente para redirecioná-los ao nó virtual baseado em x86.

Nota

Os clusters ACK Serverless executam todos os pods em nós virtuais automaticamente, sem necessidade de configuração de agendamento. Por padrão, os nós virtuais utilizam arquitetura x86. Os métodos descritos neste tópico aplicam-se apenas a clusters ACK que possuem tanto nós reais quanto nós virtuais.

Pré-requisitos

Antes de começar, verifique se você possui:

Um cluster ACK com pelo menos um nó virtual baseado em x86 (ECI) registrado
O kubectl configurado com acesso ao cluster

Escolha um método de agendamento

Selecione o método adequado conforme a quantidade de pods que deseja redirecionar para o ECI:

Cenário	Método	Recomendado
Executar alguns pods específicos no ECI	Adicione um rótulo a cada pod	Sim
Executar todos os pods de um namespace no ECI	Adicione um rótulo ao namespace	Sim
Utilizar afinidade de nó ou nome fixo de nó	Configure `nodeSelector`/`tolerations` ou `nodeName`	Não

Importante

Para agendamento automático e baseado em políticas, sem modificar recursos individuais, configure um eci-profile. O eci-profile identifica os pods por rótulo e os agenda para o ECI automaticamente.

Observações de uso

Todos os métodos exigem a modificação de recursos existentes e podem introduzir vulnerabilidades de segurança. Revise as alterações cuidadosamente antes de aplicá-las.
Ao utilizar rótulos de pod, rótulos de namespace ou nodeName para agendar pods, o provisionador não oferece suporte ao modo de vinculação WaitForFirstConsumer para volumes de disco provisionados dinamicamente. Para mais detalhes, consulte Usar um volume de disco provisionado dinamicamente.

Método 1: Adicionar um rótulo ao pod

Adicione o rótulo alibabacloud.com/eci=true diretamente à especificação do pod para agendá-lo no nó virtual baseado em x86. Use este método quando precisar direcionar pods individualmente.

Nota

O rótulo eci=true também funciona, mas está obsoleto. Use alibabacloud.com/eci=true em seu lugar.

Crie um manifesto de pod com o rótulo:

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  labels:
    alibabacloud.com/eci: "true"   # Schedules this pod to the virtual node
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx

Aplique o manifesto:
```
kubectl create -f test-pod.yaml
```

Método 2: Adicionar um rótulo ao namespace

Rotule um namespace com alibabacloud.com/eci=true para agendar todos os pods desse namespace no nó virtual baseado em x86. Use esta abordagem quando todos os pods de um namespace dedicado devem ser executados no ECI.

Nota

O rótulo de namespace virtual-node-affinity-injection=enabled também funciona, mas está obsoleto. Use alibabacloud.com/eci=true em seu lugar.

Crie um namespace:
```
kubectl create ns vk
```

Adicione o rótulo ao namespace:

kubectl label namespace vk alibabacloud.com/eci=true

Crie um manifesto de pod direcionado ao namespace rotulado:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: vk   # Pods in this namespace are automatically scheduled to the virtual node
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx

Aplique o manifesto:
```
kubectl create -f test-pod.yaml
```

Método 3: Usar nodeSelector, tolerations ou nodeName (não recomendado)

Estes métodos dependem de primitivas de agendamento de baixo nível do Kubernetes, como rótulos de afinidade de nó, taints e nomes explícitos de nós. Eles são propensos a erros, fortemente acoplados às convenções de nomenclatura de nós e mais difíceis de manter do que o agendamento baseado em rótulos. Use-os apenas se os métodos baseados em rótulos acima não atenderem aos seus requisitos.

Por padrão, os nós virtuais baseados em x86 possuem o rótulo type: virtual-kubelet e um taint com a chave virtual-kubelet.io/provider. Para agendar um pod nesses nós, configure a especificação do pod para corresponder a esse rótulo e tolerar o taint.

Crie um manifesto de pod utilizando uma das seguintes abordagens:

Opção A: nodeSelector e tolerations

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx
  nodeSelector:
    type: virtual-kubelet          # Targets nodes with this label
  tolerations:
  - key: virtual-kubelet.io/provider
    operator: Exists               # Tolerates the default taint on virtual nodes

Opção B: nodeName

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx
  nodeName: virtual-kubelet-cn-beijing-g   # Targets a specific virtual node by name

Aplique o manifesto:

kubectl create -f test-pod.yaml

Próximos passos

Configure um eci-profile — Defina o agendamento automático de pods sem modificar recursos individuais.
Usar um volume de disco provisionado dinamicamente — Compreenda as limitações de armazenamento quando os pods são executados em nós virtuais.