En savoir plus sur la restauration de clusters Kubernetes basée sur des clichés etcd

Pour assurer la continuité des activités en cas de sinistre, vous devez implémenter une stratégie de récupération après sinistre pour les applications exécutées sur les clusters Kubernetes. Utilisez ces recommandations Oracle Maximum Availability Architecture (Oracle MAA) qui fournissent la protection des données et vous permettent de passer rapidement à un système de secours avec une perte minimale de données et de productivité.

Malgré l'énorme changement que l'adoption d'Kubernetes implique pour l'architecture du système informatique, un système Kubernetes présente des paradigmes de récupération après sinistre similaires à ceux d'une application traditionnelle (comme Oracle Java SE, Oracle Java EE ou JavaScript). Il doit conserver une copie cohérente et "aussi à jour que possible" de votre système principal dans un emplacement secondaire qui peut reprendre les charges de travail en cas de sinistre entraînant un temps d'inactivité dans la région principale.

Ce guide de solution fournit des recommandations et des utilitaires Oracle MAA qui créent un système Kubernetes secondaire et vous permettent de récupérer dans des scénarios de sinistre affectant un emplacement et forçant la redirection des charges de travail vers un site de réplique.

Bien que ce guide de solutions se concentre sur la restauration d'un cluster Kubernetes dans une autre région, vous pouvez utiliser les mêmes scripts et procédures pour restaurer un cluster sur place jusqu'à un point dans le temps antérieur. Cette opération peut être utile dans d'autres scénarios que la récupération après sinistre, par exemple :

Lorsque le plan de contrôle est mal configuré.
Lorsque la base de données etcd est perdue, corrompue ou quand etcd ne se présente pas correctement.
Lorsqu'une erreur de déploiement ou d'utilisateur incorrecte affecte plusieurs applications ou microservices et que le cluster doit être rétabli vers une version ou une incarnation précédente. Une restauration de cliché ETCD rétablit tous les artefacts jusqu'au moment où le cliché (sauvegarde) a été pris.

Ce document se concentre sur la réplication des données etcd de Kubernetes vers un emplacement secondaire. Toutes les informations d'un cluster Kubernetes sont stockées dans etcd, qui est un fichier de valeurs de clé utilisé comme magasin de sauvegarde de Kubernetes pour les données du cluster. Ce livre de jeux de solution fournit des recommandations pour répliquer un cluster Kubernetes créé avec l'outil kubeadm Kubernetes (reportez-vous à https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) en fonction de la restauration etcd. Les procédures de configuration et les scripts fournis peuvent nécessiter des personnalisations pour d'autres types de cluster (ceux qui ne sont pas créés avec kubeadm), mais en général, sont valides tant que le plan de contrôle d'Kubernetes utilise l'accès aux adresses etcd. Cette solution de réplication nécessite une configuration spécifique pour le cluster secondaire et utilise une copie des clichés etcd (également appelés instantanés etcd) pour afficher exactement les mêmes artefacts qui existaient dans le cluster principal.

Vous pouvez utiliser des instantanés d'artefact ou des outils de sauvegarde Kubernetes tiers pour répliquer des espaces de noms et des applications spécifiques sur des systèmes Kubernetes. Cependant, ils ne protègent pas les clusters des corruptions de fichier et des erreurs de configuration dans les métadonnées du plan de contrôle. En plus de les utiliser pour la protection contre les sinistres, vous pouvez utiliser des instantanés etcd pour les restaurations locales et rétablir les clusters Kubernetes à un point de travail antérieur dans le temps. Si votre magasin etcd et votre système de cluster etcd sont en mauvais état, les applications peuvent continuer à s'exécuter mais les transferts de pod, les modifications de configuration, l'accès secret et toute autre opération nécessitant la disponibilité du plan de contrôle ne fonctionneront pas correctement. C'est pour cette raison que la conservation etcd doit faire partie intégrante des procédures de cycle de vie des clusters Kubernetes.

Outre les données de configuration Kubernetes, les applications et les microservices exécutés sur Kubernetes peuvent générer des données lors de l'exécution. La protection contre les sinistres des données d'exécution n'est pas traitée dans ce document et doit être traitée exactement de la même manière que dans les applications traditionnelles exécutées sur des serveurs d'applications :

