Por padrão, o sistema tenta recriar automaticamente um pod baseado em Elastic Container Instance após uma falha na criação. Para obter o resultado da criação rapidamente e tratar a falha o quanto antes, modifique a política de tratamento de falhas do pod.
Descrição da configuração
Pode ocorrer falha na criação de um pod em um nó virtual por insuficiência de recursos. Por padrão, o sistema reagenda os recursos automaticamente e tenta recriar o pod. Adicione a anotação k8s.aliyun.com/eci-fail-strategy para configure a política de tratamento de falhas do pod e especifique se o pod deve ser recriado após uma falha na criação.
As anotações devem ser adicionadas ao bloco de metadata no arquivo de configuração do pod. Por exemplo, ao crie um Deployment, adicione as anotações na seção spec.template.metadata.
As anotações relacionadas ao Elastic Container Instance são aplicadas somente durante a criação do pod. Adicionar ou modifique essas anotações em um pod já existente não terá efeito.
A tabela a seguir descreve os valores válidos da anotação k8s.aliyun.com/eci-fail-strategy.
Valor | Descrição | Cenário |
fail-back | Após uma falha na criação do pod, o sistema tenta recriá-lo automaticamente. O pod permanece no estado Pending até ser recriado com sucesso. Após a recriação, o status do pod muda para o estado Running. | Requer alta taxa de sucesso na criação e é possível aceitar atraso na entrega dos pods. |
fail-over | Os efeitos de fail-over e fail-back são idênticos. | |
fail-fast | Após uma falha na criação do pod, o sistema reporta o erro diretamente. O pod fica no estado ProviderFailed. A camada de orquestração superior determina se o sistema deve tentar recriar o pod ou agendá-lo em um nó real. | Mais indicado para cenários que exigem alta eficiência e entrega ágil de pods, com lógica de tratamento de falhas otimizada. |
Se a anotação
k8s.aliyun.com/eci-fail-strategy: "fail-fast"for adicionada ao metadata no arquivo de configuração de um pod baseado em Elastic Container Instance, o provisioner não suporta o StorageClassWaitForFirstConsumerao montar um volume de disco provisionado dinamicamente no pod.Recomendamos não usar a anotação
k8s.aliyun.com/eci-reschedule-enablepara configurar o reagendamento.
Exemplo de configuração
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
labels:
app: test
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx-test
labels:
app: nginx
alibabacloud.com/eci: "true"
annotations:
k8s.aliyun.com/eci-fail-strategy: "fail-fast" # If a pod fails to be created, the system directly reports an error without attempting to recreate the pod.
k8s.aliyun.com/eci-use-specs: "ecs.c6.large"
spec:
containers:
- name: nginx
image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
ports:
- containerPort: 80No arquivo YAML de exemplo acima, a política de tratamento de falhas do pod é fail-fast. Caso o pod permaneça no estado Pending por um longo período, visualize o pod status.reason.
Se o pod status.reason for ContainerInstanceScheduleFailed, o pod falhou no agendamento. Nesse caso, visualize a condição ContainerInstanceCreated e identifique a causa com base no reason e na message da condição. Em seguida, tome as medidas adequadas, como modifique as especificações do pod e configure múltiplas zonas para crie o pod. Para mais informações, consulte ContainerInstanceCreated.
-
Se o pod status.reason estiver vazio, visualize a condição ContainerInstanceCreated e verifique o status de agendamento com base no valor da condição. Na maioria dos casos, quando a política de tratamento de falhas é fail-fast, o pod status.reason não está vazio.
Se o valor de ContainerInstanceCreated for True, o pod foi agendado com sucesso e ocorreu uma exceção durante a criação do sandbox.
Se o valor de ContainerInstanceCreated for False e o valor de reason não for Creating, o pod falhou no agendamento e é necessário aguardar o reagendamento.
Por exemplo, considere um pod cuja criação falhou por insuficiência de recursos. O código de exemplo a seguir ilustra a condição ContainerInstanceCreated quando a política de tratamento de falhas do pod é fail-fast.
Se a política de tratamento de falhas do pod for fail-back, o sistema reagenda o pod automaticamente após a falha na criação. Nesse caso, o pod status.reason não será ContainerInstanceScheduleFailed. Visualize a condição ContainerInstanceCreated e identifique a causa da falha de agendamento no ciclo atual com base no reason e na message da condição.
{
"conditions": [
{
"lastProbeTime": "2023-03-30T18:11:31Z",
"lastTransitionTime": "2023-03-30T18:11:31Z",
"message": "Create ECI failed because the specified instance is out of stock. %s",
"reason": "ContainerGroup.NoStock",
"status": "False",
"type": "ContainerInstanceCreated"
}
],
"Reason":"ContainerInstanceScheduleFailed",
"phase": "Pending"
}