Container Compute Service:Configure automatic instance rotation for hardware failures

Como funciona

Quando uma instância do ACS passa por manutenção programada de nó ou apresenta uma falha de hardware, como uma GPU danificada, a estabilidade e o desempenho do service podem ser afetados. O componente acs-instance-helper automatiza o tratamento dessas falhas:

1. Monitoramento automático de falhas: O componente monitora continuamente a Condition de falha dos Pods. A infraestrutura subjacente relata esse sinal automaticamente para eventos como falhas de GPU, problemas na máquina host ou manutenções e reinicializações programadas de nós.

2. Alinhamento com janela de manutenção: O componente decide quando agir com base no prazo limite de tratamento de falhas reportado pelo nó subjacente e em uma janela de manutenção opcional. Se o prazo permitir, ele aguarda a janela de manutenção predefinida antes de prosseguir.

3. Atualização de rotação acionada: Para aplicações stateless, como Deployments e CloneSets, o componente utiliza uma estratégia de scale-up online (primeiro escala, depois destrói) para rotacionar os Pods no nó com falha.

   Importante

   Para aplicações não online, o acs-instance-helper realiza o eviction direto dos Pods na instância assim que detecta a condição de falha.

Pré-requisitos

• Seu cluster ACS deve estar na versão 1,28 ou posterior.

• O ACK Virtual Node deve estar instalado na versão v2.16.0 ou posterior. Para mais informações, consulte ACK Virtual Node.

Instale o componente

1. No console do ACS, clique em nome do cluster desejado. No painel de navegação à esquerda, escolha Applications > Helm.

2. Na página Helm, clique em Deploy.

   1. Basic Information: Na caixa de pesquisa Chart, insira acs-instance-helper e selecione-o nos resultados.

   2. Parameters: Em Chart Version, selecione a versão mais recente.

Configure as definições globais do acs-instance-helper (Opcional)

Você também pode configurar uma janela de manutenção e adicionar suporte a tipos personalizados de workload.

apiVersion: v1
kind: ConfigMap
metadata:
  name: acs-instance-helper-global-config
  namespace: kube-system
data:
  customOnlineWorkloads: foo.io/SomeWorkload,bar.io/AnotherWorkload
  hardwareFaultEvictionSeconds: "60"
  maintenanceTime: "2025-10-09T10:00:00+08:00"
  maintenanceDuration: "4h"
  maintenanceWeeklyPeriod: "Saturday,Sunday"
  # maintenanceRecurrence: "FREQ=WEEKLY;BYDAY=SA,SU"  # Maintenance window: every Saturday and Sunday

Expanda a seção abaixo para ver a descrição dos parâmetros.

Parâmetros

Chave	Descrição	Exemplo
customOnlineWorkloads	Classifica um workload como tipo "service online", utilizando a estratégia de scale-up online (escalar primeiro, destruir depois) para rotacionar Pods em nós com falha. Por padrão, o componente suporta o tipo de workload Deployment. Use este parâmetro para adicionar suporte a tipos personalizados de workload. Importante Certifique-se de que seu controlador de workload personalizado consiga manter o número especificado de réplicas (por exemplo, criando novas automaticamente se a contagem estiver baixa). A rotação sem interrupções não é garantida para todos os workloads personalizados. Ao ativar esse recurso para um workload personalizado, teste-o exaustivamente.	foo.io/SomeWorkload,bar.io/AnotherWorkload
hardwareFaultEvictionSeconds	Para services que usam a estratégia "escalar e realizar eviction", este parâmetro define o período de espera (em segundos) entre a conclusão do scale-up e o eviction do Pod na instância com falha. O valor padrão é "300" (5 minutos). O valor deve ser uma string, por exemplo, "60".	"60"
maintenanceTime	Ativa a janela de manutenção para o cluster e define seu horário de início no formato RFC3339. Use um identificador de fuso horário explícito, como +08:00 ou UTC.	2025-10-09T10:00:00+08:00 Declara que a janela de manutenção começa às 10h00 do dia 9 de outubro de 2025 (UTC+8).
maintenanceDuration	Especifique a duração de cada janela de manutenção. Este parâmetro só entra em vigor quando maintenanceTime estiver configurado. O valor deve ser uma string. Formatos como "3", "3h" e "3H" são suportados. O valor padrão é "3", o que significa 3 horas.	"4h"
maintenanceWeeklyPeriod	Define os dias da semana para manutenção. Este parâmetro só entra em vigor quando maintenanceTime estiver configurado. Os valores válidos são Monday, Tuesday, Wednesday, Thursday, Friday, Saturday e Sunday. Separe múltiplos valores com vírgulas. Se este parâmetro for configurado, ele substituirá o valor de maintenanceRecurrence.	Saturday,Sunday
maintenanceRecurrence	Define um cronograma de manutenção personalizado usando a sintaxe de regra de recorrência RFC5545. Este parâmetro só entra em vigor quando maintenanceTime estiver configurado. Atualmente, apenas FREQ=WEEKLY é suportado. Os parâmetros COUNT e UNTIL não são suportados. Se maintenanceWeeklyPeriod também estiver configurado, este parâmetro será ignorado.	FREQ=WEEKLY;BYDAY=SA,SU

