L'immagine mostra un diagramma dell'architettura di una configurazione di disaster recovery Kubernetes multiregione.

Ci sono due regioni: Regione 1 - Primaria e Regione 2 - Secondaria. Un servizio DNS (Domain Name Service), un'applicazione kubernetes (myk8sapp.example.com) e un registro dei container per altri registri dei container esterni si trovano al di fuori delle aree geografiche. C'è una comunicazione bidirezionale tra il DNS e myk8sapp.example.com.

Ogni area dispone di un load balancer, un cluster Kubernetes, un registro dei container, un database Oracle RAC, backup ETCD, snapshot YAML, un'API Kube e un gateway di instradamento dinamico (DRG). C'è una comunicazione bidirezionale tra i DRG in ogni regione. Il load balancer nell'area 1 e nell'area 2 è connesso a myk8sapp.example.com.

Il cluster Kubernetes in ogni area contiene gli elementi riportati di seguito.

Controller di ingresso: flussi di dati dal controller di ingresso al load balancer.
Nodi di lavoro Kubernetes con 3 nodi (ci-w1, ci-w2 e ci-w3). I nodi di lavoro Kubernetes sono connessi al controller in entrata e al database Oracle RAC.
Piano di controllo Kubernetes con tre piani di controllo (ci-m1, ci-m2 e ci-m3) e tre istanze ETCD. I nodi del piano di controllo Kubernetes sono connessi all'API Kube.

Nell'area 1, i dati del database Oracle RAC passano attraverso Oracle Data Guard al database Oracle RAC nell'area 2.

Nell'area 1, il piano di controllo utilizza l'API Kube per inviare snapshot agli snapshot YAML. Gli snapshot YAML dell'area 1 passano agli snapshot YAML dell'area 2 e quindi all'API Kube dell'area 2.

Nell'area 1, il piano di controllo invia i backup ai backup ETCD. I backup ETCD dell'area 1 passano ai backup ETCD dell'area 2 e quindi al piano di controllo Kubernetes dell'area 2.