Práticas recomendadas para alta disponibilidade com o OpenShift

Este documento descreve as práticas recomendadas para alcançar a elevada disponibilidade (HA) com cargas de trabalho da Red Hat OpenShift Container Platform no Compute Engine. Este documento centra-se nas estratégias ao nível da aplicação para ajudar a garantir que as suas cargas de trabalho permanecem altamente disponíveis quando ocorrem falhas. Estas estratégias ajudam a eliminar pontos únicos de falha e a implementar mecanismos de comutação por falha e recuperação automáticas.

Este documento destina-se a arquitetos de plataformas e aplicações e pressupõe que tem alguma experiência na implementação do OpenShift. Para mais informações sobre como implementar o OpenShift, consulte a documentação da Red Hat.

Distribua as implementações por várias zonas

Recomendamos que implemente o OpenShift em várias zonas numa Google Cloud região. Esta abordagem ajuda a garantir que, se uma zona sofrer uma interrupção, os nós do plano de controlo do cluster continuam a funcionar nas outras zonas em que a implementação está distribuída. Para implementar o OpenShift em várias zonas, especifique uma lista de zonas da mesma região no ficheiro install-config.yaml. Google Cloud

Para um controlo detalhado das localizações onde os nós são implementados, recomendamos que defina políticas de posicionamento de VMs que garantam que as VMs estão distribuídas por diferentes domínios de falhas 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 da localização. Para mais informações sobre como criar uma política de distribuição para clusters existentes, consulte o artigo Crie e aplique políticas de posicionamento de distribuição a VMs.

Da mesma forma, para impedir que sejam agendados vários agrupamentos no mesmo nó, recomendamos que use regras de anti-afinidade de agrupamentos. Estas regras distribuem as réplicas da aplicação por várias zonas. O exemplo seguinte 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 interfaces Web ou APIs REST, recomendamos que execute várias réplicas de pods para cada serviço ou rota. Esta abordagem garante que o tráfego é automaticamente encaminhado para pods em zonas disponíveis.

Gerir proativamente a carga para evitar o compromisso excessivo de recursos

Recomendamos que faça a gestão proativa da carga da sua aplicação para evitar o excesso de compromisso de recursos. O excesso de compromisso pode levar a um desempenho fraco do serviço sob carga. Pode ajudar a evitar o compromisso excessivo definindo limites de pedidos de recursos. Para uma explicação mais detalhada, consulte o artigo Gerir recursos para o seu pod. Além disso, pode aumentar ou diminuir automaticamente as réplicas com base na CPU, na memória ou em métricas personalizadas, através da escala automática horizontal de pods.

Também recomendamos que use os seguintes serviços de equilíbrio de carga:

  • Operador de entrada do OpenShift. O operador de entrada implementa controladores de entrada baseados no HAProxy para processar o encaminhamento para os seus pods. Em concreto, recomendamos que configure o acesso global para o controlador de entrada, o que permite que os 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 seu cluster. Além disso, recomendamos que implemente verificações de estado do controlador de entrada para monitorizar o estado dos seus pods e reiniciar os pods com falhas.
  • Google Cloud Balanceamento de carga. O balanceamento de carga distribui o tráfego por Google Cloud zonas. Escolha um balanceador de carga que satisfaça as necessidades da sua aplicação.

Defina orçamentos de interrupção de pods

Recomendamos que defina orçamentos de interrupção para especificar o número mínimo de pods que a sua aplicação requer para estar disponível durante interrupções, como eventos de manutenção ou atualizações. O exemplo seguinte 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 o artigo Especificar um orçamento de interrupção para a sua aplicação.

Use armazenamento que suporte a HA e a replicação de dados

Para cargas de trabalho com estado que requerem armazenamento de dados persistente fora dos contentores, recomendamos as seguintes práticas recomendadas.

Práticas recomendadas para discos

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

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

O operador de disco persistente da CSI fornece uma classe de armazenamento que pode usar para criar reivindicações de volume persistente (PVC). Para o Filestore, tem de criar a classe de armazenamento do Filestore.

Práticas recomendadas para bases de dados

Se precisar de uma base de dados, use uma das seguintes opções:

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

  • É criado um cluster do PostgreSQL denominado my-postgres-cluster com três instâncias para alta disponibilidade.
  • O cluster usa a classe de armazenamento regionalpd-balanced para armazenamento duradouro e replicado em várias zonas.
  • É inicializada uma base de dados denominada mydatabase com um utilizador myuser, cujas credenciais são armazenadas num segredo do Kubernetes denominado my-database-secret.
  • O acesso de superutilizador está desativado para uma maior segurança.
  • A monitorização está ativada 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"

Externalize o estado da aplicação

Recomendamos que mova o estado da sessão ou a colocação em cache para armazenamentos na memória partilhados (por exemplo, Redis) ou armazenamentos de dados persistentes (por exemplo, Postgres, MySQL) configurados para serem executados no modo HA.

Resumo das práticas recomendadas

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

  • Distribua as implementações por várias zonas
  • Gerir proativamente a carga para evitar o compromisso excessivo de recursos
  • Defina orçamentos de interrupção de pods
  • Use funcionalidades de replicação de dados de HA
  • Externalize o estado da aplicação

O que se segue?