Best practice per l'alta affidabilità

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

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

Questo documento fa parte di una serie incentrata sulle strategie a livello di applicazione che garantiscono che i tuoi carichi di lavoro rimangano a disponibilità elevata e recuperabili rapidamente in caso di errori. I documenti di questa serie sono i seguenti:

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 a garantire che, se una zona subisce un'interruzione, 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ù zone, specifica un elenco di Google Cloud zone della stessa regione nel tuo install-config.yaml file.

Per un controllo granulare delle località in cui vengono eseguite le VM, ti consigliamo di definire le policy di posizionamento delle VM, che garantiscono che le VM siano distribuite in diversi domini di errore nella stessa zona. L'applicazione di una policy di posizionamento distribuito ai nodi del cluster consente di ridurre il numero di nodi interessati contemporaneamente da interruzioni specifiche della località. Per ulteriori informazioni su come creare una policy di distribuzione per i cluster esistenti, consulta Creare e applicare policy di posizionamento distribuito alle VM.

Allo stesso modo, per impedire la pianificazione di più pod sullo stesso nodo, ti consigliamo di utilizzare le regole di anti-affinità dei pod. Queste regole distribuiscono le repliche delle applicazioni 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 senza stato come i frontend web o le API REST, ti consigliamo di eseguire più repliche dei pod per ogni servizio o route. Questo approccio garantisce che il traffico venga instradato automaticamente ai pod nelle zone disponibili.

Gestisci in modo proattivo il carico per evitare un overcommitment delle risorse

Ti consigliamo di gestire in modo proattivo il carico dell'applicazione per evitare un overcommitment delle risorse. L'overcommitment può comportare un rendimento scadente del servizio sotto carico. Puoi contribuire a prevenire l'overcommitment impostando i limiti delle richieste di risorse. Per una spiegazione più dettagliata, consulta Gestire le risorse per il pod. Inoltre, puoi scalare automaticamente le repliche in orizzontale o in verticale in base alla CPU, alla memoria o alle metriche personalizzate utilizzando la scalabilità automatica orizzontale dei pod.

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

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

Definisci i budget di interruzione dei pod

Ti consigliamo di definire i budget di interruzione per specificare il numero minimo di pod che la tua applicazione richiede per essere disponibile durante le 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 di interruzione per l'applicazione.

Utilizza l'archiviazione che supporta la disponibilità elevata e la replica dei dati

Per i carichi di lavoro con stato che richiedono l'archiviazione permanente dei dati al di fuori dei container, ti 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:

L'operatore del disco permanente CSI fornisce una classe di archiviazione che puoi utilizzare per creare richieste di volumi permanenti (PVC). Per Filestore, devi creare la classe di archiviazione di Filestore.

Best practice per i database

Se hai bisogno di un database, utilizza una delle seguenti opzioni:

Dopo aver installato l'operatore del 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 affidabilità.
  • Il cluster utilizza la classe di archiviazione regionalpd-balanced per l'archiviazione durevole e replicata 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 è disabilitato 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"

Estrai lo stato dell'applicazione

Ti consigliamo di spostare lo stato della sessione o la memorizzazione nella cache in archivi in memoria condivisi (ad esempio Redis) o in 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 l'alta affidabilità con OpenShift:

  • Distribuisci i deployment su più zone
  • Gestisci in modo proattivo il carico per evitare un overcommitment delle risorse
  • Definisci i budget di interruzione dei pod
  • Utilizza le funzionalità di replica dei dati ad alta disponibilità
  • Estrai lo stato dell'applicazione

Passaggi successivi