Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Use spot instances in Knative

Última atualização: Jun 27, 2026

Instâncias spot são instâncias de computação preemptivas com preços significativamente inferiores aos das instâncias sob demanda. Se suas cargas de trabalho do Knative lidam com requisições de curta duração e toleram interrupções ocasionais, a migração para instâncias spot reduz substancialmente os custos de computação e mantém a elasticidade e a capacidade de resposta da sua arquitetura serverless.

Este tópico explica como configurar instâncias spot para Serviços do Knative no Container Service for Kubernetes (ACK), lidar adequadamente com interrupções e monitorar o status das instâncias spot.

Pré-requisitos

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

Conceitos principais

  • Instância spot

    Uma instância de computação preemptiva e econômica. Você pode dar lances na capacidade ociosa de computação da Alibaba Cloud para executar seus containers. A instância permanece em execução até que seu lance fique abaixo do preço de mercado atual ou até que o recurso seja recuperado devido à falta de estoque. Para mais informações, consulte O que é uma instância spot?

  • Knative

    O Knative visa estabelecer um padrão para orquestração de aplicações serverless nativas da nuvem e multiplataforma. Seus principais recursos incluem dimensionamento automático baseado em requisições, redução a zero, gerenciamento de múltiplas versões, lançamentos canary baseados em tráfego, implantação de funções e arquitetura orientada a eventos. Para mais informações, consulte Visão geral do ACK Knative e Visão geral do ACK Serverless Knative.

Como funciona

Os Serviços do Knative dimensionam automaticamente os Pods conforme as requisições recebidas. Cada Pod executa em um nó virtual, que provisiona o recurso correspondente do Elastic Container Instance (ECI) com base nas anotações do Pod. Para utilizar instâncias spot, adicione anotações específicas ao modelo de Pod do seu Serviço Knative. O nó virtual cuida do provisionamento e da substituição automática.

image

O Knative é ideal para instâncias spot pelos seguintes motivos:

  • Cargas de trabalho escopadas por requisição: Os Pods do Knative processam requisições individuais e liberam recursos imediatamente após a conclusão. Assim, interrupções raramente afetam o trabalho em andamento.

  • Desligamento controlado nativo: O Knative injeta um container sidecar queue-proxy em cada Pod. Quando um Pod é encerrado, o queue-proxy aguarda a conclusão de todas as requisições em trânsito antes que o container da aplicação seja desligado.

  • Economia de custos: Para usuários do Knative focados em otimização orçamentária, o uso de instâncias spot proporciona uma redução significativa de despesas.

Limitações

Importante

As anotações de instância spot são aplicadas apenas durante a criação de um Pod ECI. Adicionar ou modificar essas anotações em um Pod ECI existente não surte efeito.

Configurar instâncias spot

Adicione as seguintes anotações ao modelo de Pod do seu Serviço Knative.

Anotação

Valor de exemplo

Obrigatório

Descrição

k8s.aliyun.com/eci-spot-strategy

SpotAsPriceGo

Sim

Estratégia de lance. Valores válidos: SpotWithPriceLimit e SpotAsPriceGo. Consulte Escolher uma estratégia de lance para obter detalhes.

k8s.aliyun.com/eci-spot-price-limit

"0.5"

Não

Preço horário máximo para a instância spot. O valor aceita até três casas decimais. Vigente apenas quando eci-spot-strategy está definido como SpotWithPriceLimit.

k8s.aliyun.com/eci-spot-duration

"1"

Não

Período de proteção em horas. Padrão: 1. Defina como 0 para desativar o período de proteção. Durante esse intervalo, a instância spot não é recuperada mesmo que o preço de mercado ultrapasse seu lance.

k8s.aliyun.com/eci-spot-fallback

"true"

Não

Indica se deve criar uma instância sob demanda caso não haja estoque spot disponível. Padrão: false. Quando definido como true, o nó virtual recorre a uma instância sob demanda tanto na criação quanto na substituição de um Pod recuperado.

Escolher uma estratégia de lance

