Informationen zum Wiederherstellen von Kubernetes-Clustern basierend auf etcd-Snapshots

Um die Geschäftskontinuität bei Katastrophen sicherzustellen, möchten Sie eine Disaster-Recovery-Strategie für Anwendungen implementieren, die auf Kubernetes-Clustern ausgeführt werden. Verwenden Sie diese Oracle Maximum Availability Architecture-(Oracle MAA-)Empfehlungen, die Datenschutz bieten und Ihnen einen schnellen Wechsel zu einem Standbysystem mit minimalem Daten- und Produktivitätsverlust ermöglichen.

Trotz der enormen Änderung, die der Kubernetes-Einführung für die Architektur des IT-Systems voraussetzt, stellt ein Kubernetes-System ähnliche Disaster Recovery-(DR-)Paradigmen wie eine herkömmliche Anwendung (wie Oracle Java SE, Oracle Java EE oder JavaScript) dar. Es muss eine konsistente und "möglichst aktuelle" Kopie Ihres primären Systems an einem sekundären Speicherort aufrechterhalten werden, die Workloads wiederaufnehmen kann, wenn eine Disaster-Ausfallzeit in der primären Region entsteht.

Dieses Lösungs-Playbook enthält Oracle MAA-Empfehlungen und -Utilitys, mit denen Sie ein sekundäres Kubernetes-System erstellen und Disaster-Szenarios, die sich auf einen Standort auswirken, wiederherstellen und die Umleitung von Workloads zu einem Replikatsort erzwingen können.

Dieses Lösungs-Playbook konzentriert sich zwar auf die Wiederherstellung eines Kubernetes-Clusters in einer anderen Region, Sie können aber dieselben Skripte und Prozeduren verwenden, um ein Cluster direkt bis zu einem früheren Zeitpunkt wiederherzustellen. Dieser Vorgang kann in anderen Szenarios als dem Disaster Recovery nützlich sein. Beispiel:

Wenn die Steuerebene falsch konfiguriert ist.
Wenn die etcd-Datenbank verloren geht, beschädigt ist oder wenn etcd nicht ordnungsgemäß hochgefahren wird.
Wenn sich ein falscher Deployment- oder Benutzerfehler auf mehrere Anwendungen oder Microservices auswirkt und das Cluster auf eine vorherige Version oder Inkarnation zurückgesetzt werden muss. Beim Wiederherstellen eines ETCD-Snapshots werden alle Artefakte auf den Zeitpunkt zurückgesetzt, zu dem der Snapshot (Backup) erstellt wurde.

In diesem Dokument werden die Daten aus Kubernetes usw. an einem sekundären Speicherort repliziert. Alle Informationen eines Kubernetes-Clusters werden in etcd gespeichert, einem Schlüsselwertspeicher, der als Kubernetes-Backing-Speicher für die Daten des Clusters verwendet wird. Dieses Lösungs-Playbook enthält Empfehlungen zum Replizieren eines Kubernetes-Clusters, das mit dem Kubernetes-Tool kubeadm erstellt wurde (siehe https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), basierend auf etcd-Wiederherstellung. Die bereitgestellten Setupprozeduren und Skripte erfordern möglicherweise Anpassungen für andere Clustertypen (die nicht mit kubeadm erstellt wurden). Im Allgemeinen sind jedoch gültig, solange Zugriff auf die etcd-Endpunkte besteht, die von der Kubernetes-Control Plane verwendet werden. Diese Replikationslösung erfordert ein spezifisches Setup für das sekundäre Cluster und verwendet eine Kopie von etcd (auch als etcd-Snapshots bezeichnet), um genau dieselben Artefakte aufzurufen, die in der primären Datenbank vorhanden waren.

Mit Artefakt-Snapshots oder Kubernetes-Backuptools von Drittanbietern können Sie bestimmte Namespaces und Anwendungen über Kubernetes-Systeme hinweg replizieren. Sie schützen Cluster jedoch nicht vor Dateibeschädigungen und Fehlkonfigurationen in den Metadaten der Control Plane. Sie können diese nicht nur zum Katastrophenschutz verwenden, sondern auch etcd-Snapshots für lokale Restore-Vorgänge verwenden und Kubernetes-Cluster auf einen vorherigen Arbeitspunkt zurücksetzen. Wenn Ihr etcd-Speicher und Ihr etcd-Clustersystem fehlerhaft sind, werden Anwendungen möglicherweise weiterhin ausgeführt, Podverschiebungen, Konfigurationsänderungen, Secret-Zugriff und andere Vorgänge, die eine Verfügbarkeit der Control Plane erfordern, funktionieren jedoch nicht ordnungsgemäß. Daher muss die Beibehaltung von etcd ein wichtiger Bestandteil aller Kubernetes-Cluster-Lebenszyklusprozeduren sein.

Neben den Kubernetes-Konfigurationsdaten können Anwendungen und Microservices, die auf Kubernetes ausgeführt werden, zur Laufzeit Daten generieren. Runtime Data Disaster Protection ist außerhalb dieses Dokuments und sollte genauso behandelt werden wie bei herkömmlichen Anwendungen, die auf Anwendungsservern ausgeführt werden:

