O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Automatizando o failover de aplicações com estado usando o Trident.

07/01/2026 Colaboradores

PDFs

O recurso de desanexação forçada do Trident permite desanexar automaticamente volumes de nós com problemas em um cluster Kubernetes, evitando a corrupção de dados e garantindo a disponibilidade do aplicativo. Essa funcionalidade é particularmente útil em cenários onde os nós deixam de responder ou são desativados para manutenção.

Detalhes sobre Force Detach

A força de desprendimento está disponível para ontap-san , ontap-san-economy , ontap-nas , e ontap-nas-economy apenas. Antes de habilitar a desconexão forçada, o desligamento não normal do nó (NGNS) deve ser habilitado no cluster do Kubernetes. O NGNS é habilitado por padrão para o Kubernetes 1.28 e superior. Para mais informações, consulte "Kubernetes: Desligamento do nó não gracioso" .

Ao usar o ontap-nas driver ou ontap-nas-economy, você precisa definir o autoExportPolicy parâmetro na configuração de back-end true para que o Trident possa restringir o acesso do nó Kubernetes com a alteração aplicada usando políticas de exportação gerenciadas.

Como o Trident conta COM NGNS do Kubernetes, não remova out-of-service as taints de um nó que não seja saudável até que todos os workloads não toleráveis sejam reprogramados. Aplicar ou remover a taint de forma imprudente pode comprometer a proteção de dados no back-end.

Quando o administrador do cluster do Kubernetes tiver aplicado a node.kubernetes.io/out-of-service=nodeshutdown:NoExecute taint ao nó e enableForceDetach estiver definido como true, o Trident determinará o status do nó e:

Interrompa o acesso de E/S de backend para volumes montados nesse nó.

Marque o objeto do nó Trident como dirty (não é seguro para novas publicações).

O controlador Trident rejeitará novas solicitações de volume de publicação até que o nó seja requalificado (depois de ter sido marcado como dirty) pelo pod de nó do Trident. Quaisquer cargas de trabalho agendadas com um PVC montado (mesmo depois que o nó do cluster estiver pronto e saudável) não serão aceitas até que o Trident possa verificar o nó clean (seguro para novas publicações).

Quando a integridade do nó é restaurada e a taint é removida, o Trident irá:

Identifique e limpe caminhos publicados obsoletos no nó.
Se o nó estiver em um cleanable estado (a tint fora de serviço foi removida e o nó está Ready no estado) e todos os caminhos obsoletos e publicados estiverem limpos, o Trident reajustará o nó como clean e permitirá novos volumes publicados no nó.

Detalhes sobre o failover automático

Você pode automatizar o processo de desacoplamento forçado por meio da integração com"operador de verificação de integridade do nó (NHC)" . Quando ocorre uma falha em um nó, o NHC aciona a remediação de nó Trident (TNR) e a desconexão forçada automaticamente, criando um CR TridentNodeRemediation no namespace do Trident que define o nó com falha. O TNR é criado somente em caso de falha de um nó e removido pelo NHC assim que o nó volta a ficar online ou é excluído.

Falha no processo de remoção do pod do nó

O failover automático seleciona as cargas de trabalho a serem removidas do nó com falha. Quando um TNR é criado, o controlador TNR marca o nó como sujo, impedindo novas publicações de volume e inicia a remoção de pods compatíveis com o recurso de desanexação forçada e seus respectivos volumes anexados.

Todos os volumes/PVCs suportados por desanexação forçada também são suportados por failover automático:

Volumes NAS e NAS-economy usando políticas de exportação automática (SMB ainda não é suportado).
SAN e volumes SAN-economia.

ConsulteDetalhes sobre Force Detach .

Comportamento padrão:

Os pods que utilizam volumes compatíveis com o recurso de desanexação forçada são removidos do nó com falha. O Kubernetes irá reprogramar essas tarefas para um nó saudável.
Os pods que utilizam um volume não suportado pelo force-detach, incluindo volumes que não sejam Trident, não são removidos do nó com falha.
Pods sem estado (não PVCs) não são removidos do nó com falha, a menos que a anotação do pod trident.netapp.io/podRemediationPolicy: delete Está definido.

Substituindo o comportamento de remoção do pod:

O comportamento de remoção de pods pode ser personalizado usando uma anotação de pod: trident.netapp.io/podRemediationPolicy[retain, delete] . Essas anotações são examinadas e utilizadas quando ocorre uma falha de sistema. Aplique anotações à especificação do pod do deployment/replicaset do Kubernetes para evitar que a anotação desapareça após uma falha:

retain- O pod NÃO será removido do nó com falha durante um failover automático.
delete- O Pod será removido do nó com falha durante um failover automático.

Essas anotações podem ser aplicadas a qualquer pod.

As operações de E/S serão bloqueadas apenas em nós com falha para volumes que suportam desanexação forçada.
Para volumes que não suportam desanexação forçada, existe o risco de corrupção de dados e problemas de multi-anexação.

Remediação de nó Trident CR

O CR TridentNodeRemediation (TNR) define um nó com falha. O nome do TNR é o nome do nó com falha.

Exemplo de TNR:

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediation
metadata:
  name: <K8s-node-name>
spec: {}

Estados TNR: Use os seguintes comandos para visualizar o status dos TNRs:
kubectl get tnr <name> -n <trident-namespace>

Os programas TNR (Captura, Esterilização e Devolução) podem ocorrer em um dos seguintes estados:

