Die Abbildung zeigt ein Architekturdiagramm einer Kubernetes-Disaster Recovery-Konfiguration mit mehreren Regionen.

Es gibt zwei Regionen: Region 1 - Primär und Region 2 - Sekundär. Ein Domain Name Service (DNS), eine Kubernetes-Anwendung (myk8sapp.example.com) und eine Container Registry für andere externe Container-Registrys befinden sich außerhalb der Regionen. Es gibt eine wechselseitige Kommunikation zwischen DNS und myk8sapp.example.com.

Jede Region verfügt über Load Balancer, ein Kubernetes-Cluster, eine Container Registry, eine Oracle RAC-Datenbank, ETCD-Backups, YAML-Snapshots, eine Kube-API und ein dynamisches Routinggateway (DRG). Zwischen den DRGs in jeder Region besteht eine wechselseitige Kommunikation. Der Load Balancer in Region 1 und Region 2 ist mit myk8sapp.example.com verbunden.

Das Kubernetes-Cluster in jeder Region enthält Folgendes:

Ingress-Controller: Datenflüsse vom Ingress-Controller zum Load Balancer.
Kubernetes-Worker-Knoten mit 3 Knoten (ci-w1, ci-w2 und ci-w3). Die Kubernetes-Worker-Knoten sind mit dem Ingress Controller und mit der Oracle RAC-Datenbank verbunden.
Kubernetes-Control Plane mit drei Control Planes (ci-cp1, cci-cp2 und ci-cp3) und drei ETCD-Instanzen. Die Kubernetes-Control-Plane-Knoten sind mit der Kube-API verbunden.

In Region 1 fließen Daten aus Oracle RAC Database über Oracle Data Guard in die Oracle RAC-Datenbank in Region 2.

In Region 1 verwendet die Control Plane die Kube-API, um Snapshots an YAML-Snapshots zu senden. YAML-Snapshots von Region 1 werden in YAML-Snapshots von Region 2 und dann in die Kube-API von Region 2 übertragen.

In Region 1 sendet die Control Plane Backups an ETCD-Backups. ETCD-Backups in Region 1 fließen zu ETCD-Backups in Region 2 und dann zur Kubernetes-Control Plane von Region 2.