Existem duas estratégias de lance disponíveis. Escolha conforme sua tolerância a variações de custo e falhas na criação.

Estratégia

Funcionamento do preço

Comportamento de criação

SpotAsPriceGo

Segue automaticamente o preço de mercado atual

A criação pode ter sucesso se houver estoque; quando a demanda por recursos do tipo de instância especificado é alta, o preço pode atingir o valor sob demanda

SpotWithPriceLimit

Faz um lance com um preço máximo fixo definido por você

Falha se não houver estoque disponível no seu limite de preço ou abaixo dele

Importante

Ao usar SpotAsPriceGo em períodos de alta demanda de recursos, o preço spot pode atingir o preço sob demanda.

Exemplos

Exemplo 1: Limite de preço fixo

O YAML a seguir cria uma instância spot usando a estratégia SpotWithPriceLimit com preço horário máximo de $0,25.

  • Durante a criação: falha se não houver estoque disponível para o tipo de instância especificado a $0,25/hora ou menos.

  • Após a criação: a instância executa com um período de proteção garantido de 1 hora. Terminada essa proteção, a instância é recuperada se o preço de mercado exceder $0,25 ou se o tipo de instância especificado tiver estoque insuficiente.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/eci: "true"
      annotations:
        k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # Specify the ECS instance type.
        k8s.aliyun.com/eci-spot-strategy: "SpotWithPriceLimit"  # Use the strategy that sets a custom price limit.
        k8s.aliyun.com/eci-spot-price-limit: "0.25"            # Set the maximum hourly price.
    spec:
      containers:
      - env:
        - name: TARGET
          value: "Knative"
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Exemplo 2: Limite de preço fixo com fallback para sob demanda

O YAML abaixo cria uma instância spot com fallback para sob demanda, equilibrando economia de custos e disponibilidade.

  • Durante a criação: se houver estoque spot disponível a $0,05/hora ou menos, uma instância spot é criada com período de proteção de 1 hora. Caso contrário, uma instância sob demanda é provisionada, a qual não é recuperada automaticamente.

  • Após a criação: se a instância spot for recuperada após o período de proteção, o nó virtual cria um substituto. Se ainda não houver estoque spot no momento da substituição, uma instância sob demanda será criada.

Para verificar se um Pod foi rebaixado para sob demanda, execute kubectl describe pod e procure pelo evento SpotDegraded na saída.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        alibabacloud.com/eci: "true"
      annotations:
        k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # Specify the ECS instance type.
        k8s.aliyun.com/eci-spot-strategy: "SpotWithPriceLimit"  # Use the strategy that sets a custom price limit.
        k8s.aliyun.com/eci-spot-price-limit: "0.05"             # Set the maximum hourly price.
        k8s.aliyun.com/eci-spot-fallback: "true"                # Automatically fall back to an on-demand instance if spot inventory is unavailable.
    spec:
      containers:
      - env:
        - name: TARGET
          value: "Knative"
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Criar um Serviço Knative com instâncias spot

O procedimento a seguir cria um Serviço Knative de exemplo que utiliza a estratégia SpotAsPriceGo com fallback para sob demanda ativado.

  1. Faça login no console do ACK. No painel de navegação à esquerda, clique em console do ACKClusters.

  2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Applications > Knative.

  3. Na página Knative, clique na aba Services. Selecione default na lista suspensa Namespace e clique em Create from Template. Na lista suspensa Sample Template, selecione custom. Cole o YAML a seguir no editor e clique em Create.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: helloworld-go
    spec:
      template:
        metadata:
          labels:
            alibabacloud.com/eci: "true"
          annotations:
            k8s.aliyun.com/eci-use-specs : "ecs.c6.large"           # Specify the ECS instance type.
            k8s.aliyun.com/eci-spot-strategy: "SpotAsPriceGo"       # Use the strategy that follows the market price.
            k8s.aliyun.com/eci-spot-duration: "1"                   # Protection period in hours.
            k8s.aliyun.com/eci-spot-fallback: "true"                # Fall back to on-demand if spot inventory is unavailable.
        spec:
          containers:
          - env:
            - name: TARGET
              value: "Knative"
            image: registry-vpc.{REGION-ID}.aliyuncs.com/knative-samples/helloworld-go:160e4dc8 # Replace {REGION-ID} with your cluster's region ID, such as cn-hangzhou.

    Essa configuração cria uma instância spot ecs.c6.large com o seguinte comportamento:

    • Se não houver estoque spot disponível no momento da criação, uma instância sob demanda será provisionada.

    • Após a criação, a instância executa com um período de proteção garantido de 1 hora.

    • Terminada a proteção, a instância spot pode ser recuperada se o preço de mercado superar o lance atual ou se o estoque tornar-se insuficiente. A configuração eci-spot-fallback: "true" garante a criação de uma instância sob demanda caso não haja estoque spot quando o nó virtual substituir o Pod.

