Mit Artefakt-Snapshots Ihre OCI-Kubernetes-Engine-Cluster vor Katastrophen schützen
Oracle Maximum Availability Architecture (Oracle MAA) bietet Empfehlungen und Dienstprogramme, mit denen Sie in Disaster-Szenarios, die sich auf einen Standort auswirken, ein Recovery durchführen und die Umleitung von Workloads zu einem Replikatsite erzwingen können. Der Schwerpunkt dieses Inhalts liegt auf der Kubernetes-Konfigurationsreplikation für Anwendungen. Anwendungen, die auf Kubernetes-Clustern ausgeführt werden, sind für den Betrieb von vielen verschiedenen Komponenten abhängig, 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 dar wie herkömmliche Anwendungen. Während Laufzeitanwendungen können persistente Daten generiert, gelesen und aktualisiert werden. Dieses Lösungshandbuch enthält Empfehlungen zum Replizieren der Konfiguration einer Anwendung, die auf Kubernetes ausgeführt wird. Der Katastrophenschutz von Laufzeitdaten liegt außerhalb des Geltungsbereichs dieses Dokuments und sollte genauso behandelt werden wie bei herkömmlichen Anwendungen, die auf Anwendungsservern ausgeführt werden, einschließlich:
- Vermeiden Sie mehrsprachige Persistenz. Die Verwendung verschiedener Arten von persistenten Speichern für Laufzeitdaten ist gemäß dem BAC-Theorem (Backup Availability Consistency) fast 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.
Darüber hinaus müssen Sie die Kubernetes-Cluster-Control Plane schützen. Verwenden Sie die entsprechenden etcd-Snapshots, um Beschädigungen und Fehler zu vermeiden und einen Flashback für funktionsfähige Cluster bereitzustellen. Obwohl Oracle MAA Best Practices für den Schutz der Control Plane vor Katastrophen bereitstellt, liegt es außerhalb des Umfangs dieses Dokuments, die erforderlichen Techniken in diesem Bereich zu beschreiben.
Bevor Sie beginnen
Weitere Informationen finden Sie im Folgenden:
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-(K8s-)Clusterkonfiguration wird über ETCD-Snapshots zum Schutz der Control Plane 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 Kubernetes-Cluster werden basierend auf etcd-Snapshots wiederhergestellt. Die Images, die der Container verwendet, werden in Registrys gehostet, entweder lokal in jedem Cluster oder in externen Repositorys (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-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-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
Oracle Cloud Infrastructure Load Balancing bietet eine automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server.
- 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-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.
- 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.
- 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-apiserverder Kubernetes-Control Plane. Er führt den Kubernetes-API-Server aus. - ETCD-Backup
ETCD Backup ist ein Backup der Komponente
etcdder Kubernetes-Control Plane. Dieetcdenthä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. 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 (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.
- Images stellen ein ähnliches Paradigma wie Binärdateien dar: 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 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.
Obwohl dieses Handbuch ein Beispiel für die Verwendung von Oracle Cloud Infrastructure darstellt, sind die Empfehlungen generisch 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 der OCI Kubernetes-Engine (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 auch in OKE ausgeführt wird, oder zwischen zwei On-Premise- oder benutzerdefinierten Kubernetes-Clustern verwenden.
Erforderliche Produkte und Rollen
Für diese Lösung sind folgende Produkte und Rollen erforderlich:
- Oracle Cloud Infrastructure Kubernetes Engine-Cluster (Kubernetes Engine oder OKE)
- Bastionknoten, der das kubernetes-System verwalten kann
- 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 ist jedoch auch für Kubernetes-Cluster anwendbar, die sich nicht auf OCI befinden.
Dies sind die Rollen, die für jeden Service erforderlich sind.
| Servicename: Rolle | Erforderlich für... |
|---|---|
Oracle Cloud Infrastructure: admin |
Ressourcen und Services bereitstellen und einrichten, wenn Sie eine oder mehrere OCI-Regionen verwenden. |
Kubernetes-Engine-Cluster (primär): administrator |
Führen Sie alle Skripte aus. |
| Kubernetes Engine (primäre) Knoten: BS-Benutzer mit Ausführungsberechtigungen und SSH-Berechtigungen für sekundäre Knoten |
Folgende Skripts ausführen:
|
Kubernetes-Engine-Cluster (sekundär): administrator |
Führen Sie alle Skripte aus. |
| Kubernetes Engine-(sekundäre) Knoten: BS-Benutzer mit Ausführungsberechtigungen |
Folgende Skripts ausführen:
|
Weitere Informationen finden Sie unter Oracle-Produkte, -Lösungen und -Services.