L'image présente un diagramme d'architecture d'une configuration de récupération après sinistre Kubernetes multi-région.

Il existe deux régions : Région 1 - Principal et Région 2 - Secondaire. Un service de noms de domaine (DNS), une application kubernetes (myk8sapp.example.com) et un registre de conteneurs pour les autres registres de conteneurs externes se trouvent en dehors des régions. Il existe une communication bidirectionnelle entre le DNS et myk8sapp.example.com.

Chaque région dispose d'un équilibreur de charge, d'un cluster Kubernetes, d'un registre de conteneurs, d'une base de données Oracle RAC, de sauvegardes ETCD, de clichés YAML, d'une API Kube et d'une passerelle de routage dynamique (DRG). Il existe une communication bidirectionnelle entre les passerelles de routage dynamique de chaque région. L'équilibreur de charge des régions 1 et 2 est connecté à myk8sapp.example.com.

Le cluster Kubernetes de chaque région contient les éléments suivants :

Dans la région 1, les données de la base de données Oracle RAC circulent via Oracle Data Guard vers la base de données Oracle RAC dans la région 2.

Dans la région 1, le plan de contrôle utilise l'API Kube pour envoyer des instantanés aux instantanés YAML. Les instantanés YAML de la région 1 circulent vers les instantanés YAML de la région 2, puis vers l'API Kube de la région 2.

Dans la région 1, le plan de contrôle envoie des sauvegardes aux sauvegardes ETCD. Les sauvegardes ETCD de la région 1 sont transmises aux sauvegardes ETCD de la région 2, puis au plan de contrôle Kubernetes de la région 2.