Vermeiden Sie mehrsprachige Persistenz (die Verwendung verschiedener Arten von persistenten Speichern für Laufzeitdaten ist ein "fast" unmöglich Problem gemäß BAC-Theorem zu lösen)
Verwenden Sie einen einzigen Speicher für alle verschiedenen Datentypen, Microservices und Anwendungen mit möglichst vielen Abhängigkeiten
Informationen zum Katastrophenschutz für Ihre Laufzeit finden Sie unter Oracle MAA Best Practices for Oracle Database.

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:

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-Clusterkonfiguration wird über etcd-Snapshots zum Control-Plane-Schutz repliziert. Sie können etcd-Kopien oder Artefakt-Snapshots zum anwendungsspezifischen Konfigurationsschutz verwenden. Weitere Informationen finden Sie unter Artefakt-Snapshots zum Schutz Ihrer Kubernetes-Cluster vor Katastrophen verwenden. Von den Containern verwendete Images werden in Registrys entweder lokal für jedes Cluster oder in externen Repositorys gehostet (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 von kubernetes-etcd-multiregion-dr.png folgt

Beschreibung der Abbildung kubernetes-etcd-multiregion-dr.png

kubernetes-etcd-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-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.
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.
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. Die Kubernetes-Cluster in den beiden Regionen sollten ähnliche Ressourcen wie die Anzahl der Worker-Knoten (und deren Hardwarekapazität) und andere Infrastruktur (Shared Storage, Load Balancer, Datenbanken usw.) aufweisen. 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.
Hostnamenalias und Virtualisierung: Es ist wichtig, die von den Knoten auf der sekundären Site verwendeten Hostnamen zu planen. Die Hostnamen oder Aliashostnamen für die Control-Plane und Worker-Knoten müssen im sekundären Speicherort "aktiv" sein, bevor ein etcd-Snapshot aus einem primären Kubernetes-Cluster wiederhergestellt werden kann. Knotennamen werden in verschiedenen Artefakten eines Kubernetes-Clusters gespeichert, um Worker-Knoten zu identifizieren, Pod-Zuweisungen zu markieren, in Konfigurations-Maps (config)-Maps, die das Cluster selbst beschreiben, sowie in mehreren Konfigurationsdateien und Einträgen. Ihr sekundärer Speicherort muss die Worker-, Control Plane- und Frontend-kube-api-Adressen mit denselben Hostnamen identifizieren, die im primären Kubernetes-Cluster verwendet werden (ein vollständig angegebener Name kann sich im Domainnamen unterscheiden, der Hostname muss jedoch identisch sein. Ohne Aliasnamen funktioniert eine etcd-Snapshot-Wiederherstellung nicht ordnungsgemäß, da Kubelets, Scheduler, Controller und im Allgemeinen die Control-Plane-Services nicht die entsprechenden Endpunkte und Hosts erreichen können, die von der replizierten Konfiguration verwendet werden. Verwenden Sie keine IPs, um Knoten in Kubernetes zu identifizieren. Verwenden Sie stattdessen immer Hostnamen.
Containerimages weisen ein ähnliches Paradigma wie Binärdateien auf: Images ändern sich möglicherweise 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 Lösungs-Playbook zeigt ein Beispiel mit Kubernetes-Clustern, die mit dem Tool kubeadm erstellt wurden. Die Empfehlungen gelten für benutzerdefinierte Kubernetes-Cluster, die in On-Premise-Systemen installiert sind. Die meisten Skripte erfordern jedoch möglicherweise Änderungen für Cluster, die nicht mit dem Tool kubeadm erstellt werden. Sie müssen die Schritte und Skripte verwenden, die zwischen Kubernetes-Clustern bereitgestellt werden, auf denen dieselbe etcd- und Kubernetes-Version ausgeführt wird. Die Wiederherstellung von etcd-Snapshots über verschiedene Kubernetes-Versionen hinweg kann zu Inkonsistenzen und instabilen etcd-Clustern führen.

Erforderliche Produkte und Rollen - Info

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

Kubernetes-Cluster
Bastion, die den Kubernetes-Systemzugriff auf die etcd-Endpunkte des Clusters verwalten und mit ssh auf die verschiedenen Control-Plane-Knoten zugreifen kann
(Optional) 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 On Premise befinden.

Für jeden Service sind diese Rollen erforderlich.

Servicename: Rolle	Erforderlich für ...
Kubernetes-Cluster (primär): `administrator`	alle Skripte ausführen
Kubernetes-(Primär-)Knoten: Benutzer mit sudo-Rechten für Root	Folgende Skripts ausführen: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Kubernetes-Cluster (sekundär): `administrator`	alle Skripte ausführen
Kubernetes-(sekundäre) Knoten: Benutzer mit sudo-Rechten für Root	Folgende Skripts ausführen: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

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