Informationen zur Wiederherstellung von Kubernetes-Clustern auf Basis von etcd-Snapshots

Um die Geschäftskontinuität im Katastrophenfall sicherzustellen, sollten Sie eine Disaster-Recovery-Strategie für Anwendungen implementieren, die auf Kubernetes-Clustern ausgeführt werden. Verwenden Sie diese Empfehlungen von Oracle Maximum Availability Architecture (Oracle MAA), die Datenschutz bieten und es Ihnen ermöglichen, schnell zu einem Standby-System mit minimalem Verlust von Daten und Produktivität zu wechseln.

Trotz der enormen Veränderung, die Kubernetes für die Architektur des IT-Systems bedeutet, präsentiert ein Kubernetes-System ähnliche Disaster Recovery-(DR-)Paradigmen wie eine herkömmliche Anwendung (wie Oracle Java SE, Oracle Java EE oder JavaScript). Es muss eine konsistente und möglichst aktuelle Kopie Ihres primären Systems an einem sekundären Speicherort beibehalten werden, der die Workloads wiederaufnehmen kann, sollte eine Katastrophe zu Ausfallzeiten in der primären Region führen.

Dieses Lösungshandbuch enthält Empfehlungen und Utilitys von Oracle MAA, mit denen Sie ein sekundäres Kubernetes-System erstellen und ein Recovery in Disaster-Szenarios durchführen können, die sich auf einen Standort auswirken, und die Umleitung von Workloads zu einer Replikatsite erzwingen.

Obwohl sich dieses Lösungshandbuch auf die Wiederherstellung eines Kubernetes-Clusters in einer anderen Region konzentriert, können Sie dieselben Skripte und Prozeduren verwenden, um ein Cluster direkt auf einen früheren Zeitpunkt wiederherzustellen. Dieser Vorgang kann in anderen Szenarios als dem Disaster Recovery nützlich sein. Beispiele:

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

Dieses Dokument konzentriert sich auf die Replikation der etcd-Daten von Kubernetes in einem sekundären Speicherort. Alle Informationen eines Kubernetes-Clusters werden in etcd gespeichert, einem Schlüsselwertspeicher, der als Kubernetes-Backing-Speicher für die Clusterdaten verwendet wird. Dieses Lösungshandbuch 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 restore. Die bereitgestellten Setupprozeduren und Skripte erfordern möglicherweise Anpassungen für andere Clustertypen (die nicht mit kubeadm erstellt wurden), sind jedoch im Allgemeinen 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 Instanz vorhanden waren.

Sie können Artefakt-Snapshots oder Kubernetes-Backuptools von Drittanbietern verwenden, um bestimmte Namespaces und Anwendungen über Kubernetes-Systeme hinweg zu replizieren. Sie schützen Cluster jedoch nicht vor Dateibeschädigungen und Fehlkonfigurationen in den Control-Plane-Metadaten. Neben der Verwendung für den Katastrophenschutz können Sie etcd snapshots für lokale Wiederherstellungen verwenden und Kubernetes-Cluster auf einen vorherigen Arbeitspunkt zurücksetzen. Wenn das System etcd store und etcd cluster fehlerhaft sind, werden Anwendungen möglicherweise weiterhin ausgeführt, Podverschiebungen, Konfigurationsänderungen, geheimer Zugriff und alle anderen Vorgänge, die eine Verfügbarkeit der Control Plane erfordern, funktionieren jedoch nicht ordnungsgemäß. Aus diesem Grund muss die Beibehaltung von etcd ein wichtiger Bestandteil aller Lebenszyklusprozeduren für Kubernetes-Cluster sein.

Neben den Kubernetes-Konfigurationsdaten können Anwendungen und Microservices, die auf Kubernetes ausgeführt werden, zur Laufzeit Daten generieren. Der Schutz von Datenkatastrophen zur Laufzeit liegt außerhalb des Geltungsbereichs dieses Dokuments und sollte genauso behandelt werden wie bei herkömmlichen Anwendungen, die auf Anwendungsservern ausgeführt werden:

• Mehrsprachige Persistenz vermeiden (die Verwendung verschiedener Arten persistenter Speicher für Laufzeitdaten ist ein "fast" unmöglich zu lösendes Problem gemäß dem BAC-Theorem)
• Verwenden Sie einen einzigen Speicher für alle verschiedenen Datentypen, Microservices und Anwendungen mit möglichst vielen Abhängigkeiten
• Informationen zum Katastrophenschutz zur Laufzeit finden Sie unter Best Practices für Oracle MAA für Oracle Database.

Bevor Sie beginnen

Es gibt mehrere technische Kurzüberblicke zu Oracle Maximum Availability Architecture (MAA), in denen beschrieben wird, wie ein Disaster Recovery-(DR-)System für herkömmliche Middleware-Systeme eingerichtet wird. In diesen Dokumenten werden die Disaster-Schutzanforderungen für die externen Infrastrukturkomponenten (wie Speicher, Load Balancer und Datenbank) beschrieben, die Kubernetes-Anwendungen verwenden.

