Aumentar a disponibilidade do app com estado usando o operador de alta disponibilidade com estado

Autopilot Padrão

O operador de alta disponibilidade (HA, na sigla em inglês) com estado permite usar a integração integrada do GKE com o Persistent Disk regional para automatizar e controlar a velocidade do failover de pod StatefulSet. Durante o failover, o operador processa automaticamente a detecção de falhas no nó, desconectando um volume de um nó com falha e garantindo a anexação do volume seguro ao nó de failover.

Por que usar o operador de alta disponibilidade com estado

Uma arquitetura com estado comum para garantir alta disponibilidade usa Persistent Disks regionais como camada de armazenamento. Esses discos oferecem uma replicação síncrona de dados entre duas zonas em uma região. Durante falhas de rede em nó ou zona, essa arquitetura permite que suas réplicas de failover das cargas de trabalho (por anexação forçada) sejam armazenadas em outro nó, em uma zona diferente.

O operador de alta disponibilidade com estado permite fazer as seguintes otimizações:

Melhoria no tempo de recuperação dos aplicativos de réplica única: se você usar apenas uma réplica, poderá usar o operador de alta disponibilidade com estado e trocar o armazenamento zonal pelo armazenamento regional quando o aplicativo for provisionado, para aumentar a durabilidade e a disponibilidade dos dados em caso de falha do nó.
Reduza os custos de rede entre zonas: pode custar caro fazer a replicação de dados em várias zonas para aplicativos de alta capacidade. É possível usar o operador de alta disponibilidade com estado para executar o aplicativo em uma única zona, mantendo um caminho de failover para uma zona alternativa que se ajuste ao SLA do aplicativo.

Limitações

Com uma arquitetura de operador de alta disponibilidade com estado de réplica única, o GKE mantém seus dados em duas zonas por meio do Persistent Disk regional, mas os dados só serão acessíveis enquanto a réplica do aplicativo estiver íntegra. Durante um failover, seu aplicativo ficará temporariamente indisponível enquanto a réplica estiver sendo reprogramada para um novo nó íntegro. Se o aplicativo tiver um objetivo do tempo de recuperação (RTO, na sigla em inglês) muito baixo, recomendamos o uso de uma abordagem de várias réplicas.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Requisitos

Os nós e o plano de controle do cluster precisam estar executando o GKE versão 1.28 ou mais recente.
Quando você usa o operador de alta disponibilidade com estado, ele configura automaticamente seu StatefulSet vinculado para usar Persistent Disks regionais. No entanto, você é responsável por garantir que os pods sejam configurados para usar esses discos e possam ser executados em todas as zonas associadas ao armazenamento subjacente.
Certifique-se de que seu aplicativo seja executado em formatos de máquina compatíveis com o Persistent Disk regional: E2, N1, N2, N2D.
Verifique se o driver CSI do Persistent Disk do Compute Engineestá ativado. O driver CSI do Persistent Disk está ativado por padrão nos novos clusters do Autopilot e Padrão e não pode ser desativado ou editado ao usar o Autopilot. Se você precisar adicionar manualmente o driver CSI do Persistent Disk a partir do cluster, consulte Como ativar o driver CSI do Persistent Disk em um cluster atual.
Se você estiver usando um StorageClass personalizado, configure o driver CSI do Persistent Disk com o provisionador pd.csi.storage.gke.io e estes parâmetros:
- availability-class: regional-hard-failover
- replication-type: regional-pd

Configurar e usar o operador de alta disponibilidade com estado

Siga estas etapas para configurar o operador de alta disponibilidade com estado para suas cargas de trabalho com estado:

Ative o complemento StatefulHA.
Instale um recurso HighAvailabilityApplication.
Instale um StatefulSet.
Inspecione o recurso HighAvailabilityApplication.

Ativar o complemento `StatefulHA`

Para usar o operador de alta disponibilidade com estado, o complemento StatefulHA precisa estar ativado no cluster.

