Quelle stratégie DR pour Kubernetes ?

On m'a récemment demandé :

Quelle est la stratégie de reprise après sinistre que vous avez mise en œuvre pour vos clusters Kubernetes ?

Et ma réponse est toujours la même : allez léger, réchauffez-vous ou rentrez chez vous. Bien que cela dépende du budget, du RPO et du RTO de l'activité sous-jacente, la plupart du temps, la lumière ou la chaleur suffisent.

Alors, à quoi faites-vous référence exactement ?

Retournons à l'origine de la reprise après sinistre dans AWS en utilisant cette image pour décrire les principales options possibles :

Pour comprendre chaque option, nous devons replacer le contexte d'une catastrophe. Disons que le désastre est aussi simple que la région dans laquelle votre cluster Kubernetes est exécuté est en panne. Et maintenant ?

Sauvegarde et amp; Restaurer

Cette approche implique d'effectuer périodiquement des sauvegardes des configurations de votre cluster, y compris les données, les configurations de déploiement et d'autres paramètres pertinents. À l'aide des services AWS, vous pouvez utiliser Amazon S3 pour stocker des instantanés et des volumes EBS, ainsi qu'ECR pour les images de conteneurs.

Exemple avec EKS : En supposant que les données de votre cluster EKS résident dans des volumes EBS, vous pouvez prendre des instantanés réguliers de ces volumes et les stocker dans S3. Si la région dans laquelle votre cluster EKS fonctionne tombe en panne, vous devez d'abord configurer un nouveau cluster EKS dans une autre région, puis restaurer les volumes à partir de vos instantanés. Vous devrez également redéployer vos applications à l'aide des configurations et des images de conteneurs que vous avez sauvegardées.

Voyant lumineux

Pour EKS, cela signifierait que votre cluster s'exécute en permanence dans une autre région avec une empreinte minimale. Les services essentiels, notamment la couche de données, sont répliqués.

Exemple avec EKS : vous auriez un cluster EKS plus petit exécuté dans une autre région, avec des services critiques tels que des bases de données en modes de réplication. AWS RDS, par exemple, peut être configuré dans le cadre d'une réplication interrégionale. Si votre cluster principal tombe en panne, vous devez augmenter ce cluster, rediriger le trafic (peut-être en utilisant Route 53 avec des contrôles d'état), et il prendra le relais.

Veille chaude

Avec EKS, cela équivaudrait à avoir un clone entièrement fonctionnel de votre environnement de production, mais réduit.

Exemple avec EKS : dans une autre région, vous auriez un cluster EKS avec les mêmes configurations que votre cluster principal, mais réduit. Les services clés seraient en veille ou fonctionneraient dans des versions réduites. En cas de sinistre dans la région principale, ce cluster peut rapidement évoluer pour gérer la totalité de la charge de production. Des services tels que les groupes AWS Auto Scaling seraient cruciaux dans cette stratégie.

Actif-Actif

Pour EKS, cela impliquerait d'avoir plusieurs clusters EKS dans différentes régions, tous desservant le trafic simultanément.

Exemple avec EKS : vous exécuteriez des clusters EKS dans deux régions ou plus avec un accélérateur global ou un équilibreur de charge multirégional comme Route 53 acheminant le trafic vers chacune d'entre elles. La réplication et la synchronisation des données deviennent ici cruciales, surtout si vous exécutez des applications avec état. Les services AWS tels que DynamoDB Global Tables ou la réplication RDS inter-régions seraient des composants importants.

Pourquoi je suggère Pilot ou Warm ?

Les méthodes de veilleuse et de veille chaude offrent un équilibre entre le coût et la vitesse de récupération. Ils ne sont pas aussi coûteux que l'exécution d'une configuration active-active, mais ils offrent une récupération plus rapide qu'une simple méthode de sauvegarde et de restauration. En fonction de vos exigences spécifiques en matière de RTO et de RPO, ainsi que de votre budget, ces méthodes constituent un terrain d'entente qui fonctionne pour de nombreuses entreprises.

Votre décision

Votre choix doit tenir compte de la rapidité avec laquelle vous devez récupérer (RTO) et de la quantité de données que vous pouvez vous permettre de perdre (RPO). Avec EKS, des éléments tels que l'état du cluster, les configurations des applications et les données doivent être pris en compte. En outre, AWS propose divers outils et services, depuis les solutions de sauvegarde jusqu'au routage et à la mise à l'échelle du trafic, qui peuvent vous aider à mettre en œuvre la stratégie que vous avez choisie.