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 dem 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). In jeder Region besteht eine wechselseitige Kommunikation zwischen den DRGs. 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: Daten fließen 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 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 fließen in YAML-Snapshots von Region 2 und dann in die Kube-API von Region 2.

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