Eviter la persistance Polyglot (l'utilisation de différents types de magasins persistants pour les données d'exécution est "presque" impossible à résoudre le problème selon le théorème BAC)
Utiliser un espace de stockage unique pour tous les différents types de données, microservices et applications avec des dépendances autant que possible
Reportez-vous à Meilleures pratiques Oracle MAA pour Oracle Database pour la protection contre les sinistres de votre exécution

Avant de commencer

Plusieurs présentations techniques d'Oracle Maximum Availability Architecture (MAA) décrivent la configuration d'un système de récupération après sinistre pour les systèmes middleware traditionnels. Ces documents détaillent les exigences en matière de protection contre les sinistres pour les composants d'infrastructure externe (tels que le stockage, les équilibreurs de charge et la base de données) utilisés par les applications Kubernetes.

Pour plus de détails, vérifiez les points suivants :

Architecture

Cette architecture présente la topologie du système de récupération après sinistre pour le cluster Kubernetes.

Toutes les informations d'exécution, de configuration et de métadonnées résidant dans la base de données principale sont répliquées de la région 1 vers la région 2 avec Oracle Autonomous Data Guard. La configuration de cluster Kubernetes requise est répliquée via des instantanés etcd pour la protection du plan de contrôle. Vous pouvez utiliser des copies etcd ou des clichés d'artefact pour la protection de configuration propre à l'application. Pour plus d'informations, reportez-vous à Utilisation d'instantanés d'artefact pour protéger vos clusters Kubernetes contre les sinistres. Les images utilisées par les conteneurs sont hébergées dans des registres locaux pour chaque cluster ou dans des référentiels externes (les images ne sont pas considérées comme une configuration de cluster Kubernetes par elles-mêmes).

Remarque :

La configuration d'Oracle Autonomous Data Guard pour la base de données d'exécution est hors de portée de ce document.

Description de l'image kubernetes-etcd-multiregion-dr.png

Description de l'illustration kubernetes-etcd-multiregion-dr.png

kubernetes-etcd-multiregion-dr-oracle.zip

