Mit Artefakt-Snapshots Ihre Kubernetes-Cluster vor Katastrophen schützen

Um die Geschäftskontinuität bei Katastrophen sicherzustellen, möchten Sie eine Disaster-Recovery-(DR-)Strategie für Anwendungen implementieren, die auf dem Kubernetes-Cluster ausgeführt werden und Datenschutz bieten. Mit dieser Strategie können Sie schnell zu einem Standbysystem wechseln, bei dem nur minimale Daten- und Produktivitätsverluste auftreten. Trotz der enormen Änderung, die der Kubernetes-Einführung für die Architektur des IT-Systems voraussetzt, stellt ein Kubernetes-System ähnliche DR-Paradigmen wie eine herkömmliche Anwendung (Oracle Java SE, Oracle Java EE usw.) dar. Sie müssen eine konsistente und eine möglichst aktuelle Kopie Ihres Primärsystems an einem sekundären Speicherort aufrechterhalten, die Arbeitslasten wiederaufnehmen kann, wenn dies zu Ausfallzeiten in der primären Region führen soll.

Oracle Maximum Availability Architecture (MAA) bietet Empfehlungen und Utilitys, mit denen Sie in Disaster-Szenarios ein Recovery durchführen können, die sich auf einen Standort auswirken, und die Umleitung von Workloads auf einen Replikatsstandort erzwingen. Der Schwerpunkt dieses Buches ist die Kubernetes-Konfigurationsreplikation für Anwendungen. Anwendungen, die auf Kubernetes-Clustern ausgeführt werden, hängen von vielen verschiedenen Komponenten ab, die ausgeführt werden müssen, darunter Control-Plane-Knoten, Worker-Knoten, Load Balancer und Speicher. Gleichzeitig stellen die Laufzeitdaten, die von Anwendungen generiert werden, die auf Kubernetes ausgeführt werden, dieselben Herausforderungen wie herkömmliche Anwendungen dar. Während Laufzeitanwendungen können persistente Daten generieren, lesen und aktualisieren. Dieses Lösungs-Playbook enthält Empfehlungen zur Replikation der Konfiguration einer auf Kubernetes ausgeführten Anwendung. Der Katastrophenschutz von Laufzeitdaten liegt außerhalb des Geltungsbereichs dieses Dokuments und sollte genau wie bei herkömmlichen Anwendungen, die auf Anwendungsservern ausgeführt werden, behandelt werden, einschließlich:

• Vermeiden Sie mehrsprachige Persistenz. Die Verwendung verschiedener Arten von persistenten Speichern für Laufzeitdaten ist laut dem Theorem "Backup Availability Consistency (BAC)" nahezu unmöglich zu lösen.
• Verwenden Sie einen einzigen Speicher für alle verschiedenen Datentypen, Microservices und Anwendungen mit Abhängigkeiten so weit wie möglich.
• Informationen zum Katastrophenschutz für Ihre Laufzeitdaten finden Sie unter Best Practices für Oracle MAA für Oracle Database.

Außerdem müssen Sie die Control Plane des Kubernetes-Clusters schützen. Verwenden Sie die entsprechenden etcd-Snapshots, um Beschädigungen und Fehler zu vermeiden und um ein Flashback für funktionierende Cluster bereitzustellen. Obwohl Oracle Maximum Availability Best Practices für den Control-Plane-Schutz vor Katastrophen bereitstellt, liegt der Umfang dieses Dokuments nicht bei der Beschreibung der erforderlichen Techniken in diesem Bereich.

Bevor Sie beginnen

Es gibt verschiedene technische Kurzüberblicke in Oracle Maximum Availability Architecture (MAA), in denen beschrieben wird, wie ein Disaster Recovery-(DR-)System für traditionelle Middleware-Systeme eingerichtet wird. In diesen Dokumenten werden die Katastrophenschutzanforderungen für die externen Infrastrukturkomponenten (wie Speicher, Load Balancer und Datenbank) beschrieben, die von Kubernetes-Anwendungen verwendet werden.

Weitere Informationen finden Sie unter:

• Oracle WebLogic Server for Oracle Cloud Infrastructure - Disaster Recovery
• SOA Suite auf Oracle Cloud Infrastructure Marketplace Disaster Recovery

Architektur

Diese Architektur zeigt die Topologie des Disaster Recovery-(DR-)Systems für das Kubernetes-Cluster.

Alle Laufzeit-, Konfigurations- und Metadateninformationen in der primären Datenbank werden von Region 1 in Region 2 mit Oracle Autonomous Data Guard repliziert. Die erforderliche Kubernetes-(K8s-)Clusterkonfiguration wird über ETCD-Snapshots zum Control-Plane-Schutz und mit YAML-Snapshots zum Schutz der Anwendungskonfiguration repliziert. Sie können Artefakt-Snapshots verwenden oder etcd-Kopien oder Artefakt-Snapshots für anwendungsspezifischen Konfigurationsschutz für anwendungsspezifischen Konfigurationsschutz verwenden. Weitere Informationen finden Sie unter Wiederherstellung von Kubernetes-Clustern basierend auf etcd-Snapshots. Die vom Container verwendeten Images werden in Registrys gehostet, entweder lokal für jedes Cluster oder in externen Repositorys (Bilder werden selbst nicht als Kubernetes-Clusterkonfiguration betrachtet).

Hinweis:

Die Einrichtung von Oracle Autonomous Data Guard für die Laufzeitdatenbank liegt außerhalb des Geltungsbereichs dieses Dokuments.

Beschreibung der Abbildung kubernetes-multiregion-dr.png

kubernetes-multiregion-dr-oracle.zip

Diese Architektur unterstützt die folgenden Komponenten:

• Region

  Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domains bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie voneinander trennen (innerhalb von Ländern oder sogar Kontinenten).

• Load Balancer

  Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt zu mehreren Servern im Backend.

• Dynamisches Routinggateway (DRG)

  Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie einem VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.

• Data Guard

  Oracle Data Guard umfasst zahlreiche Services, mit denen Sie eine oder mehrere Standby-Datenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standby-Datenbanken als Kopien der Produktionsdatenbank. Wenn dann die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, kann Oracle Data Guard jede Standbydatenbank in die Produktionsrolle umschalten und so die Ausfallzeit für den Ausfall minimieren.

• Oracle Real Application Clusters (Oracle RAC)

  Mit Oracle RAC können Sie eine einzelne Oracle Database auf mehreren Servern ausführen, um die Verfügbarkeit zu maximieren und die horizontale Skalierbarkeit beim Zugriff auf Shared Storage zu ermöglichen. Benutzersessions, die sich bei Oracle RAC-Instanzen anmelden, können Failover ausführen und Änderungen während Ausfällen sicher wiedergeben, ohne dass Änderungen an Endbenutzeranwendungen vorgenommen werden müssen.

• Container-Registry

  Oracle Cloud Infrastructure Registry ist eine von Oracle verwaltete Registry, mit der Sie Ihren Workflow von Entwicklung zu Produktion vereinfachen können. Registry erleichtert das Speichern, Freigeben und Verwalten von Entwicklungsartefakten und -images. Die hochverfügbare und skalierbare Architektur von Oracle Cloud Infrastructure stellt sicher, dass Sie Ihre Anwendungen zuverlässig bereitstellen und verwalten können.

• Container Engine for Kubernetes

  Oracle Cloud Infrastructure Container Engine for Kubernetes ist ein vollständig verwalteter, skalierbarer und hochverfügbarer Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Sie geben die von Ihren Anwendungen benötigten Compute-Ressourcen an, und Container Engine for Kubernetes stellt sie in einem vorhandenen Mandanten in Oracle Cloud Infrastructure bereit. Container Engine for Kubernetes verwendet Kubernetes, um das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen auf mehreren Hostclustern zu automatisieren.

• Kubernetes-Cluster

  Ein Kubernetes-Cluster ist eine Gruppe von Rechnern, auf denen containerisierte Anwendungen ausgeführt werden. Kubernetes bietet eine portierbare, erweiterbare Open-Source-Plattform für die Verwaltung containerisierter Workloads und Services in diesen Knoten. Ein Kubernetes-Cluster wird aus Worker-Knoten und Control-Plane-Knoten gebildet.

