Entwicklung und Test von Apps im Hinblick auf Ausfallsicherheit

Erfahren Sie, wie Red Hat OpenShift on IBM Cloud die Wartung der Steuerungsebene handhabt, wie sich Wartungsupdates auf laufende Workloads auswirken und wie Sie Ihre Anwendungen auf hohe Ausfallsicherheit testen und auslegen können.

Überblick über die Clusterarchitektur und die Zuständigkeiten

Red Hat OpenShift on IBM Cloud ist ein verwalteter Kubernetes-Service. In jedem Cluster ist die Architektur in zwei Ebenen mit [unterschiedlichen Zuständigkeiten](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service) unterteilt:

Steuerebene
Verwaltet von IBM. Umfasst den Kubernetes-API-Server, etcd, den Controller-Manager und den Scheduler.
Datenebene
Von Ihnen verwaltet. Umfasst Worker-Knoten, Anwendungs-Pods, Speicherkonfigurationen und Netzwerk-Add-ons.
Verantwortungsbereiche für die Steuer- und Datenebene des Clusters
Flugzeug Verwaltet von Komponenten
Steuerebene IBM API-Server, etcd, Controller-Manager, Scheduler
Datenebene Sie Worker-Knoten, Anwendungs-Pods, Speicher, Netzwerk-Add-ons

IBM führt regelmäßig Aktualisierungen der Patch-Versionen für die Steuerungsebene durch. Diese Patches beheben Sicherheitslücken, enthalten wichtige Fehlerbehebungen und stellen sicher, dass die Cluster weiterhin die Sicherheitsanforderungen der IBM erfüllen. Wenn Sie verstehen, wie diese Patches angewendet werden, können Sie fundierte Entscheidungen bezüglich Ihrer Anwendungsarchitektur treffen.

Anwendungen, die in Cloud-Umgebungen ausgeführt werden, sind dynamischen Bedingungen ausgesetzt, darunter vorübergehende Netzwerkstörungen, Wartungsarbeiten an der Hosting-Infrastruktur und Latenzzeiten bei Diensten von Drittanbietern. Die Auslegung und das Testen auf Ausfallsicherheit unter allen Bedingungen gewährleisten zuverlässige Produktions-Workloads.

So wendet IBM Patches für die Steuerungsebene an

Die Komponenten der Steuerungsebene für jeden Red Hat OpenShift on IBM Cloud-Cluster werden in einer hochverfügbaren (HA) Konfiguration betrieben. Mehrere Replikate jeder Komponente sind über unabhängige Verfügbarkeitszonen verteilt, sodass innerhalb der Steuerungsebene kein einzelner Ausfallpunkt existiert.

Wenn ein Patch-Upgrade angewendet wird, verwendet IBM eine Strategie der schrittweisen Neuerstellung. Replikate werden nacheinander aktualisiert:

  • Der API-Server Kubernetes bleibt während des gesamten Upgrades erreichbar.
  • Cluster-Vorgänge wie Planung, automatische Skalierung und Zustandsprüfungen laufen unterbrechungsfrei weiter.
  • IBM Sorgt für eine sanfte Abschaltverzögerung, damit laufende Verbindungen abgeschlossen werden können, bevor ein Pod entfernt wird.

Patch-Upgrades der Steuerungsebene sind so konzipiert, dass sie keine Auswirkungen auf die in der Datenebene ausgeführten Benutzeranwendungen haben. Ihre Pods, Dienste und Workloads laufen während des gesamten Prozesses auf den Worker-Knoten weiterhin normal weiter.

Auswirkungen auf die Workloads während Aktualisierungen der Steuerungsebene

Da die Datenebene vom Benutzer verwaltet wird, führen Patches der Steuerungsebene von IBM keinen Neustart, keine Neuplanung und keine Änderungen an Ihren Worker-Knoten oder laufenden Anwendungs-Pods durch.

Anwendungen oder Tools, die häufig direkte Aufrufe an die Kubernetes-API senden (wie z. B. benutzerdefinierte Controller, Operatoren, CI/CD-Pipelines oder Überwachungsagenten, die den Clusterstatus überwachen), müssen jedoch vorübergehende API-Fehler elegant handhaben. Beachten Sie die allgemeinen Best Practices für Kubernetes:

  • Implementieren Sie eine Wiederholungslogik mit exponentiellem Backoff für alle API-Aufrufe.
  • Vermeiden Sie es, sich auf dauerhafte offene Verbindungen zum API-Server ohne Wiederverbindungslogik zu verlassen.