O tempo de resolução de falhas depende tanto do prazo limite de tratamento quanto da janela de manutenção configurada. Se houver uma janela de manutenção disponível antes do prazo, o acs-instance-helper prioriza os reparos durante essa janela. Caso o processo não seja concluído dentro de uma única janela, as operações restantes continuam na próxima janela disponível.

Crie e configure um workload

Ative o recurso de tratamento de falhas para seu workload configurando uma annotation.

O recurso de tratamento de falhas executa a rotação tentando repetidamente evictions por meio da Eviction API em vez de excluir diretamente os Pods nas instâncias com falha. Você pode configurar uma política de PodDisruptionBudget (PDB) para controlar a concorrência de evictions e evitar interrupções no service. Para mais informações, consulte Use a PDB to control Pod eviction concurrency .

Simule um cenário de falha

Em produção, a Condition é adicionada automaticamente pelo plano de controle subjacente. Nesta seção, você injeta manualmente uma Condition em um Pod para simular um cenário de falha.

1. Simule a falha: Substitua POD_NAME pelo nome real do seu Pod para injetar uma Condition de falha de hardware.kubectl patch pod POD_NAME --type='merge' --subresource=status -p='{

   "status": {

   "conditions": [

   {

   "type": "Interruption.HardwareFault",

   "status": "True",

   "reason": "MockForTest",

   "message": "Underlying infrastructure issue [Reboot] scheduled at 2099-03-12T09:00:00.000+08:00",

   "lastProbeTime": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'",

   "lastTransitionTime": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"

   }

   ]

   }

   }'

   O prazo limite para tratamento da falha é especificado no campo message .

2. Observe o scale-up: Após injetar a falha, o acs-instance-helper aciona um scale-up de acordo com a maintenance window configuration. Se nenhuma janela estiver configurada, ele aciona o scale-up imediatamente. Um novo Pod é criado e o status do workload original permanece inalterado.

   kubectl get pods -l app=hardware-fault-helper-example

   Saída esperada:

   NAME                                             READY   STATUS    RESTARTS   AGE
   hardware-fault-helper-example-7cf4cf96c5-xxxxx   1/1     Running   0          2m21s
   hardware-fault-helper-example-7cf4cf96c5-yyyyy   1/1     Running   0          36s # The newly scaled-up Pod

3. Verifique o evento de scale-up: Consulte os eventos do Pod com falha. Você deverá ver um evento NewInstanceCreationTriggered, confirmando que o scale-up foi acionado pelo hardware-fault-helper.kubectl describe po POD_NAME

   Saída esperada:

   ...
     Normal  NewInstanceCreationTriggered  62s    hardware-fault-helper  controller default/hardware-fault-helper-example-7cf4cf96c5 (apiVersion:apps/v1, kind:ReplicaSet) will create a new instance

4. Verifique o evento de eviction: Após o período de espera definido em hardwareFaultEvictionSeconds, o Pod com falha é retirado de serviço. Ele entra no estado Terminating antes de ser excluído. Você também pode observar um evento correspondente a essa ação.kubectl describe po POD_NAME

   Saída esperada:

   ...
     Warning  InstanceEvictedGracefully     2s     hardware-fault-helper  pod is deleted due to hardware fault
     Normal   Killing                       1s     kubelet                Stopping container main-container

5. Confirme a recuperação: Por fim, o Pod com falha é completamente substituído, restando apenas o Pod recém-criado.

   kubectl get pods -l app=hardware-fault-helper-example

   Saída esperada:

   NAME                                             READY   STATUS      RESTARTS   AGE
   hardware-fault-helper-example-7cf4cf96c5-yyyyy   1/1     Running     0          5m5s

Faturamento

A instalação do componente acs-instance-helper implanta um Deployment com duas réplicas no seu cluster. Cada réplica consome 1 vCPU e 2 GiB de memória do cluster, o que gerará custos. Para mais informações sobre faturamento, consulte ACS computing power billing.

FAQ

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
  namespace: YOUR_NAMESPACE # Specify the namespace where the policy applies. Defaults to `default` if not specified.
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: app