• Kubernetes-Worker-Knoten

  Ein Kubernetes-Worker-Knoten ist ein Worker-Rechner, der containerisierte Anwendungen in einem Kubernetes-Cluster ausführt. Jedes Cluster hat mindestens einen Worker-Knoten.

• Kubernetes-Control Plane
  Eine Kubernetes-Control Plane verwaltet die Ressourcen für die Worker-Knoten und Pods in einem Kubernetes-Cluster. Die Control-Plane-Komponenten erkennen und reagieren auf Ereignisse, führen die Planung durch und verschieben Clusterressourcen. Im Folgenden sind die Komponenten der Control Plane aufgeführt:

  • kube-apiserver: Führt den Kubernetes-API-Server aus.
  • etcd: Verteilter Schlüssel-Werte-Speicher für alle Cluster-Daten.
  • kube-scheduler: Bestimmt, auf welchem Knoten neue nicht zugewiesene Pods ausgeführt werden.
  • kube-controller-manager: Führt Controller-Prozesse aus.
  • cloud-controller-manager: Verknüpft Ihr Cluster mit einer cloud-spezifischen API.
• Ingress-Controller

  Ein Ingress-Controller ist eine Komponente, die in einem Kubernetes-Cluster ausgeführt wird und die Ingress-Ressourcen verwaltet. Er empfängt Datenverkehr vom externen Netzwerk, leitet ihn an den richtigen Service weiter und führt Load Balancing sowie SSL-Beendigung durch. Der Ingress-Controller wird in der Regel als separater Pod im Cluster ausgeführt und kann unabhängig von den von ihm verwalteten Services skaliert werden.

• KUBE-Endpunkt-API

  Die KUBE-Endpunkt-API ist die Komponente kube-apiserver der Kubernetes-Control Plane. Es wird der Kubernetes-API-Server ausgeführt.

• ETCD-Backup

  ETCD-Backup ist ein Backup der ETCD-Komponente der Kubernetes-Control Plane. Die etcd enthält den verteilten Schlüssel/Wert-Speicher für alle Clusterdaten. Es ist wichtig, ein ETCD-Backup zu erstellen, um Kubernetes-Cluster für das Disaster Recovery wiederherzustellen.

• YAML-Snapshots

  Ein YAML-Snapshot ist eine Point-in-Time-Kopie der (YAML-)Dateien mit der Definition der Artefakte in einem Kubernetes-Cluster. Der Snapshot ist eine tar-Datei, mit der Sie diese Artefakte in demselben oder einem anderen Kubernetes-Cluster wiederherstellen können.

Überlegungen zum Katastrophenschutz in Kubernetes

Beachten Sie bei der Implementierung von Disaster Protection für Kubernetes Folgendes:

• Symmetrisches Disaster Recovery (DR): Oracle empfiehlt die Verwendung derselben Ressourcenkapazität und -konfiguration in primärer und sekundärer Instanz. Für die beteiligten Kubernetes-Namespaces sollten ähnliche Ressourcen verfügbar sein, wie die Anzahl der Worker-Knoten (und deren Hardwarekapazität) und andere Infrastruktur (Shared Storage, Load Balancer, Datenbanken usw.). Die Ressourcen, von denen das Kubernetes-Cluster in der sekundären Region abhängig ist, müssen mit denselben Workloads wie primär arbeiten können. Außerdem müssen die beiden Systeme funktionell konsistent sein mit den exakt gleichen Diensten, von denen das wiederhergestellte System abhängt, Seitenwagen, Konfigurationskarten (CMs) müssen an beiden Orten verwendet werden.
• Containerimages weisen ein ähnliches Paradigma wie Binärdateien auf: Images ändern sich nicht so häufig wie die Kubernetes-Konfiguration, und Sie müssen Images möglicherweise nicht mit jeder Kubernetes-Clusterreplikation aktualisieren. Die vom primären System verwendeten Images müssen mit denen im sekundären System identisch sein, oder es können Inkonsistenzen und Fehler auftreten. Die Bildreplikation ist jedoch außerhalb des Geltungsbereichs dieses Playbooks. Es gibt mehrere Strategien, mit denen Sie eine konsistente Verwendung von Bildern zwischen zwei Standorten gewährleisten können, darunter:
  • Speichern Sie Images in der primären Datenbank, und laden Sie sie in die Worker-Knoten der sekundären Gruppe. Dieser Ansatz ist sehr einfach zu implementieren, verursacht jedoch Verwaltungsaufwand. Die Verwendung von Container-Registrys bietet erhebliche Vorteile, und das lokale Speichern von Images erschwert die Verwaltung von Versionen und Updates.
  • Images können sich in vollständig externen Container-Registrys in verschiedenen Regionen oder Data Centern befinden, die von der Primär- und der Standbydatenbank verwendet werden. Externe Produkte und Bibliotheken werden von Dritten verwaltet, und ihre Verfügbarkeit ist in der Regel in ihren Releases implizit.
  • Images können sich in Container-Registrys befinden, die sich in Primär- und Standbydatenbank befinden. Jede Region wird parallel aktualisiert, wenn eine neue Version eines Images freigegeben wird. Dies bietet eine bessere Kontrolle über die verwendete Software, führt jedoch zu einem höheren Verwaltungsaufwand. Für den Zugriff auf zwei verschiedene Registrys müssen Images dupliziert und die Zugangsdaten verwaltet werden. CI/CD-Tools werden in der Regel für diesen Ansatz verwendet.

Dieses Playbook zeigt zwar ein Beispiel mit Oracle Cloud Infrastructure, die Empfehlungen sind jedoch allgemein für benutzerdefinierte Kubernetes-Cluster, die in On-Premise-Systemen installiert sind. Sie können die Schritte und Skripte verwenden, die zwischen einem primären Kubernetes-Cluster, das in Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) ausgeführt wird, und einem sekundären Cluster bereitgestellt werden, das in einem On-Premise- oder benutzerdefinierten Kubernetes-Cluster ausgeführt wird. Sie können auch die Schritte und Skripte zwischen einem primären Kubernetes-Cluster, das in OKE ausgeführt wird, und einem sekundären Cluster, das ebenfalls in OKE ausgeführt wird, oder zwischen zwei On-Premise- oder benutzerdefinierten Kubernetes-Clustern verwenden.

Erforderliche Produkte und Rollen - Info

Für diese Lösung sind folgende Produkte und Rollen erforderlich:

• Kubernetes-Cluster
• Bastionknoten zur Verwaltung des Kubernetes-Systems
• Oracle Cloud Infrastructure (OCI)

  Dieses Playbook basiert auf der Verwendung von OCI-Regionen und -Ressourcen für die primäre und sekundäre Region. Diese Lösung gilt jedoch auch für Kubernetes-Cluster, die sich nicht auf OCI befinden.

Für jeden Service sind diese Rollen erforderlich.

Servicename: Rolle	Erforderlich für ...
Oracle Cloud Infrastructure: admin	Ressourcen und Services bereitstellen und einrichten, wenn Sie eine oder mehrere OCI-Regionen verwenden.
Kubernetes-Cluster (primär): administrator	alle Skripte ausführen
Kubernetes-(Primär-)Knoten: BS-Benutzer mit Ausführungsberechtigungen und SSH-Berechtigungen für sekundäre Knoten	Folgende Skripts ausführen: maak8-get-all-artifacts.sh maak8DR-apply.sh
Kubernetes-Cluster (sekundär): administrator	alle Skripte ausführen
Kubernetes-(sekundäre) Knoten: BS-Benutzer mit Ausführungsberechtigungen	Folgende Skripts ausführen: removeyamlblock.sh apply-artifacts.sh maak8-push-all-artifacts.sh

Informationen zu den benötigten Informationen finden Sie unter Oracle Produkte, Lösungen und Services.

Änderungslog

In diesem Log werden wichtige Änderungen aufgeführt:

12. Juli 2023

Das Architekturdiagramm wurde überarbeitet. Der Inhalt wurde erweitert.