Cette architecture prend en charge les composants suivants :

Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
Programme d'équilibrage de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatisée à partir d'un seul point d'entrée vers plusieurs serveurs du back-end.
Dynamic routing gateway (DRG)
L'DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux cloud virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
Data Guard
Oracle Data Guard fournit un ensemble complet de services permettant de créer, de tenir à jour, de gérer et de surveiller des bases de données de secours afin que les bases de données Oracle de production restent disponibles sans interruption. Oracle Data Guard gère ces bases de données de secours en tant que copies de la base de données de production. Ensuite, si la base de données de production devient indisponible en raison d'une panne planifiée ou non planifiée, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'arrêt associé à la panne.
Oracle Real Application Clusters (Oracle RAC)
Oracle RAC vous permet d'exécuter une seule base de données Oracle Database sur plusieurs serveurs pour maximiser la disponibilité et activer l'évolutivité horizontale tout en accédant au stockage partagé. Les sessions utilisateur se connectant aux instances Oracle RAC peuvent basculer et réexécuter les modifications en toute sécurité pendant les pannes, sans apporter de modifications aux applications de l'utilisateur final.
Registre du conteneur
Oracle Cloud Infrastructure Registry est un registre géré par Oracle qui vous permet de simplifier votre workflow du développement jusqu'à la production. Registry facilite le stockage, le partage et la gestion des artefacts et des images de développement. L'architecture hautement disponible et évolutive d'Oracle Cloud Infrastructure vous garantit un déploiement et une gestion fiables de vos applications.
Container Engine for Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetes est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications en conteneur vers le cloud. Indiquez les ressources de calcul dont vos applications ont besoin et Container Engine for Kubernetes les provisionne sur Oracle Cloud Infrastructure dans une location existante. Container Engine for Kubernetes utilise Kubernetes pour automatiser le déploiement, le redimensionnement et la gestion des applications en conteneur sur des clusters d'hôtes.
Cluster Kubernetes
Un cluster Kubernetes est un ensemble de machines qui exécutent des applications en conteneur. Kubernetes fournit une plate-forme open source extensible et portable permettant de gérer les charges de travail et les services en conteneur dans ces noeuds. Un cluster kubernetes est formé de noeuds de processus actif et de noeuds de plan de contrôle.
Plan de contrôle Kubernetes
Un plan de contrôle Kubernetes gère les ressources pour les noeuds de processus actif et les pods au sein d'un cluster Kubernetes. Les composants du plan de contrôle détectent les événements, effectuent la planification et déplacent les ressources du cluster et y répondent. Les composants de plan de contrôle sont les suivants :
- kube-apiserver : exécute le serveur d'API Kubernetes.
- etcd : banque clé-valeur distribuée pour toutes les données de cluster.
- kube-scheduler : détermine sur quel noeud les nouveaux pods non affectés seront exécutés.
- kube-controller-manager : exécute les processus du contrôleur.
- cloud-controller-manager : lie votre cluster à une API propre au cloud.
Noeud de processus actif Kubernetes
Un noeud de processus actif Kubernetes est une machine de processus actif qui exécute des applications en conteneur dans un cluster Kubernetes. Chaque cluster comporte au moins un noeud de processus actif.
Contrôleur entrant
Un contrôleur entrant est un composant qui s'exécute dans un cluster Kubernetes et gère les ressources entrantes. Il reçoit le trafic du réseau externe, l'achemine vers le bon service et effectue l'équilibrage de charge et la terminaison SSL. Le contrôleur entrant s'exécute généralement en tant que pod distinct dans le cluster et peut être mis à l'échelle indépendamment des services qu'il gère.
API KUBE-Endpoint
L'API KUBE-Endpoint est le composant kube-apiserver du plan de contrôle Kubernetes. Il exécute le serveur d'API Kubernetes.
Sauvegarde ETCD
La sauvegarde ETCD est une sauvegarde du composant etcd du plan de contrôle Kubernetes. etcd contient la banque clé-valeur distribuée pour toutes les données de cluster. Il est important de créer une sauvegarde ETCD pour récupérer les clusters Kubernetes en vue d'une récupération après sinistre.
Clichés YAML
Un cliché YAML est une copie ponctuelle des fichiers (yaml) contenant la définition des artefacts dans un cluster Kubernetes. Le cliché est un fichier tar que vous pouvez utiliser pour restaurer ces artefacts dans le même cluster Kubernetes ou dans un autre.

Remarques concernant la protection contre les sinistres de Kubernetes

Lors de l'implémentation de la protection contre les sinistres pour Kubernetes, tenez compte des points suivants :

