A imagem mostra um diagrama de arquitetura de uma configuração de recuperação de desastres do Kubernetes com várias opções.

Há duas regiões: Região 1 - Principal e Região 2 - Secundária. Um DNS (Domain Name Service), um aplicativo kubernetes (myk8sapp.example.com) e um Registro de Contêiner para outros registros de contêiner externos estão fora das regiões. Há comunicação bidirecional entre o DNS e myk8sapp.example.com.

Cada região tem Balanceador de Carga, um Cluster Kubernetes, um Registro de Contêiner, um Banco de Dados Oracle RAC, Backups ETCD, Snapshots YAML, uma API Kube e um gateway de roteamento dinâmico (DRG). Há comunicação bidirecional entre os DRGs em cada região. O Balanceador de Carga na Região 1 e na Região 2 está conectado ao myk8sapp.example.com.

O Cluster do Kubernetes em cada região contém o seguinte:

Controlador de Entrada: Fluxos de dados do Controlador de Entrada para o Balanceador de Carga.
Nós de Trabalho do Kubernetes com 3 nós (ci-w1, ci-w2 e ci-w3). Os Nós de Trabalho do Kubernetes são conectados ao Controlador de Entrada e ao Banco de Dados Oracle RAC.
Plano de Controle do Kubernetes com três planos de controle (ci-m1, ci-m2 e ci-m3) e três instâncias ETCD. Os nós do Plano de Controle do Kubernetes são conectados à API do Kube.

Na Região 1, os dados do Oracle RAC Database fluem pelo Oracle Data Guard para o Oracle RAC Database na Região 2.

Na Região 1, o Plano de Controle usa a API do Kube para enviar snapshots para Snapshots do YAML. Os Snapshots da Região 1 YAML fluem para os Snapshots da Região 2 YAML e, em seguida, para a API Kube da Região 2.

Na Região 1, o Plano de Controle envia backups para Backups ETCD. Os Backups ETCD da Região 1 fluem para Backups ETCD da Região 2 e depois para o Plano de Controle Kubernetes da Região 2.