Best Practices für Hochverfügbarkeit mit OpenShift

In diesem Dokument werden Best Practices beschrieben, mit denen Sie eine hohe Verfügbarkeit (High Availability, HA) mit Red Hat OpenShift Container Platform-Arbeitslasten in der Compute Engine erreichen. In diesem Dokument liegt der Schwerpunkt auf Strategien auf Anwendungsebene, mit denen Sie dafür sorgen können, dass Ihre Arbeitslasten bei Ausfällen hoch verfügbar bleiben. Mit diesen Strategien können Sie Single Points of Failure beseitigen 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 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 in den anderen Zonen, in denen die Bereitstellung verteilt ist, weiter funktionieren, wenn eine Zone ausfällt. Wenn Sie OpenShift über mehrere Zonen hinweg bereitstellen möchten, geben Sie in der install-config.yaml-Datei eine Liste der 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 in verschiedenen Ausfalldomains in derselben Zone verteilt werden. Wenn Sie eine Richtlinie für die gestreute 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 die verteilte Platzierung für vorhandene Cluster finden Sie unter Richtlinien für verteilte Platzierung erstellen und auf VMs anwenden.

Ebenso empfehlen wir die Verwendung von Pod-Anti-Affinitätsregeln, um zu verhindern, dass mehrere Pods auf demselben Knoten geplant werden. Mit diesen Regeln werden Anwendungsrepliken auf mehrere Zonen verteilt. Das folgende Beispiel zeigt, wie Sie Pod-Antiaffinitätsregeln implementieren:

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-Frontends oder REST APIs empfehlen wir, für jeden Dienst oder jede Route mehrere Pod-Replikate auszuführen. So wird sichergestellt, dass Traffic automatisch an Pods in verfügbaren Zonen weitergeleitet wird.

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

Wir empfehlen, die Auslastung Ihrer Anwendung proaktiv zu verwalten, um eine Überbeanspruchung der Ressourcen zu vermeiden. Eine zu hohe Auslastung kann zu einer schlechten Dienstleistung führen. Sie können eine Überbuchung verhindern, indem Sie Limits für Ressourcenanfragen festlegen. Eine ausführlichere Erklärung finden Sie unter Ressourcen für Ihren Pod verwalten. Außerdem können Sie mit dem horizontalen Pod-Autoscaler Replikat automatisch basierend auf CPU, Arbeitsspeicher oder benutzerdefinierten Messwerten hoch- oder herunterskalieren.

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

Budgets für Pod-Störungen definieren

Wir empfehlen, Unterbrechungsbudgets zu definieren, um die Mindestanzahl von Pods anzugeben, die für Ihre Anwendung während Unterbrechungen wie Wartungsereignissen oder Updates verfügbar sein müssen. Im folgenden Beispiel wird gezeigt, wie ein Budget für Unterbrechungen 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 die Datenreplizierung unterstützt

Für zustandsorientierte Arbeitslasten, die einen nichtflüchtigen Datenspeicher außerhalb von Containern erfordern, empfehlen wir die folgenden Best Practices.

Best Practices für Laufwerke

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

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

Legen Sie abschließend eine StorageClass für das Laufwerk fest:

Im folgenden Beispiel wird gezeigt, wie Sie eine StorageClass festlegen:

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 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 über Zonen hinweg.
  • Eine Datenbank namens 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.
  • 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 extern speichern

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 die Ausführung im HA-Modus konfiguriert sind.

Zusammenfassung der Best Practices

Im Folgenden finden Sie eine Zusammenfassung der Best Practices für die Hochverfügbarkeit mit OpenShift:

  • Bereitstellungen auf mehrere Zonen verteilen
  • Last proaktiv verwalten, um eine Überbeanspruchung von Ressourcen zu vermeiden
  • Budgets für Pod-Störungen definieren
  • Funktionen zur HA-Datenreplikation verwenden
  • Anwendungsstatus extern speichern

Nächste Schritte