Práticas recomendadas para alta disponibilidade com o OpenShift

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. Este documento se concentra em estratégias no nível do aplicativo para ajudar você a garantir que suas 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 da Red Hat.

Espalhar implantações por várias zonas

Recomendamos implantar o OpenShift em várias zonas de uma regiãoGoogle Cloud . 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 zonas Google Cloud da mesma região no seu arquivoinstall-config.yaml.

Para um controle refinado sobre os locais em que os nós são implantados, recomendamos definir políticas de posicionamento de VM que garantam que as VMs sejam distribuídas em diferentes domínios de falha na mesma zona. Aplicar uma política de posicionamento expandido aos nós do cluster ajuda a reduzir o número de nós 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 às VMs.

Da mesma forma, para evitar que vários pods sejam programados no mesmo nó, recomendamos usar 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 pod:

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 forma proativa para evitar o excesso de alocação de recursos

Recomendamos que você gerencie proativamente a carga do aplicativo para evitar o excesso de uso de recursos. O excesso de capacidade pode levar a um desempenho ruim do serviço sob carga. Para evitar o excesso de compromisso, defina limites de solicitação de recursos. Para uma explicação mais detalhada, consulte 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 horizontal de pods.

Também recomendamos que você use os 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. Recomendamos que você configure o acesso global para o controlador de entrada, o que permite que clientes em qualquer região na mesma rede e região da VPC 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 seus pods e reiniciar os que estão falhando.
  • Google Cloud Balanceamento de carga. O balanceamento de carga distribui o tráfego entre 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.

Use armazenamento que ofereça suporte a alta disponibilidade e replicação de dados

Para cargas de trabalho com estado que exigem armazenamento de dados persistentes 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 dela no cluster:

O operador de disco permanente do CSI fornece uma classe de armazenamento que pode ser usada para criar reivindicações de volume permanente (PVCs). Para o Filestore, é preciso criar a classe de armazenamento do Filestore.

Práticas recomendadas para bancos de dados

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

Depois de instalar o operador de 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 aumentar a 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 mover o estado da sessão ou o armazenamento em cache para armazenamentos compartilhados na memória (por exemplo, Redis) ou armazenamentos de dados permanentes (por exemplo, Postgres, MySQL) configurados para serem executados no modo de alta disponibilidade.

Resumo das práticas recomendadas

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

  • Espalhar implantações por várias zonas
  • Gerenciar a carga de forma proativa para evitar o excesso de alocação de recursos
  • Definir orçamentos de interrupção de pods
  • Usar recursos de replicação de dados de alta disponibilidade
  • Externalizar o estado do aplicativo

A seguir