L'illustration présente un diagramme d'architecture d'une configuration de récupération après sinistre Kubernetes multirégionale.
Il existe deux régions : Région 1 - Principale et Région 2 - Secondaire. Un service de noms de domaine (DNS), une application kubernetes (myk8sapp.example.com) et un registre de conteneurs pour d'autres registres de conteneurs externes sont 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'une grappe Kubernetes, d'un registre de conteneurs, d'une base de données Oracle RAC, de sauvegardes ETCD, d'instantanés YAML, d'une API Kube et d'une passerelle de routage dynamique. Il existe une communication bidirectionnelle entre les passerelles de routage dynamique dans chaque région. L'équilibreur de charge des régions 1 et 2 est connecté à myk8sapp.example.com.
Dans la région 1, les données d'Oracle RAC Database transitent par 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 sont dirigés 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 les sauvegardes aux sauvegardes ETCD. Les sauvegardes ETCD de la région 1 sont dirigées vers les sauvegardes ETCD de la région 2, puis vers le plan de contrôle Kubernetes de la région 2.