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

Il existe deux régions : la région 1 - primaire et la 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 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, d'instantané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 dans chaque région. L'équilibreur de charge dans les régions 1 et 2 est connecté à myk8sapp.example.com.

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

Dans la région 1, les données de la base de données Oracle RAC transitent par Oracle Data Guard vers la base de données Oracle RAC de la région 2.

Dans la région 1, le plan de contrôle utilise l'API Kube pour envoyer des clichés aux clichés YAML. Les clichés YAML de la région 1 sont transmis aux clichés YAML de la région 2, puis à 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 acheminées vers les sauvegardes ETCD de la région 2, puis vers le plan de contrôle Kubernetes de la région 2.