Best Practices für Hochverfügbarkeit mit OpenShift

In diesem Dokument werden Best Practices für die Erzielung von Hochverfügbarkeit (HA) mit Red Hat OpenShift Container Platform-Arbeitslasten in Compute Engine beschrieben. In diesem Dokument werden Strategien auf Anwendungsebene beschrieben, mit denen Sie dafür sorgen können, dass Ihre Arbeitslasten bei Ausfällen hochverfügbar bleiben. Mit diesen Strategien können Sie Single Points of Failure beseitigen und Mechanismen für automatisches Failover und automatische 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 zur Bereitstellung von OpenShift finden Sie in der Red Hat-Dokumentation.

Bereitstellungen auf mehrere Zonen verteilen

Wir empfehlen, OpenShift in mehreren Zonen innerhalb einerGoogle Cloud -Region bereitzustellen. So wird sichergestellt, dass die Knoten der Steuerungsebene des Clusters weiterhin in den anderen Zonen funktionieren, auf die die Bereitstellung verteilt ist, wenn eine Zone ausfällt. Wenn Sie OpenShift in mehreren Zonen bereitstellen möchten, geben Sie in der install-config.yaml-Datei 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, die dafür sorgen, dass die VMs auf verschiedene Fehlerdomains in derselben Zone verteilt werden. Wenn Sie eine Richtlinie für gestreute Platzierung auf Ihre Clusterknoten anwenden, können Sie die Anzahl der Knoten reduzieren, die gleichzeitig von standortspezifischen Störungen betroffen sind. Weitere Informationen zum Erstellen einer Richtlinie für gestreute Platzierung für vorhandene Cluster finden Sie unter Richtlinien für gestreute Platzierung erstellen und auf VMs anwenden.

Um zu verhindern, dass mehrere Pods auf demselben Knoten geplant werden, empfehlen wir, Pod-Anti-Affinitätsregeln zu verwenden. Mit diesen Regeln werden Anwendungsreplikate auf mehrere Zonen verteilt. Das folgende Beispiel zeigt, wie Regeln zur Anti-Affinität von Pods 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, mehrere Pod-Repliken für jeden Dienst oder jede Route auszuführen. So wird sichergestellt, dass der Traffic automatisch an Pods in verfügbaren Zonen weitergeleitet wird.

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

Wir empfehlen, die Last Ihrer Anwendung proaktiv zu verwalten, um eine Überlastung der Ressourcen zu vermeiden. Eine Überbelegung kann zu einer schlechten Dienstleistung unter Last führen. Sie können eine Überbelegung verhindern, indem Sie Ressourcenanfragelimits festlegen. Eine detailliertere Erklärung finden Sie unter Ressourcen für Ihren Pod verwalten. Außerdem können Sie Replikate mithilfe des horizontalen Pod-Autoscalers automatisch auf- oder abskalieren lassen, basierend auf CPU-, Arbeitsspeicher- oder benutzerdefinierten Messwerten.

Außerdem empfehlen wir die folgenden Load-Balancing-Dienste:

  • OpenShift Ingress Operator Der Ingress-Operator stellt HAProxy-basierte Ingress-Controller bereit, um das Routing zu Ihren Pods zu verarbeiten. Wir empfehlen insbesondere, dass Sie den globalen Zugriff für den Ingress-Controller konfigurieren. Dadurch können Clients in jeder Region innerhalb desselben VPC-Netzwerks und derselben Region wie der Load Balancer auf die Arbeitslasten zugreifen, die in Ihrem Cluster ausgeführt werden. Außerdem empfehlen wir, dass Sie Systemdiagnosen für Ingress-Controller implementieren, um den Zustand Ihrer Pods zu überwachen und fehlerhafte Pods neu zu starten.
  • Google Cloud Load-Balancing. Beim Load-Balancing wird der Traffic aufGoogle Cloud Zonen verteilt. Wählen Sie einen Load-Balancer aus, der den Anforderungen Ihrer Anwendung entspricht.

Budget für Pod-Störungen definieren

Wir empfehlen, Unterbrechungsbudgets zu definieren, um die Mindestanzahl an Pods anzugeben, die für Ihre Anwendung während Unterbrechungen wie Wartungsereignissen oder Updates verfügbar sein müssen. Im folgenden Beispiel sehen Sie, wie ein Unterbrechungsbudget 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 HA und Datenreplikation unterstützt

Für zustandsorientierte 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 zugehörigen Treiber in Ihrem Cluster:

Der CSI Persistent Disk-Operator stellt eine Speicherklasse bereit, mit der Sie 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 namens 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 über Zonen hinweg.
  • Eine Datenbank mit dem Namen mydatabase wird mit einem Nutzer myuser initialisiert, dessen Anmeldedaten in einem Kubernetes-Secret namens my-database-secret gespeichert sind.
  • Der Superuser-Zugriff ist aus Sicherheitsgründen deaktiviert.
  • 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 freigegebene In-Memory-Speicher (z. B. Redis) oder persistente Datenspeicher (z. B. Postgres, MySQL) zu verschieben, die für den HA-Modus konfiguriert sind.

Zusammenfassung der Best Practices

Zusammenfassend lässt sich sagen, dass Sie die folgenden Best Practices implementieren sollten, um mit OpenShift eine hohe Verfügbarkeit zu erreichen:

  • Bereitstellungen auf mehrere Zonen verteilen
  • Last proaktiv verwalten, um eine Überlastung von Ressourcen zu vermeiden
  • Budget für Pod-Störungen definieren
  • HA-Datenreplikationsfunktionen verwenden
  • Anwendungsstatus externalisieren

Nächste Schritte