Usar instâncias ECS fora do pico e instâncias de contêiner elásticas para lidar com picos de tráfego no Knative - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Execute cargas de trabalho base do Knative em instâncias existentes do Elastic Compute Service (ECS) e direcione automaticamente os picos de tráfego para instâncias de contêiner elásticas (ECI), sem provisionar VMs adicionais. Uma ResourcePolicy controla a prioridade de agendamento entre os dois tipos de recurso: o ECS tem preferência em estado estável, enquanto a ECI absorve o excesso. Durante o scale-in, as instâncias ECI são liberadas primeiro.

Pré-requisitos

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

O Knative implantado no cluster. Consulte Implantar o Knative em um cluster ACK ou Implantar o Knative em um cluster ACK Serverless.

Uma versão do kube-scheduler compatível com a versão do Kubernetes:

Versão do Kubernetes	Versão do kube-scheduler
1.20	1.20.4-ack-7.0 ou posterior
1.22	1.22.15-ack-2.0 ou posterior
1.24	1.24.3-ack-2.0 ou posterior
1.26	1.26.3-ack-4.0 ou posterior
1,26 ou posterior	Todas as versões

O componente ack-virtual-node implantado. Esse componente é obrigatório para instâncias de contêiner elásticas. Consulte Implantar o ack-virtual-node no cluster.
Um arquivo kubeconfig obtido e o kubectl conectado ao cluster. Consulte Conectar-se ao cluster usando o kubectl.

Limitações

Restrição	Detalhes
Exclusividade mútua com custo de exclusão de pod	O agendamento de recursos baseado em prioridade é incompatível com o recurso de custo de exclusão de pod.
Exclusividade mútua com agendamento baseado em ECI	O agendamento de recursos baseado em prioridade é incompatível com o agendamento baseado em Elastic Container Instance.
Scale-in com melhor esforço	A ResourcePolicy utiliza a estratégia `prefer` (BestEffort). O scale-in não garante a remoção dos pods em ordem estrita de prioridade.
O parâmetro `max` exige Kubernetes 1.22+ e scheduler 5,0+	O parâmetro `max` só está disponível quando o cluster executa Kubernetes 1.22 ou posterior e a versão do scheduler é 5,0 ou superior.
Node pools elásticos devem estar em units sem `max`	Ao usar node pools elásticos, inclua-os nas units, mas não especifique o parâmetro `max` para essas units.
Pods pré-existentes (scheduler < 5,0 ou Kubernetes 1.20 ou anterior)	Os pods criados antes da ResourcePolicy recebem prioridade durante o scale-in.
Modificação da ResourcePolicy (scheduler < 6,1 ou Kubernetes 1.20 ou anterior)	Não modifique a ResourcePolicy até que todos os pods selecionados por ela sejam excluídos.

Crie uma ResourcePolicy para agendamento híbrido de ECS e ECI

Uma ResourcePolicy tem como alvo um Knative Service por rótulo e define uma lista ordenada de units. Cada unit mapeia para um tipo de recurso (ECS ou ECI) e pode, opcionalmente, limitar o número de pods com max. O scheduler percorre as units em ordem: quando uma unit ECS está cheia ou não há capacidade ECS disponível, os pods transbordam para a próxima unit.

Crie um Knative Service.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

Crie uma ResourcePolicy direcionada ao Knative Service helloworld-go. As instâncias ECS têm a maior prioridade. A ECI atua como fallback — os pods são agendados na ECI apenas quando a capacidade do ECS se esgota ou quando o número de pods em uma unit ECS atinge o limite max.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: xxx
  namespace: xxx
spec:
  selector:
    serving.knative.dev/service: helloworld-go  # Target Knative Service name
  strategy: prefer
  units:
  - resource: ecs
    max: 10           # Cap at 10 pods on this ECS node group
    nodeSelector:
      key2: value2
  - resource: ecs     # Secondary ECS node group (no cap)
    nodeSelector:
      key3: value3
  - resource: eci     # ECI absorbs overflow; released first during scale-in

O scale-in segue a ordem inversa das units com base no melhor esforço — as instâncias ECI são preferencialmente liberadas primeiro, mas a ordenação estrita não é garantida.

Próximos passos

Para obter mais detalhes sobre os parâmetros de agendamento de recursos baseado em prioridade, consulte Configure agendamento de recursos baseado em prioridade.