Récupération après sinistre symétrique : Oracle recommande d'utiliser exactement la même capacité et la même configuration de ressource dans le primaire et le secondaire. Les clusters Kubernetes des deux régions doivent disposer de ressources similaires, telles que le nombre de noeuds de processus actif (et leur capacité matérielle) et d'autres infrastructures (stockage partagé, équilibreurs de charge, bases de données, etc.). Les ressources dont dépend le cluster Kubernetes dans la région secondaire doivent pouvoir faire face aux mêmes charges de travail que les charges de travail principales. En outre, les deux systèmes doivent être cohérents sur le plan fonctionnel avec les mêmes services dont dépend le système restauré, les voitures latérales et les cartes de configuration (CM) doivent être utilisées dans les deux emplacements.
Alias de nom d'hôte et virtualisation : il est important de planifier les noms d'hôte utilisés par les noeuds du site secondaire. Les noms d'hôte ou d'alias des noeuds de plan de contrôle et de processus actif doivent être "actifs" dans l'emplacement secondaire avant de restaurer un cliché etcd à partir d'un cluster Kubernetes principal. Les noms de noeud sont stockés dans différents artefacts d'un cluster Kubernetes pour identifier les noeuds de processus actif, marquer les allocations de pod, dans les mappes de configuration décrivant le cluster lui-même et dans plusieurs fichiers de configuration et entrées. Votre emplacement secondaire doit identifier les adresses de processus actif, de plan de contrôle et de système frontal kube-api avec les mêmes noms d'hôte que ceux utilisés dans le cluster Kubernetes principal (un nom qualifié complet peut être différent dans le nom de domaine, mais le nom d'hôte doit être identique. Sans alias de nom d'hôte, une restauration d'instantané etcd ne fonctionnera pas correctement car les kubelets, les planificateurs, les contrôleurs et, en général, les services de plan de contrôle ne pourront pas atteindre les adresses et hôtes appropriés utilisés par la configuration répliquée. N'utilisez pas d'adresses IP pour identifier les noeuds dans kubernetes, utilisez toujours des noms d'hôte à la place.
Les images de conteneur présentent un paradigme similaire aux fichiers binaires : les images peuvent ne pas changer aussi souvent que la configuration Kubernetes et vous n'avez peut-être pas besoin de mettre à jour les images avec chaque réplication de cluster Kubernetes. Les images utilisées par le système principal doivent être identiques à celles utilisées dans le système secondaire, ou des incohérences et une défaillance peuvent se produire. Cependant, la réplication d'image est hors de portée de ce livre de jeux. Plusieurs stratégies peuvent être utilisées pour maintenir une utilisation cohérente des images entre deux emplacements, notamment :
- Enregistrez les images dans le noeud principal et chargez-les vers les noeuds de processus actif du noeud secondaire. Cette approche est très facile à mettre en œuvre, mais implique des frais généraux de gestion. L'utilisation de registres de conteneurs présente des avantages considérables et l'enregistrement d'images localement rend plus difficile la gestion des versions et des mises à jour.
- Les images peuvent résider dans des registres de conteneurs totalement externes dans différentes régions ou centres de données à partir de ceux utilisés par la base de données principale et la base de données de secours. Les produits et bibliothèques externes sont gérés par des tiers et leur disponibilité est généralement implicite dans leurs versions.
- Les images peuvent se trouver dans des registres de conteneurs situés en tant que fichiers principal et de secours. Chaque région est mise à jour en parallèle lorsqu'une nouvelle version d'une image est publiée. Cela permet de mieux contrôler le logiciel utilisé, mais entraîne des frais de gestion plus élevés. Il faut dupliquer les images et gérer les informations d'identification pour accéder à deux registres différents. Les outils d'intégration continue et de déploiement continu sont généralement utilisés pour cette approche.

Ce livre de jeux de solution présente un exemple d'utilisation des clusters Kubernetes créés à l'aide de l'outil kubeadm. Les recommandations sont génériques aux clusters Kubernetes personnalisés installés dans les systèmes sur site, mais la plupart des scripts peuvent nécessiter des modifications pour les clusters qui ne sont pas créés avec l'outil kubeadm. Vous devez utiliser les étapes et les scripts fournis entre les clusters Kubernetes exécutant les mêmes versions etcd et Kubernetes. La restauration des instantanés etcd sur différentes versions de kubernetes peut entraîner des incohérences et des clusters etcd instables.

A propos des produits et rôles requis

Cette solution requiert les produits et rôles suivants :

Cluster Kubernetes
Bastion capable de gérer le système Kubernetes accède aux adresses etcd du cluster et accède aux différents noeuds de plan de contrôle avec ssh
(Facultatif) Oracle Cloud Infrastructure (OCI)
Ce livre de jeux repose sur l'utilisation des régions et des ressources OCI pour les régions principale et secondaire. Cependant, cette solution est également applicable aux clusters Kubernetes situés sur site.

Il s'agit des rôles nécessaires pour chaque service.

Nom de service : rôle	Obligatoire pour...
Cluster Kubernetes (principal) : `administrator`	Exécuter tous les scripts.
Noeuds Kubernetes (principaux) : utilisateur disposant de droits sudo sur root	exécuter les scripts suivants : `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Cluster Kubernetes (secondaire) : `administrator`	Exécuter tous les scripts.
Noeuds Kubernetes (secondaires) : utilisateur disposant de droits sudo sur root	exécuter les scripts suivants : `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

Pour obtenir tout ce dont vous avez besoin, reportez-vous à Produits, solutions et services Oracle.