En la imagen se muestra un diagrama de arquitectura de una configuración de recuperación ante desastres de Kubernetes en varias regiones.

Hay dos regiones: Región 1 - Primaria y Región 2 - Secundaria. Un servicio de nombres de dominio (DNS), una aplicación de kubernetes (myk8sapp.example.com) y un registro de contenedor para otros registros de contenedor externos están fuera de las regiones. Existe una comunicación bidireccional entre el DNS y myk8sapp.example.com.

Cada región tiene un equilibrador de carga, un cluster de Kubernetes, un registro de contenedor, una base de datos Oracle RAC, copias de seguridad ETCD, instantáneas de YAML, una API de Kube y un gateway de enrutamiento dinámico (DRG). Hay una comunicación bidireccional entre los DRG en cada región. El equilibrador de carga de la región 1 y la región 2 están conectados a myk8sapp.example.com.

El cluster de Kubernetes de cada región contiene lo siguiente:

En la región 1, los datos de la base de datos Oracle RAC fluyen a través de Oracle Data Guard hasta la base de datos Oracle RAC en la región 2.

En la región 1, el plano de control utiliza la API de Kube para enviar instantáneas a instantáneas de YAML. Las instantáneas de YAML de la región 1 fluyen a las instantáneas de YAML de la región 2 y, a continuación, a la API de Kube de la región 2.

En la región 1, el plano de control envía copias de seguridad a las copias de seguridad ETCD. Las copias de seguridad ETCD de la región 1 fluyen a las copias de seguridad ETCD de la región 2 y, a continuación, al plano de control de Kubernetes de la región 2.