Remediando:
- Interrompa o acesso de E/S de backend para volumes suportados por desanexação forçada montados nesse nó.
- O objeto de nó Trident está marcado como sujo (não é seguro para novas publicações).
- Remova os pods e os anexos de volume do nó.
Recuperação de nó pendente:
- O controlador está aguardando que o nó volte a ficar online.
- Assim que o nó estiver online, o comando publish-enforcement garantirá que o nó esteja limpo e pronto para novas publicações de volume.
Se o nó for excluído do Kubernetes, o controlador TNR removerá o TNR e interromperá a reconciliação.
Concluído com sucesso:
- Todas as etapas de remediação e recuperação do nó foram concluídas com sucesso. O nó está limpo e pronto para novas publicações de volume.
Fracassado:
- Erro irrecuperável. Os motivos do erro são definidos no campo status.message da solicitação de alteração (CR).

Habilitando o failover automático

Pré-requisitos:

Certifique-se de que a opção de desanexação forçada esteja ativada antes de ativar o failover automático. Para obter mais informações, consulteDetalhes sobre Force Detach .
Instale a verificação de integridade do nó (NHC) no cluster Kubernetes.
- "Instale o operator-sdk".
- Instale o Operator Lifecycle Manager (OLM) no cluster, caso ainda não esteja instalado: operator-sdk olm install .
- Instalar o operador de verificação de integridade do nó: kubectl create -f https://operatorhub.io/install/node-healthcheck-operator.yaml .

Você também pode usar métodos alternativos para detectar falha de nó, conforme especificado na Integrando soluções personalizadas de verificação de integridade de nós seção abaixo.

Ver"Operador de verificação de integridade do nó" para mais informações.

Passos

Crie um CR (Creative Request) NodeHealthCheck (NHC) no namespace Trident para monitorar os nós de trabalho no cluster. Exemplo:

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: <CR name>
spec:
  selector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
      - key: node-role.kubernetes.io/master
        operator: DoesNotExist
  remediationTemplate:
    apiVersion: trident.netapp.io/v1
    kind: TridentNodeRemediationTemplate
    namespace: <Trident installation namespace>
    name: trident-node-remediation-template
  minHealthy: 0 # Trigger force-detach upon one or more node failures
  unhealthyConditions:
    - type: Ready
      status: "False"
      duration: 0s
    - type: Ready
      status: Unknown
      duration: 0s

Aplique o CR de verificação de integridade do nó no trident espaço de nomes.

kubectl apply -f <nhc-cr-file>.yaml -n <trident-namespace>

A CR acima está configurada para monitorar os nós de trabalho do Kubernetes em busca das condições de nó Ready: false e Unknown. O failover automático será acionado quando um nó entrar no estado Ready: false ou Ready: Unknown.

O unhealthyConditions No CR, utiliza-se um período de tolerância de 0 segundos. Isso faz com que o failover automático seja acionado imediatamente após o Kubernetes definir a condição do nó como Ready: false, que é definida depois que o Kubernetes perde o sinal de pulsação de um nó. O Kubernetes tem um tempo de espera padrão de 40 segundos após o último heartbeat antes de definir Ready: false. Esse período de tolerância pode ser personalizado nas opções de implantação do Kubernetes.

Para opções de configuração adicionais, consulte"Documentação do operador Node-Healthcheck" .

Informações adicionais de configuração

Quando o Trident é instalado com o recurso de desanexação forçada ativado, dois recursos adicionais são criados automaticamente no namespace do Trident para facilitar a integração com o NHC: TridentNodeRemediationTemplate (TNRT) e ClusterRole.

TridentNodeRemediationTemplate (TNRT):

O TNRT serve como modelo para o controlador NHC, que usa o TNRT para gerar recursos TNR conforme necessário.

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediationTemplate
metadata:
  name: trident-node-remediation-template
  namespace: trident
spec:
  template:
    spec: {}

Função do Cluster:

Uma função de cluster também é adicionada durante a instalação quando a opção de desanexação forçada está habilitada. Isso concede permissões ao NHC para TNRs no espaço de nomes Trident .

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.ext-remediation/aggregate-to-ext-remediation: "true"
  name: tridentnoderemediation-access
rules:
- apiGroups:
  - trident.netapp.io
  resources:
  - tridentnoderemediationtemplates
  - tridentnoderemediations
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

Atualizações e manutenção de clusters K8s

Para evitar falhas, pause o failover automático durante a manutenção ou atualizações do Kubernetes, períodos em que se espera que os nós sejam desligados ou reinicializados. Você pode pausar o CR do NHC (descrito acima) aplicando um patch em seu CR:

kubectl patch NodeHealthCheck <cr-name> --patch '{"spec":{"pauseRequests":["<description-for-reason-of-pause>"]}}' --type=merge

Isso interrompe o failover automático. Para reativar o failover automático, remova o pauseRequests da especificação após a conclusão da manutenção.

Limitações

As operações de E/S são impedidas apenas nos nós com falha para volumes suportados por desanexação forçada. Somente os pods que utilizam volumes/PVCs compatíveis com a função de desanexação forçada são removidos automaticamente.
O failover automático e o desanexamento forçado são executados dentro do pod do controlador Trident. Se o nó que hospeda o trident-controller falhar, o failover automático será atrasado até que o Kubernetes mova o pod para um nó íntegro.

Integrando soluções personalizadas de verificação de integridade de nós

Você pode substituir o operador de verificação de integridade do nó por ferramentas alternativas de detecção de falhas de nó para acionar o failover automático. Para garantir a compatibilidade com o mecanismo de failover automático, sua solução personalizada deve:

Crie um TNR quando uma falha de nó for detectada, usando o nome do nó com falha como o nome do CR do TNR.
Exclua o TNR quando o nó se recuperar e o TNR estiver no estado "Sucesso".