A imagem mostra um diagrama de arquitetura de uma configuração de recuperação de desastre do Kubernetes multirregional.

Há duas regiões: Região 1 - Principal e Região 2 - Secundária. Um Serviço de Nome de Domínio (DNS), 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á uma comunicação bidirecional entre o DNS e myk8sapp.example.com.

Cada região tem Balanceador de Carga, um Cluster do 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 Região 2 está conectado ao myk8sapp.example.com.

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

Controlador de Entrada: Os dados fluem 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 do Oracle RAC.
Plano de Controle do Kubernetes com três planos de controle (ci-cp1, cci-cp2 e ci-cp3) e três instâncias ETCD. Os nós do Plano de Controle do Kubernetes estão conectados à API do Kube.

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

Na Região 1, o Plano de Controle usa a API do Kube para enviar snapshots a Snapshots YAML. Os Snapshots YAML da Região 1 fluem para os Snapshots YAML da Região 2 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, em seguida, para o Plano de Controle do Kubernetes da Região 2.