Práticas recomendadas para alta disponibilidade

Este documento descreve as práticas recomendadas para alcançar alta disponibilidade (HA) com cargas de trabalho do Red Hat OpenShift Container Platform no Compute Engine. Ele se concentra em estratégias no nível do aplicativo para ajudar a garantir que as cargas de trabalho permaneçam altamente disponíveis quando ocorrerem falhas. Essas estratégias ajudam a eliminar pontos únicos de falha e implementar mecanismos de failover e recuperação automáticos.

Este documento é destinado a arquitetos de plataforma e aplicativos e pressupõe que você tenha alguma experiência na implantação do OpenShift. Para mais informações sobre como implantar o OpenShift, consulte a documentação do Red Hat.

Este documento faz parte de uma série que se concentra nas estratégias no nível do aplicativo que garantem que as cargas de trabalho permaneçam altamente disponíveis e possam ser recuperadas rapidamente em caso de falhas. Os documentos desta série são os seguintes:

Distribuir implantações em várias zonas

Recomendamos que você implante o OpenShift em várias zonas de uma Google Cloud região. Essa abordagem ajuda a garantir que, se uma zona sofrer uma interrupção, os nós do plano de controle do cluster continuem funcionando nas outras zonas em que a implantação está distribuída. Para implantar o OpenShift em várias zonas, especifique uma lista de Google Cloud zonas da mesma região no seu install-config.yaml arquivo.

Para um controle refinado sobre os locais em que os nós são implantados, nós recomendamos definir políticas de posicionamento de VMs, que garantem que as VMs sejam distribuídas em diferentes domínios de falha na mesma zona. A aplicação de uma política de posicionamento distribuído aos nós do cluster ajuda a reduzir o número de nós que são afetados simultaneamente por interrupções específicas do local. Para mais informações sobre como criar uma política de distribuição para clusters atuais, consulte Criar e aplicar políticas de posicionamento distribuído a VMs.

Da mesma forma, para evitar que vários pods sejam programados no mesmo nó, nós recomendamos que você use regras de antiafinidade de pods. Essas regras distribuem réplicas de aplicativos em várias zonas. O exemplo a seguir demonstra como implementar regras de antiafinidade de pods:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

Para serviços sem estado, como front-ends da Web ou APIs REST, recomendamos que você execute várias réplicas de pod para cada serviço ou rota. Essa abordagem garante que o tráfego seja roteado automaticamente para pods em zonas disponíveis.

Gerenciar a carga de maneira proativa para evitar o excesso de recursos

Recomendamos que você gerencie de maneira proativa a carga do aplicativo para evitar o excesso de recursos. O excesso de recursos pode levar a um desempenho ruim do serviço sob carga. Você pode ajudar a evitar o excesso de recursos definindo limites de solicitação de recursos. Para uma explicação mais detalhada, consulte Como gerenciar recursos para seu pod. Além disso, é possível escalonar automaticamente as réplicas para cima ou para baixo com base na CPU, na memória ou em métricas personalizadas usando o escalonador automático de pods horizontal.

Também recomendamos o uso dos seguintes serviços de balanceamento de carga:

  • Operador de entrada do OpenShift. O operador de entrada implanta controladores de entrada baseados em HAProxy para processar o roteamento para seus pods. Especificamente, recomendamos que você configure o acesso global para o controlador de entrada, o que permite que clientes em qualquer região na mesma rede VPC e região que o balanceador de carga alcancem as cargas de trabalho em execução no cluster. Além disso, recomendamos que você implemente verificações de integridade do controlador de entrada para monitorar a integridade dos pods e reiniciar os pods com falha.
  • Google Cloud Balanceamento de carga. O balanceamento de carga distribui o tráfego entre as Google Cloud zonas. Escolha um balanceador de carga que atenda às necessidades do seu aplicativo.

Definir orçamentos de interrupção de pods

Recomendamos que você defina orçamentos de interrupção para especificar o número mínimo de pods que seu aplicativo precisa estar disponível durante interrupções, como eventos de manutenção ou atualizações. O exemplo a seguir mostra como definir um orçamento de interrupção:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Para mais informações, consulte Como especificar um orçamento de interrupção para seu aplicativo.

Usar armazenamento que ofereça suporte à HA e replicação de dados

Para cargas de trabalho com estado que exigem armazenamento de dados persistente fora dos contêineres, recomendamos as seguintes práticas recomendadas.

Práticas recomendadas para disco

Se você precisar de armazenamento em disco, use uma das seguintes opções:

Depois de selecionar uma opção de armazenamento, instale o driver no cluster:

O operador CSI Persistent Disk fornece uma classe de armazenamento que pode ser usada para criar declarações de volume permanente (PVCs, na sigla em inglês). Para o Filestore, é necessário criar a classe de armazenamento do Filestore.

Práticas recomendadas para banco de dados

Se você precisar de um banco de dados, use uma das seguintes opções:

Depois de instalar o operador do banco de dados, configure um cluster com várias instâncias. O exemplo a seguir mostra a configuração de um cluster com os seguintes atributos:

  • Um cluster do PostgreSQL chamado my-postgres-cluster é criado com três instâncias para alta disponibilidade.
  • O cluster usa a classe de armazenamento regionalpd-balanced para armazenamento durável e replicado em várias zonas.
  • Um banco de dados chamado mydatabase é inicializado com um usuário myuser, cujas credenciais são armazenadas em um secret do Kubernetes chamado my-database-secret.
  • O acesso de superusuário está desativado para maior segurança.
  • O monitoramento está ativado para o cluster.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

Externalizar o estado do aplicativo

Recomendamos que você mova o estado da sessão ou o armazenamento em cache para lojas compartilhadas na memória (por exemplo, Redis) ou datastores persistentes (por exemplo, Postgres, MySQL) configurados para serem executados no modo de HA.

Resumo das práticas recomendadas

Em resumo, implemente as seguintes práticas recomendadas para alcançar alta disponibilidade com o OpenShift:

  • Distribuir implantações em várias zonas
  • Gerenciar a carga de maneira proativa para evitar o excesso de recursos
  • Definir orçamentos de interrupção de pods
  • Usar recursos de replicação de dados de HA
  • Externalizar o estado do aplicativo

A seguir