Simulation von Szenarien zum Testen der Ausfallsicherheit von Anwendungen

Um Vertrauen in die Ausfallsicherheit von Anwendungen zu schaffen, sollten Sie Produktionsausfälle in einer Nicht-Produktionsumgebung simulieren, bevor geplante Wartungsarbeiten oder unerwartete Störungen auftreten.

Überwachen Sie Ihre Anwendungen während jeder Simulation auf Anzeichen von Störungen: unerwartete Pod-Neustarts, Spitzenwerte in den Fehlerprotokollen, verlängerte Antwortzeiten oder verlorene Client-Anfragen. Nutzen Sie diese Erkenntnisse, um die Wiederholungslogik zu verfeinern, Zustandsprüfungen zu optimieren oder die Replik-Topologie anzupassen.

Die Ausführung von Befehlen zur Clusterverwaltung (wie z. B. master refresh oder worker pool resize) erfordert Plattformzugriff als Administrator oder Operator sowie Berechtigungen für den Clusterverwaltungsdienst. Wenn Sie als Anwendungsentwickler keinen Zugriff auf die Cluster-Infrastruktur haben, sprechen Sie sich bitte mit Ihrem Cluster-Administrator ab, um diese Simulationen durchzuführen.

Simulation eines Patches für die Steuerungsebene mithilfe einer Aktualisierung der Steuerungsebene

Das Auslösen einer Aktualisierung der Steuerungsebene startet den rollierenden Aktualisierungsprozess, den IBM bei Patch-Upgrades verwendet. Dieser Test überprüft, ob Ihre Anwendung und Ihre Tools die Übergänge zwischen Replikaten der Control Plane reibungslos bewältigen.

  1. Lösen Sie eine Aktualisierung der Steuerungsebene in Ihrem Cluster aus.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

  2. Stellen Sie sicher, dass Ihre Anwendungen den Datenverkehr ohne Unterbrechung weiterverarbeiten und dass die für Kunden zugänglichen Endpunkte weiterhin reaktionsfähig bleiben.

Simulation von Netzwerk-Routing-Aktualisierungen durch Hinzufügen und Entfernen von Worker-Knoten

Das Hinzufügen und Entfernen von Worker-Knoten führt dazu, dass Kubernetes die interne Netzwerk-Routing-Logik im gesamten Cluster aktualisiert und so die Bedingungen simuliert, die bei einem Knotenwechsel während der Infrastrukturwartung auftreten.

  1. Passen Sie die Größe Ihres Worker-Pools an, um einen temporären Worker-Knoten hinzuzufügen.

    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE

  2. Überwachen Sie Ihre Anwendungsprotokolle und die Antwortlatenz, während der neue Worker-Knoten initialisiert wird und dem Cluster-Netzwerk beitritt.

  3. Entfernen Sie den Test-Worker-Knoten, sobald der Test abgeschlossen ist.

    So führen Sie eine gezielte Entfernung des in Schritt 1 erstellten Worker-Knotens durch:

    1. Sperren und entleeren Sie den Worker-Knoten, bevor Sie ihn löschen, um sicherzustellen, dass die Workloads ordnungsgemäß neu geplant werden.
       oc cordon NODE_NAME
   oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
    1. Entfernen Sie den Worker-Knoten aus dem Cluster.
       ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
    1. Stellen Sie die Kapazität des Worker-Pools wieder auf den ursprünglichen Wert ein, indem Sie den ibmcloud oc worker-pool resize Befehl mit Ihrem ursprünglichen Wert --size-per-zone verwenden.

    Als Alternative, die weniger zielgerichtet ist, können Sie den Worker-Pool einfach wieder auf seine ursprüngliche Größe zurücksetzen, indem Sie den Befehl ibmcloud oc worker-pool resize aus Schritt 1 verwenden, ohne einen bestimmten Knoten explizit zu löschen.

Empfohlene Vorgehensweisen für die Ausfallsicherheit von Workloads

Die Ausfallsicherheit Ihrer Anwendung bei Cluster-Ereignissen hängt davon ab, wie Ihre Workloads konzipiert und konfiguriert sind. Beachten Sie bei Ihren Kubernetes-Workload-Spezifikationen die folgenden Empfehlungen:

Führen Sie für jede Arbeitslast mehrere Replikate aus

Eine Bereitstellung mit einer einzigen Replik duldet keine Unterbrechungen. Stellen Sie den Wert auf spec.replicas mindestens ein ( 2 vorzugsweise oder 3 mehr für Produktions-Workloads), damit der Ausfall oder die Neuplanung eines einzelnen Pods keine Ausfallzeiten verursacht.

Replikate über Zonen und Worker-Knoten verteilen

Konfigurieren Sie Anti-Affinitätsregeln für topologySpreadConstraints Pods in Ihrer Bereitstellungskonfiguration. Durch die Verteilung von Pods auf mehrere Verfügbarkeitszonen und Worker-Knoten wird verhindert, dass eine Störung in einer einzelnen Zone oder Wartungsarbeiten an einem einzelnen Knoten zum gleichzeitigen Ausfall aller Replikate führen.

Pod-Disruption-Budgets (PDBs) konfigurieren

Eine Ressource PodDisruptionBudget legt die Mindestanzahl oder den Mindestprozentsatz an Pods fest, die während freiwilliger Unterbrechungen, wie z. B. beim Leeren von Knoten oder bei Cluster-Updates, verfügbar bleiben müssen. Definieren Sie für jede kritische Workload eine PDB, um zu verhindern, dass bei Verwaltungsvorgängen mehr Pods entfernt werden, als Ihre Anwendung verkraften kann.

Definition von Bereitschafts- und Verfügbarkeitsprüfungen

Konfigurieren Sie Bereitschafts- und Verfügbarkeitsprüfungen in Ihren Containerspezifikationen:

  • Bereitschaftsprüfungen: Stellen Sie sicher, dass Kubernetes den Datenverkehr nur an Pods weiterleitet, die initialisiert und bereit sind, Anfragen zu bearbeiten.
  • Liveness-Probes: Aktivieren Sie Kubernetes, um Container automatisch neu zu starten, die in einen Deadlock oder einen fehlerhaften Zustand geraten sind.

Festlegen geeigneter Ressourcenanforderungen und -beschränkungen

Legen Sie für jeden Container realistische Anforderungen und Grenzwerte für CPU und Arbeitsspeicher fest. Die Anfragen stellen sicher, dass der Kubernetes-Scheduler Pods auf Knoten mit ausreichender Kapazität platziert. Durch Begrenzungen wird verhindert, dass ein einzelner Container übermäßig viele Ressourcen beansprucht und dadurch die Leistung der auf demselben Worker-Knoten befindlichen Workloads beeinträchtigt.

Implementierung einer eleganten Abschaltprozedur

Wenn ein Pod beendet wird, sendet Kubernetes ein Signal SIGTERM, bevor es gesendet wird SIGKILL. Entwerfen Sie Ihre Anwendung so, dass sie Fehler abfängt SIGTERM, keine neuen Verbindungen mehr akzeptiert, laufende Transaktionen abschließt und ordnungsgemäß beendet wird. Legen Sie in terminationGracePeriodSeconds Ihrer Pod-Spezifikation einen geeigneten Wert fest, um Ihrer Anwendung ausreichend Zeit zu geben, den Datenverkehr abzubauen.

Vermeiden Sie es, sich auf lang andauernde Verbindungen zum API-Server zu verlassen

Kubernetes Überwachungsanfragen und Streaming-Verbindungen (wie z. B oc exec. Portweiterleitungen oder benutzerdefinierte API-Client-Überwachungen) stellen eine direkte Verbindung zu einer bestimmten Replik der Steuerungsebene her. Wenn diese Replik während eines Patch-Upgrades einen Zyklus durchläuft, wird die Verbindung geschlossen. Workloads und Tools müssen eine Logik zur automatischen Wiederverbindung mit exponentiellem Backoff implementieren.

Verwenden Sie Wiederholungslogik und Circuit Breaker

Wenn Ihre Anwendung mit der Kubernetes-API, externen Datenbanken oder nachgelagerten Microservices interagiert, implementieren Sie eine Wiederholungslogik mit exponentiellem Backoff und Jitter. Verwenden Sie Circuit-Breaker-Muster, um Kettenausfälle zu verhindern, wenn eine vor- oder nachgelagerte Abhängigkeit vorübergehend nicht verfügbar ist.

Nächste Schritte