Weitere Informationen finden Sie im Folgenden:

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

Weitere Informationen zur Verwendung von Artefakt-Snapshots zum anwendungsspezifischen Konfigurationsschutz finden Sie unter Artefakt-Snapshots zum Schutz Ihrer OCI-Kubernetes-Engine-Cluster vor Disaster verwenden.

Architektur

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

Alle Laufzeit-, Konfigurations- und Metadateninformationen in der Primärdatenbank werden mit Oracle Autonomous Data Guard von Region 1 in Region 2 repliziert. Die erforderliche Kubernetes-Clusterkonfiguration wird für den Control-Plane-Schutz über etcd-Snapshots repliziert. Sie können etcd-Kopien oder Artefakt-Snapshots zum anwendungsspezifischen Konfigurationsschutz verwenden. Von den Containern verwendete Images werden in Registrys entweder lokal in jedem Cluster oder in externen Repositorys gehostet (Images werden nicht selbst 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-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-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

• Load Balancer

  Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server 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, z.B. ein VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

• Data Guard

  Oracle Data Guard und Oracle Active Data Guard stellen ein umfassendes Set von Services bereit, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten, verwalten und überwachen und Oracle-Produktionsdatenbanken unterbrechungsfrei verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank in die Produktionsrolle umschalten, wodurch die Ausfallzeit im Zusammenhang mit dem Ausfall minimiert wird. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads, die hauptsächlich gelesen werden, in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

• Oracle Real Application Clusters (Oracle RAC)

  Mit Oracle RAC können Sie eine einzelne Oracle Database über mehrere Server hinweg ausführen, um die Verfügbarkeit zu maximieren und die horizontale Skalierbarkeit beim Zugriff auf Shared Storage zu ermöglichen. Benutzersessions, die eine Verbindung zu Oracle RAC-Instanzen herstellen, können Failover ausführen und Änderungen bei Ausfällen ohne Änderungen an Endbenutzeranwendungen sicher wiedergeben.

• Registrierung

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

• Kubernetes Engine

  Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine oder OKE) ist ein vollständig verwalteter, skalierbarer und hoch verfügbarer Service, mit dem Sie Ihre Containeranwendungen in der Cloud bereitstellen können. Sie geben die Compute-Ressourcen an, die Ihre Anwendungen benötigen, und Kubernetes Engine stellt sie in Oracle Cloud Infrastructure in einem vorhandenen Mandanten bereit. OKE automatisiert mit Kubernetes das Deployment, die Skalierung und die Verwaltung containerisierter Anwendungen über Cluster von Hosts hinweg.

• Kubernetes-Cluster

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

• Kubernetes-Steuerebene
  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 Steuerebene aufgeführt:

  • kube-apiserver: Führt den Kubernetes-API-Server aus.
  • etcd: Verteilter Schlüssel-Wert-Speicher für alle Clusterdaten.
  • 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 verfügt über 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 Traffic vom externen Netzwerk, leitet ihn an den richtigen Service weiter und führt Load Balancing und 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-Endpoint-API ist die Komponente kube-apiserver der Kubernetes-Control Plane. Er führt den Kubernetes-API-Server aus.

• ETCD-Backup

  ETCD Backup ist ein Backup der Komponente etcd 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 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 von Kubernetes

Beachten Sie bei der Implementierung des Katastrophenschutzes für Kubernetes Folgendes:

