Best practice per l'alta affidabilità con OpenShift

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 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 ripristino automatici.

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

Distribuire i deployment in più zone

Ti consigliamo di eseguire il deployment di OpenShift in più zone all'interno di una regioneGoogle Cloud . 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 è distribuita l'implementazione. Per eseguire il deployment di OpenShift in più zone, specifica un elenco di zone Google Cloud della stessa regione nel file install-config.yaml.

Per un controllo granulare delle posizioni in cui vengono implementati i nodi, ti consigliamo di definire policy di posizionamento delle VM che garantiscano la distribuzione delle VM in domini di errore diversi nella stessa zona. L'applicazione di una policy di posizionamento distribuito ai nodi del cluster contribuisce a ridurre il numero di nodi interessati contemporaneamente da interruzioni specifiche della località. Per saperne di più su come creare una policy di distribuzione per i cluster esistenti, consulta Crea e applica 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 dell'applicazione su più zone. Il seguente esempio 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 di 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 l'overcommitment delle risorse

Ti consigliamo di gestire in modo proattivo il carico della tua applicazione per evitare un eccessivo utilizzo delle risorse. L'overcommitment può comportare prestazioni scadenti del servizio sotto carico. Puoi contribuire a evitare un impegno eccessivo impostando limiti di richiesta di risorse. Per una spiegazione più dettagliata, consulta Gestione delle risorse per il pod. Inoltre, puoi aumentare o diminuire automaticamente le repliche in base alla CPU, alla memoria o alle 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 ingresso OpenShift. L'operatore Ingress esegue il deployment di controller Ingress basati su HAProxy per gestire il routing ai tuoi 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 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 Ingress per monitorare l'integrità dei pod e riavviare quelli non integri.
  • Google Cloud Bilanciamento del carico. Il bilanciamento del carico distribuisce il traffico tra le zoneGoogle Cloud . 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 richiesti dalla tua applicazione per essere disponibili durante interruzioni come eventi di manutenzione o aggiornamenti. Il seguente esempio 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, vedi Specifica di un budget di interruzione per l'applicazione.

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

Per i workload stateful che richiedono l'archiviazione permanente dei dati al di fuori dei container, 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 CSI Persistent Disk fornisce una classe di archiviazione che puoi utilizzare per creare richieste di volumi permanenti (PVC). Per Filestore, devi creare la classe di archiviazione Filestore.

Best practice per i database

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

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 disponibilità.
  • 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 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"

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:

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

Passaggi successivi