Best Practices für Hochverfügbarkeit

In diesem Dokument werden Best Practices beschrieben, um mit Red Hat OpenShift Container Platform -Arbeitslasten in Compute Engine eine hohe Verfügbarkeit zu erreichen. Der Schwerpunkt liegt auf Strategien auf Anwendungsebene, mit denen Sie sicherstellen können, dass Ihre Arbeitslasten bei Ausfällen hochverfügbar bleiben. Mit diesen Strategien können Sie Single Points of Failure vermeiden und Mechanismen für automatisches Failover und Wiederherstellung implementieren.

Dieses Dokument richtet sich an Plattform- und Anwendungsarchitekten und setzt voraus, dass Sie bereits Erfahrung mit der Bereitstellung von OpenShift haben. Weitere Informationen zum Bereitstellen von OpenShift finden Sie in der Red Hat-Dokumentation.

Das Dokument ist Teil einer Reihe, in der es um Strategien auf Anwendungsebene geht, mit denen Sie sicherstellen, dass Ihre Arbeitslasten hochverfügbar bleiben und sich nach einem Ausfall schnell wiederherstellen lassen. Dokumente in dieser Reihe:

Bereitstellungen auf mehrere Zonen verteilen

Wir empfehlen, OpenShift in mehreren Zonen innerhalb einer Google Cloud Region bereitzustellen. So wird sichergestellt, dass die Knoten der Steuerungsebene des Clusters auch dann funktionieren, wenn es in einer Zone zu einem Ausfall kommt. Wenn Sie OpenShift in mehreren Zonen bereitstellen möchten, geben Sie in der install-config.yamlDatei eine Liste von Google Cloud Zonen aus derselben Region an.

Für eine detaillierte Steuerung der Standorte, an denen Knoten bereitgestellt werden, empfehlen wir , VM-Platzierungsrichtlinien zu definieren. So wird sichergestellt, dass die VMs auf verschiedene Fehlerdomains in derselben Zone verteilt werden. Wenn Sie eine Richtlinie für verteilte Platzierung auf Ihre Clusterknoten anwenden, wird die Anzahl der Knoten reduziert, die gleichzeitig von standortspezifischen Störungen betroffen sind. Weitere Informationen zum Erstellen einer Richtlinie für verteilte Platzierung für vorhandene Cluster finden Sie unter Richtlinien für verteilte Platzierung erstellen und auf VMs anwenden.

Um zu verhindern, dass mehrere Pods auf demselben Knoten geplant werden, empfehlen wir außerdem, Regeln für Pod-Anti-Affinität zu verwenden. Mit diesen Regeln werden Anwendungsreplikate auf mehrere Zonen verteilt. Das folgende Beispiel zeigt, wie Regeln für Pod-Anti-Affinität implementiert werden:

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

Für zustandslose Dienste wie Web-Front-Ends oder REST APIs empfehlen wir, dass Sie mehrere Pod-Replikate für jeden Dienst oder jede Route ausführen. So wird sichergestellt, dass der Traffic automatisch an Pods in verfügbaren Zonen weitergeleitet wird.

Last proaktiv verwalten, um eine Überlastung der Ressourcen zu vermeiden

Wir empfehlen, die Last Ihrer Anwendung proaktiv zu verwalten, um eine Überlastung der Ressourcen zu vermeiden. Eine Überlastung kann zu einer schlechten Dienstleistung unter Last führen. Sie können eine Überlastung vermeiden, indem Sie Grenzwerte für Ressourcenanfragen festlegen. Eine detailliertere Erklärung finden Sie unter Ressourcen für Ihren Pod verwalten. Außerdem können Sie Replikate mit dem horizontalen Pod-Autoscaler automatisch anhand von CPU-, Arbeitsspeicher- oder benutzerdefinierten Messwerten hoch- oder herunterskalieren.

Wir empfehlen außerdem, die folgenden Load-Balancing-Dienste zu verwenden:

Budgets für Pod-Störungen definieren

Wir empfehlen, Budgets für Störungen zu definieren, um die Mindestanzahl von Pods anzugeben, die für Ihre Anwendung bei Störungen wie Wartungsereignissen oder Updates verfügbar sein müssen. Das folgende Beispiel zeigt, wie ein Budget für Störungen definiert wird:

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

Weitere Informationen finden Sie unter Unterbrechungsbudget für Ihre Anwendung festlegen.

Speicher verwenden, der Hochverfügbarkeit und Datenreplikation unterstützt

Für zustandsbehaftete Arbeitslasten, die eine dauerhafte Datenspeicherung außerhalb von Containern erfordern, empfehlen wir die folgenden Best Practices.

Best Practices für Laufwerke

Wenn Sie Festplattenspeicher benötigen, verwenden Sie eine der folgenden Optionen:

Nachdem Sie eine Speicheroption ausgewählt haben, installieren Sie den entsprechenden Treiber in Ihrem Cluster:

Der CSI-Operator für nichtflüchtigen Speicher bietet eine Speicherklasse, mit der Sie Ansprüche auf nichtflüchtige Volumes (PersistentVolumeClaims, PVCs) erstellen können. Für Filestore müssen Sie die Filestore-Speicherklasse erstellen.

Best Practices für Datenbanken

Wenn Sie eine Datenbank benötigen, verwenden Sie eine der folgenden Optionen:

Nachdem Sie den Datenbankoperator installiert haben, konfigurieren Sie einen Cluster mit mehreren Instanzen. Das folgende Beispiel zeigt die Konfiguration für einen Cluster mit den folgenden Attributen:

  • Ein PostgreSQL-Cluster mit dem Namen my-postgres-cluster wird mit drei Instanzen für Hochverfügbarkeit erstellt.
  • Der Cluster verwendet die Speicherklasse regionalpd-balanced für dauerhaften und replizierten Speicher in mehreren Zonen.
  • Eine Datenbank mit dem Namen mydatabase wird mit einem Nutzer myuser initialisiert, dessen Anmeldedaten in einem Kubernetes-Secret mit dem Namen my-database-secret gespeichert sind.
  • Der Superuser-Zugriff ist aus Sicherheitsgründen deaktiviert.
  • Das Monitoring ist für den Cluster aktiviert.
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"

Anwendungsstatus externalisieren

Wir empfehlen, den Sitzungsstatus oder das Caching in gemeinsam genutzte In-Memory-Speicher (z. B. Redis) oder dauerhafte Datenspeicher (z. B. Postgres, MySQL) zu verschieben, die für den HA-Modus konfiguriert sind.

Zusammenfassung der Best Practices

Implementieren Sie die folgenden Best Practices, um mit OpenShift eine hohe Verfügbarkeit zu erreichen:

  • Bereitstellungen auf mehrere Zonen verteilen
  • Last proaktiv verwalten, um eine Überlastung der Ressourcen zu vermeiden
  • Budgets für Pod-Störungen definieren
  • Funktionen zur Datenreplikation für Hochverfügbarkeit verwenden
  • Anwendungsstatus externalisieren

Nächste Schritte