Clusters do Autopilot: o GKE ativa automaticamente o complemento StatefulHA na criação do cluster. Se você quiser usar o operador de alta disponibilidade com estado em uma carga de trabalho atual, reimplante-a em um novo cluster do Autopilot.
Clusters padrão:
- Criação de novo cluster: siga as instruções da gcloud CLI para criar um cluster padrão e adicione a seguinte sinalização: --add-on=StatefulHA.
- Cluster padrão existente: siga as instruções da gcloud CLI para atualizar as configurações de um cluster padrão e use a seguinte sinalização para ativar o complemento: --update-addons=StatefulHA=ENABLED`.

O GKE instala automaticamente um StorageClass chamado standard-rwo-regional quando o complemento está ativado.

Instalar um recurso HighAvailabilityApplication

HighAvailabilityApplication é um recurso do Kubernetes que simplifica as configurações do StatefulSet e aumenta a disponibilidade do pod no GKE. O operador de alta disponibilidade com estado reconcilia recursos HighAvailabilityApplication no GKE.

Na especificação HighAvailabilityApplication, defina HighAvailabilityApplication.spec.resourceSelection.resourceKind como StatefulSet.

Para saber como configurar o recurso HighAvailability, consulte a documentação de referência do HighAvailabilityApplication.

Confira o exemplo a seguir para o PostgreSQL:

Salve o manifesto a seguir em um arquivo chamado stateful-ha-example-resource.yaml:
```
kind: HighAvailabilityApplication
apiVersion: ha.gke.io/v1
metadata:
  name: APP_NAME
  namespace: APP_NAMESPACE
spec:
  resourceSelection:
    resourceKind: StatefulSet
  policy:
    storageSettings:
      requireRegionalStorage: true
    failoverSettings:
      forceDeleteStrategy: AfterNodeUnreachable
      afterNodeUnreachable:
        afterNodeUnreachableSeconds: 20
```
Substitua:
- APP_NAME: o nome de um aplicativo no cluster que você quer proteger. Esse nome precisa ser compartilhado pelo HighAvailabilityApplication e pelo StatefulSet.
- APP_NAMESPACE: o namespace do aplicativo. Esse namespace precisa ser compartilhado pelo HighAvailabilityApplication e pelo StatefulSet que estejam sendo protegidos.
Neste exemplo:
- HighAvailabilityApplication.spec.policy.storageSettings.requireRegionalSettings, definida como true. Isso aplica o armazenamento regional.
- HighAvailabilityApplication.spec.policy.failoverSettings, definida como AfterNodeUnreachable. Isso determina como a exclusão forçada é acionada em caso de falha do nó.
- HighAvailabilityApplication.spec.policy.failoverSettings.afterNodeUnreachable, definida como 20. Esse é o tempo limite para forçar a exclusão de um pod depois que o nó em que ele está sendo executado é marcado como inacessível.
Crie o recurso. O recurso HighAvailabilityApplication identifica um StatefulSet com namespace e nome correspondentes.
```
kubectl apply -f stateful-ha-example-resource.yaml
```

Instalar um StatefulSet

Instale um StatefulSet. Por exemplo, é possível instalar um StatefulSet do PostgreSQL usando o Helm (o Helm vem pré-instalado com o Cloud Shell):

helm install postgresql oci://registry-1.docker.io/bitnamicharts/postgresql \
  --namespace=APP_NAMESPACE \
  --set fullnameOverride=APP_NAME

O recurso HighAvailabilityApplication modifica automaticamente o StorageClass do StatefulSet para standard-rwo-regional, que usa o Persistent Disk regional.

Inspecionar o recurso HighAvailabilityApplication

Execute o comando a seguir para verificar se o failover automático está ativado no aplicativo de exemplo:

kubectl describe highavailabilityapplication APP_NAME

A saída será assim:

Status:
Conditions:
  Last Transition Time:  2023-08-09T23:59:52Z
  Message:               Application is protected
  Observed Generation:   1
  Reason:                ApplicationProtected
  Status:                True
  Type:                  Protected