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 da plataforma de contêineres Red Hat OpenShift no Compute Engine. Este documento 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 ocorrem falhas. Essas estratégias ajudam a eliminar pontos únicos de falha e implementar mecanismos de failover e recuperação automática.

Este documento é destinado a arquitetos de plataforma e de aplicativos e presume 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.

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 passar por 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 arquivo install-config.yaml.

Para ter controle detalhado 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. A aplicação de uma política de posicionamento espalhada nos nós do cluster ajuda a reduzir o número de nós que são simultaneamente afetados por interrupções específicas do local. Para mais informações sobre como criar uma política de propagação para clusters existentes, 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 o uso de regras de antiafinidade de pods. Essas regras distribuem as réplicas do aplicativo 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 nas zonas disponíveis.

Gerenciar a carga de forma proativa para evitar o comprometimento excessivo de recursos

Recomendamos que você gerencie proativamente a carga do aplicativo para evitar o comprometimento excessivo de recursos. O compromisso excessivo pode levar a um desempenho ruim do serviço sob carga. Para evitar o compromisso excessivo, defina limites de solicitação de recursos. Para uma explicação mais detalhada, consulte Gerenciar recursos do pod. Além disso, é possível aumentar ou diminuir o número de réplicas com base na CPU, na memória ou em métricas personalizadas usando o escalonador automático de pod horizontal.

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. Especificamente, recomendamos que você configure o acesso global para o controlador de Ingress, que permite que clientes em qualquer região na mesma rede e região da VPC do balanceador de carga acessem os workloads em execução no cluster. Além disso, recomendamos que você implemente verificações de integridade do controlador de ingress para monitorar a integridade dos pods e reiniciar os pods com falhas.
  • 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 o aplicativo precisa para 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 com suporte a HA e replicação de dados

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

Práticas recomendadas para discos

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:

Por fim, defina um StorageClass para o disco:

O exemplo a seguir mostra como definir um StorageClass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-balanced
provisioner: PROVISIONER
parameters:
  type: DISK-TYPE
  replication-type: REPLICATION-TYPE
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values:
          - europe-west1-b
          - europe-west1-a

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 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 todas as 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 que você mova o estado da sessão ou o armazenamento em cache para armazenamentos compartilhados na memória (por exemplo, Redis) ou armazenamentos de dados persistentes (por exemplo, Postgres, MySQL) configurados para execução no modo 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 forma proativa para evitar o comprometimento excessivo 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