L'immagine mostra un diagramma dell'architettura di una configurazione di recupero da errori irreversibili Kubernetes a più aree.

Esistono due aree: Area 1 - Primario e Area 2 - Secondaria. Un servizio DNS (Domain Name Service), un'applicazione kubernetes (myk8sapp.example.com) e un registro dei container per altri registri di container esterni si trovano al di fuori delle aree. Esiste una comunicazione bidirezionale tra DNS e myk8sapp.example.com.

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

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

Controller in entrata: i dati passano dal controller in entrata 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, and 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 poi 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.