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:
O Knative implantado no seu cluster ACK. Para mais informações, consulte Implantar e gerenciar componentes do Knative.
A versão 2.11.0 ou posterior do ack-virtual-node, caso deseje usar a API de Eviction para desligamento controlado. Para mais informações, consulte ack-virtual-node.
Conceitos principais
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.

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-proxyem cada Pod. Quando um Pod é encerrado, oqueue-proxyaguarda 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
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 |
|
|
|
Sim |
Estratégia de lance. Valores válidos: |
|
|
|
Não |
Preço horário máximo para a instância spot. O valor aceita até três casas decimais. Vigente apenas quando |
|
|
|
Não |
Período de proteção em horas. Padrão: |
|
|
|
Não |
Indica se deve criar uma instância sob demanda caso não haja estoque spot disponível. Padrão: |
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 |
|
|
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 |
|
|
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 |
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.
Faça login no console do ACK. No painel de navegação à esquerda, clique em console do ACKClusters.
Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Applications > Knative.
-
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.largecom 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.
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 é:
O nó virtual recebe um evento
SpotToBeReleasede invoca a API de Eviction.O servidor de API verifica o PDB configurado para o Pod.
O timestamp de exclusão do Pod é definido e o período de carência começa.
O kubelet no nó virtual inicia o desligamento controlado do Pod.
O plano de controle desassocia o Pod dos Endpoints e EndpointSlices relevantes.
Ao término do período de carência, o kubelet encerra forçadamente o Pod.
O kubelet notifica o sistema para excluir o Pod.
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.