• Symmetrisches Disaster Recovery (DR): Oracle empfiehlt, dieselbe Ressourcenkapazität und -konfiguration in primärer und sekundärer Version zu verwenden. Die Kubernetes-Cluster in den beiden Regionen sollten über ähnliche Ressourcen verfügen, wie die Anzahl der Worker-Knoten (und deren Hardwarekapazität) und andere Infrastruktur (gemeinsamer Speicher, Load Balancer, Datenbanken usw.). Die Ressourcen, von denen das Kubernetes-Cluster in der sekundären Region abhängt, müssen mit denselben Workloads wie die primäre mithalten können. Außerdem müssen die beiden Systeme funktional mit den exakt gleichen Diensten konsistent sein, von denen das restaurierte System abhängt, Nebenwagen, Konfigurationskarten (CMs) müssen an beiden Orten verwendet werden.
• Hostnamensalias und Virtualisierung: Es ist wichtig, die Hostnamen zu planen, die von den Knoten in der sekundären Site verwendet werden. Die Hostnamen oder Aliashostnamen für die Control-Plane und die Worker-Knoten müssen im sekundären Speicherort "aktiv" sein, bevor ein etcd-Snapshot aus einem primären Kubernetes-Cluster wiederhergestellt wird. Knotennamen werden in verschiedenen Artefakten eines Kubernetes-Clusters gespeichert, um Worker-Knoten zu identifizieren, Pod-Zuweisungen zu markieren, in Konfigurationszuordnungen (Konfigurationszuordnungen), 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 vollqualifizierter Name kann sich im Domainnamen unterscheiden, der Hostname muss jedoch identisch sein.) Ohne Alias für den Hostnamen funktioniert eine Snapshot-Wiederherstellung etcd nicht ordnungsgemäß, da Kubelets, Scheduler, Controller und im Allgemeinen die Control-Plane-Services die entsprechenden Endpunkte und Hosts, die von der replizierten Konfiguration verwendet werden, nicht erreichen können. Verwenden Sie keine IP-Adressen, um Knoten in Kubernetes zu identifizieren. Verwenden Sie stattdessen immer Hostnamen.
• Images stellen ein ähnliches Paradigma wie Binärdateien dar: 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 Bilder müssen mit denen im sekundären System identisch sein, oder es können Inkonsistenzen und Fehler auftreten. Die Imagereplikation ist jedoch außerhalb des Geltungsbereichs dieses Handbuchs. Es gibt mehrere Strategien, die Sie verwenden können, um eine konsistente Verwendung von Bildern zwischen zwei Standorten zu gewährleisten, einschließlich der folgenden:
  • Speichern Sie Bilder im primären Bereich, und laden Sie sie auf die Worker-Knoten des sekundären Bereichs. Dieser Ansatz ist sehr einfach zu implementieren, verursacht jedoch Verwaltungsaufwand. Die Verwendung von Container-Registrys hat erhebliche Vorteile, und das lokale Speichern von Bildern 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 Primär- und Standbydatenbanken verwendet werden. Externe Produkte und Bibliotheken werden von Dritten verwaltet, und ihre Verfügbarkeit ist in ihren Releases in der Regel implizit.
  • Images können sich in Container-Registrys in der 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. Sie erfordert das Duplizieren von Images und das Verwalten der Zugangsdaten für den Zugriff auf zwei verschiedene Registrys. CI/CD-Tools werden in der Regel für diesen Ansatz verwendet.
• Unterschiede zwischen dem primären und dem sekundären Cluster: Es wird erwartet (wie im Allgemeinen für DR-Systeme), dass primäre und sekundäre Replikate in Bezug auf die verwendeten Versionen und Konfigurationen sind. Folgende Aspekte sind besonders relevant:
  1. Kubernetes-Versionen
  2. Containerlaufzeit und Containerlaufzeitversion
  3. Netzwerk-Plug-in und Netzwerk-Plug-in-Versionen
  4. podSubnet und servicesubnet
  5. Hostpfadverzeichnis etcd und Imageversion etcd
  6. Netzwerk-Plug-in und DNs-Imageversion
  7. Bild-Repository für Control-Plane-Pods

  Katastrophenschutzkonfigurationen mit geringfügigen Unterschieden zwischen Sites in der Kubernetes-Version funktionieren möglicherweise, können jedoch den Cluster nach einer Wiederherstellung aus dem etcd-Snapshot eines Primärrechners in einem inkonsistenten Status belassen. Informationen zu Container-Laufzeit-Sockets, Kubernetes-Version usw. werden in Kubernetes selbst gespeichert. Beispiel: cri-socket-Informationen sind auf Basis der verwendeten Containerlaufzeit für jeden Knoten spezifisch und werden in internen Konfigurationszuordnungen gespeichert. Viele Informationen, die von kubeadm für Upgrades verwendet werden, basieren auf Konfigurationszuordnungen im Namespace kube-system. Daher ist es wichtig, dass sowohl primäre als auch sekundäre dieselben Informationen in diesen Konfigurationsmaps verwenden. Mit diesem Befehl können Sie alle relevanten Informationen aus den wichtigen configmaps sowohl in der Primär- als auch in der Standbydatenbank in yaml-Dateien speichern.

  [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

  Ebenso können Sie mit dem folgenden Befehl eine Kopie der Knotenkonfiguration in jeder Site erstellen:

  [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
  

Dieses Lösungshandbuch enthält ein Beispiel für die Verwendung von Kubernetes-Clustern, die mit dem Tool kubeadm erstellt wurden. Die Empfehlungen sind generisch 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 mit derselben etcd- und Kubernetes-Version bereitgestellt werden. Die Wiederherstellung von etcd-Snapshots über verschiedene Kubernetes-Versionen hinweg kann zu Inkonsistenzen und instabilen etcd-Clustern führen.

Erforderliche Produkte und Rollen

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

• Kubernetes-Cluster
• Bastion, die in der Lage ist, den Kubernetes-Systemzugriff auf die etcd-Endpunkte des Clusters zu verwalten und mit ssh auf die verschiedenen Control-Plane-Knoten zuzugreifen
• (Optional) Oracle Cloud Infrastructure (OCI)

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

Dies sind die Rollen, die für jeden Service erforderlich sind.

Servicename: Rolle	Erforderlich für...
Kubernetes-Cluster (primär): administrator	Führen Sie alle Skripte aus.
Kubernetes-Knoten (primä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
Kubernetes-Cluster (sekundär): administrator	Führen Sie alle Skripte aus.
Kubernetes-Knoten (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

Weitere Informationen finden Sie unter Oracle-Produkte, -Lösungen und -Services.