Best practice per l'alta disponibilità con OpenShift

Questo documento descrive le best practice per ottenere l'alta disponibilità (HA) con i carichi di lavoro della piattaforma di container Red Hat OpenShift su Compute Engine. Questo documento si concentra sulle strategie a livello di applicazione per aiutarti ad assicurarti che i carichi di lavoro rimangano ad alta disponibilità in caso di errori. Queste strategie ti aiutano a eliminare i single point of failure e a implementare meccanismi per il failover e il recupero automatici.

Questo documento è rivolto agli architetti di piattaforme e applicazioni e presuppone che tu abbia una certa esperienza con il deployment di OpenShift. Per ulteriori informazioni su come eseguire il deployment di OpenShift, consulta la documentazione di Red Hat.

Distribuisci i deployment su più zone

Ti consigliamo di eseguire il deployment di OpenShift in più zone all'interno di una Google Cloud regione. Questo approccio contribuisce ad assicurare che, in caso di interruzione del servizio in una zona, i nodi del piano di controllo del cluster continuino a funzionare nelle altre zone in cui è distribuito il deployment. Per eseguire il deployment di OpenShift in più Google Cloud zone della stessa regione nel file install-config.yaml.

Per un controllo granulare delle località in cui vengono implementati i nodi, consigliamo di definire criteri di posizionamento delle VM che garantiscano che le VM siano distribuite in diversi domini di errore nella stessa zona. L'applicazione di un criterio di posizionamento distribuito ai nodi del cluster consente di ridurre il numero di nodi che sono contemporaneamente colpiti da interruzioni specifiche per località. Per saperne di più su come creare un criterio di distribuzione per i cluster esistenti, consulta Creare e applicare criteri di posizionamento della distribuzione alle VM.

Analogamente, per impedire la pianificazione di più pod sullo stesso nodo, consigliamo di utilizzare le regole di anti-affinità dei pod. Queste regole distribuiscono le repliche dell'applicazione su più zone. L'esempio seguente mostra come implementare le regole di anti-affinità dei 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

Per i servizi stateless come i front-end web o le API REST, ti consigliamo di eseguire più repliche del pod per ogni servizio o route. Questo approccio garantisce che il traffico venga indirizzato automaticamente ai pod nelle zone disponibili.

Gestisci in modo proattivo il carico per evitare un impegno eccessivo delle risorse

Ti consigliamo di gestire in modo proattivo il carico dell'applicazione per evitare un impegno eccessivo delle risorse. L'over-commitment può portare a scarse prestazioni del servizio sotto carico. Puoi contribuire a evitare l'overcommit impostando limiti di richiesta di risorse. Per una spiegazione più dettagliata, consulta la sezione sulla gestione delle risorse per il pod. Inoltre, puoi aumentare o diminuire automaticamente le repliche in base a CPU, memoria o metriche personalizzate utilizzando il gestore della scalabilità automatica orizzontale dei pod.

Ti consigliamo inoltre di utilizzare i seguenti servizi di bilanciamento del carico:

  • Operatore di ingressi OpenShift. L'operatore Ingress esegue il deployment di controller ingress basati su HAProxy per gestire il routing ai pod. In particolare, ti consigliamo di configurare l'accesso globale per il controller Ingress, che consente ai client di qualsiasi regione all'interno della stessa rete VPC e della stessa regione del bilanciatore del carico di raggiungere i carichi di lavoro in esecuzione sul tuo cluster. Inoltre, ti consigliamo di implementare i controlli dell'integrità del controller di ingressi per monitorare l'integrità dei pod e riavviare quelli in stato di errore.
  • Google Cloud Bilanciamento del carico. Il bilanciamento del carico distribuisce il traffico tra leGoogle Cloud zone. Scegli un bilanciatore del carico che sia in grado di soddisfare le esigenze della tua applicazione.

Definisci i budget di interruzione dei pod

Ti consigliamo di definire budget per le interruzioni per specificare il numero minimo di pod che la tua applicazione deve avere a disposizione durante interruzioni come eventi di manutenzione o aggiornamenti. L'esempio seguente mostra come definire un budget di interruzione:

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

Per ulteriori informazioni, consulta Specificare un budget per le interruzioni per la tua applicazione.

Utilizza un'unità di archiviazione che supporta l'HA e la replica dei dati

Per i workload stateful che richiedono l'archiviazione di dati permanenti al di fuori dei contenitori, consigliamo le seguenti best practice.

Best practice per i dischi

Se hai bisogno di spazio di archiviazione su disco, utilizza una delle seguenti opzioni:

Dopo aver selezionato un'opzione di archiviazione, installa il relativo driver nel cluster:

Infine, imposta un StorageClass per il disco:

L'esempio seguente mostra come impostare un 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

Best practice per i database

Se hai bisogno di un database, utilizza uno dei seguenti:

Dopo aver installato l'operatore di database, configura un cluster con più istanze. L'esempio seguente mostra la configurazione di un cluster con i seguenti attributi:

  • Viene creato un cluster PostgreSQL denominato my-postgres-cluster con tre istanze per l'alta disponibilità.
  • Il cluster utilizza la classe di archiviazione regionalpd-balanced per lo spazio di archiviazione durevole e replicato tra le zone.
  • Un database denominato mydatabase viene inizializzato con un utente myuser, le cui credenziali sono archiviate in un secret Kubernetes denominato my-database-secret.
  • L'accesso come superutente è disattivato per una maggiore sicurezza.
  • Il monitoraggio è abilitato per il 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"

Esternalizza lo stato dell'applicazione

Ti consigliamo di spostare lo stato della sessione o la memorizzazione nella cache in datastore in memoria condivisi (ad esempio Redis) o datastore permanenti (ad esempio Postgres, MySQL) configurati per l'esecuzione in modalità HA.

Riepilogo delle best practice

In sintesi, implementa le seguenti best practice per ottenere un'alta disponibilità con OpenShift:

  • Distribuisci i deployment su più zone
  • Gestisci in modo proattivo il carico per evitare l'overcommit delle risorse
  • Definisci i budget di interruzione dei pod
  • Utilizzare le funzionalità di replica dei dati HA
  • Esternalizza lo stato dell'applicazione

Passaggi successivi