Lidar com interrupções de instâncias spot

A Alibaba Cloud envia um evento SpotToBeReleased e define a condição do pod ContainerInstanceExpired como true aproximadamente 3 minutos antes da recuperação da instância spot.

A figura a seguir mostra um exemplo da notificação.图片 1.png

Nessa janela de 3 minutos, configure o tratamento controlado para que as requisições em trânsito sejam concluídas antes do encerramento do Pod.

Configurar eviction baseada em API

Adicione a anotação k8s.aliyun.com/eci-spot-release-strategy: api-evict aos seus Pods spot. Quando o nó virtual recebe um evento SpotToBeReleased, ele chama a API de Eviction para remover o Pod. Isso respeita as configurações do PodDisruptionBudget (PDB) e de terminationGracePeriodSeconds.

A sequência de eviction é:

  1. O nó virtual recebe um evento SpotToBeReleased e invoca a API de Eviction.

  2. O servidor de API verifica o PDB configurado para o Pod.

  3. O timestamp de exclusão do Pod é definido e o período de carência começa.

  4. O kubelet no nó virtual inicia o desligamento controlado do Pod.

  5. O plano de controle desassocia o Pod dos Endpoints e EndpointSlices relevantes.

  6. Ao término do período de carência, o kubelet encerra forçadamente o Pod.

  7. O kubelet notifica o sistema para excluir o Pod.

  8. O servidor de API exclui o Pod.

Em um ambiente Knative, o sidecar queue-proxy aguarda a conclusão de todas as requisições em trânsito antes que o container da aplicação pare, proporcionando um desligamento suave na etapa 4.

Monitorar eventos de instâncias spot

Visualizar o evento SpotToBeReleased

Execute kubectl describe para visualizar o aviso de interrupção na seção Events:

Events:
  Type     Reason            Age    From          Message
  ----     ------            ----   ----          -------
  Warning  SpotToBeReleased  3m32s  kubelet, eci  Spot ECI will be released in 3 minutes

Alternativamente, execute kubectl get events para listar todos os eventos recentes:

LAST SEEN   TYPE      REASON             OBJECT         MESSAGE
3m39s       Warning   SpotToBeReleased   pod/pi-frmr8   Spot ECI will be released in 3 minutes

Para informações sobre como automatizar respostas a eventos de interrupção, consulte Encerramento controlado.

Verificar o status após a recuperação

Mesmo após a recuperação de uma instância spot, as informações da instância permanecem retidas. O status do Pod muda para BidFailed e a causa da falha é BidFailed.

Execute kubectl get pod para visualizar o status:

NAME       READY   STATUS      RESTARTS   AGE
pi-frmr8   1/1     BidFailed   0          3h5m

Execute kubectl describe para visualizar os detalhes completos do status:

Status:             Failed
Reason:             BidFailed
Message:            The pod is spot instance, and have been released at 2020-04-08T12:36Z

Próximos passos

Se sua aplicação for sensível à latência de cold start, considere usar instâncias reservadas para manter uma instância burstable de baixa especificação sempre ativa. Isso reduz o tempo de inicialização sem aumentar significativamente os custos. Para mais informações, consulte Configurar instâncias reservadas.