En savoir plus sur la restauration des grappes Kubernetes basée sur les instantanés etcd

Pour assurer la continuité des activités en cas de sinistre, vous devez mettre en oeuvre une stratégie de récupération après sinistre pour les applications exécutées sur des grappes Kubernetes. Utilisez ces recommandations Oracle Maximum Availability Architecture (Oracle MAA) qui assurent 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 de Kubernetes implique pour l'architecture du système informatique, un système Kubernetes présente des paradigmes de reprise après sinistre (DR) similaires à ceux d'une application traditionnelle (comme Oracle Java SE, Oracle Java EE ou JavaScript). Il doit maintenir 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'arrêt dans la région principale.

Ce livre de jeu de solutions fournit des recommandations et des utilitaires Oracle MAA qui créeront un système Kubernetes secondaire et vous permettront de récupérer les données 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 solution se concentre sur la restauration d'une grappe Kubernetes dans une région différente, vous pouvez utiliser les mêmes scripts et procédures pour restaurer une grappe sur place à un point antérieur dans le temps. Cette opération peut être utile dans des scénarios autres que la récupération après sinistre, tels que :

• Lorsque le plan de contrôle est mal configuré.
• Lorsque la base de données etcd est perdue, corrompue ou lorsque etcd ne s'affiche pas correctement.
• Lorsqu'un déploiement incorrect ou une erreur utilisateur affecte plusieurs applications ou microservices et que le cluster doit être rétabli à une version ou une incarnation précédente. Une restauration d'instantané ETCD rétablira tous les artefacts jusqu'au moment où l'instantané (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'une grappe Kubernetes sont stockées dans etcd, qui est un magasin de valeurs de clé utilisé comme magasin de sauvegarde de Kubernetes pour les données de la grappe. Ce livre de jeu de solutions fournit des recommandations pour répliquer une grappe Kubernetes créée avec l'outil kubeadm de Kubernetes (voir https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) basée sur etcd restore. Les procédures et scripts de configuration fournis peuvent nécessiter des personnalisations pour d'autres types de grappe (celles qui ne sont pas créées avec kubeadm), mais sont généralement valides tant qu'il y a accès aux points d'extrémité etcd utilisés par le plan de contrôle de Kubernetes. Cette solution de réplication nécessite une configuration spécifique pour la grappe secondaire et utilisera une copie de etcd (également appelée etcd snapshots) pour afficher exactement les mêmes artefacts qui existaient dans la grappe principale.

Vous pouvez utiliser des instantanés d'artefact ou des outils de sauvegarde Kubernetes de tierce partie pour répliquer des espaces de noms et des applications spécifiques sur les systèmes Kubernetes. Toutefois, ils ne protègent pas les grappes contre les corruptions de fichiers et les 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 etcd snapshots pour les restaurations locales et pour rétablir les grappes Kubernetes à un point de travail antérieur dans le temps. Si votre système etcd store et etcd cluster n'est pas sain, les applications peuvent continuer à s'exécuter, mais les déplacements de pods, 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 pourquoi la conservation de etcd doit être une partie critique des procédures de cycle de vie des grappes Kubernetes.

Outre les données de configuration de Kubernetes, les applications et microservices s'exécutant sur Kubernetes peuvent générer des données lors de l'exécution. La protection contre les sinistres de données lors de l'exécution n'est pas incluse dans le présent 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 :

• Éviter la persistance polyglotte (l'utilisation de différents types de stockage persistants pour les données d'exécution est un problème "presque" impossible à résoudre selon le théorème BAC)
• Utiliser un magasin unique pour tous les types de données, microservices et applications avec des dépendances, dans la mesure du possible
• Voir Meilleures pratiques d'Oracle MAA pour Oracle Database pour la protection contre les sinistres lors de l'exécution

Étapes préliminaires

Plusieurs présentations techniques d'Oracle Maximum Availability Architecture (MAA) décrivent la configuration d'un système de reprise après sinistre pour les systèmes intergiciels traditionnels. Ces documents décrivent en détail les exigences de protection en cas de sinistre pour les composants de l'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, consultez les informations suivantes :

• Récupération après sinistre d'Oracle WebLogic Server for Oracle Cloud Infrastructure
• SOA Suite sur Oracle Cloud Infrastructure Marketplace pour la récupération après sinistre

Voir Utiliser des instantanés d'artefact pour protéger vos grappes OCI Kubernetes Engine contre les sinistres pour plus de détails sur l'utilisation d'instantanés d'artefact pour la protection de la configuration propre à l'application.

Architecture

Cette architecture présente la topologie du système de récupération après sinistre pour la grappe 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 grappe Kubernetes requise est répliquée au moyen d'instantanés etcd pour la protection du plan de contrôle. Vous pouvez utiliser des copies etcd ou des instantanés d'artefact pour la protection de la configuration propre à l'application. Les images utilisées par les conteneurs sont hébergées dans des registres locaux à chaque grappe ou dans des référentiels externes (les images ne sont pas considérées comme une configuration de grappe Kubernetes elles-mêmes).

Note :

La configuration d'Oracle Autonomous Data Guard pour la base de données d'exécution n'est pas incluse dans ce document.

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 un ou plusieurs 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 différents pays ou continents).

• Équilibreur de charge

  Le service Oracle Cloud Infrastructure Load Balancing permet une répartition automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dorsaux.

• Passerelle de routage dynamique (DRG)

  La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux en nuage 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 place ou un réseau d'un autre fournisseur de nuage.

• Data Guard

  Oracle Data Guard et Oracle Active Data Guard fournissent un jeu complet de services qui créent, tiennent à jour, gèrent et surveillent une ou plusieurs bases de données de secours et qui permettent aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard tient à jour ces bases de données de secours en tant que copies de la base de données de production à l'aide de la réplication en mémoire. Si la base de données de production devient indisponible en raison d'une interruption planifiée ou non planifiée, Oracle Data Guard peut remplacer n'importe quelle base de données de secours par le rôle de production, réduisant ainsi le temps d'arrêt associé à l'interruption. Oracle Active Data Guard offre la possibilité supplémentaire de décharger les charges de travail en lecture principalement vers les bases de données de secours et fournit également des fonctions avancées de protection des données.

• 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 permettre une évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur qui se connectent aux instances Oracle RAC peuvent effectuer un basculement et réexécuter les modifications en toute sécurité lors des pannes, sans apporter de modifications aux applications de l'utilisateur final.

• Registre

  Oracle Cloud Infrastructure Registry est un registre géré par Oracle qui vous permet de simplifier votre flux de travail, du développement à la mise en production. Le registre vous permet de stocker, de partager et de gérer facilement des artefacts de développement, tels que des images Docker. L'architecture hautement disponible et évolutive d'Oracle Cloud Infrastructure vous permet de déployer et de gérer vos applications en toute confiance.

• Moteur Kubernetes

  Oracle Cloud Infrastructure Kubernetes Engine pour (Moteur Kubernetes pour OCI ou OKE) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications conteneurisées dans le nuage. Vous indiquez les ressources de calcul dont vos applications ont besoin et Kubernetes Engine les provisionne sur Oracle Cloud Infrastructure dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, l'ajustement et la gestion des applications conteneurisées sur les grappes d'hôtes.

• Grappe Kubernetes

  Une grappe Kubernetes est un ensemble de machines qui exécutent des applications en conteneur. Kubernetes fournit une plate-forme portative, extensible et à code source libre pour la gestion des charges de travail et des services conteneurisés dans ces noeuds. Une grappe Kubernetes est formée de noeuds de travail 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 travail et les pods d'une grappe Kubernetes. Les composants du plan de contrôle détectent les événements et y répondent, effectuent la programmation et déplacent les ressources de la grappe. Voici les composants du plan de contrôle :

  • kube-apiserver : Exécute le serveur d'API Kubernetes.
  • etcd : Stockage clé-valeur distribué pour toutes les données du 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 : relie votre grappe à une API propre au nuage.
• Noeud de travail Kubernetes

  Un noeud de travail Kubernetes est une machine de travail qui exécute des applications conteneurisées dans une grappe Kubernetes. Chaque grappe comporte au moins un noeud de travail.

• Contrôleur de trafic entrant

  Un contrôleur de trafic entrant est un composant qui s'exécute dans une grappe Kubernetes et gère les ressources de trafic entrant. Il reçoit le trafic du réseau externe, l'achemine vers le service approprié et effectue l'équilibrage de charge et la terminaison SSL. Le contrôleur de trafic entrant s'exécute généralement en tant que pod distinct dans la grappe et peut être ajusté indépendamment des services qu'il gère.

• API de point d'extrémité KUBE

  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 le magasin clé-valeur réparti pour toutes les données de grappe. Il est important de créer une sauvegarde ETCD pour récupérer les grappes Kubernetes aux fins de récupération après sinistre.

• Instantanés YAML

  Un instantané YAML est une copie à un instant donné des fichiers (YAML) contenant la définition des artefacts dans une grappe Kubernetes. L'instantané est un fichier TAR que vous pouvez utiliser pour restaurer ces artefacts dans la même grappe Kubernetes ou dans une autre grappe.

Considérations relatives à la protection contre les catastrophes de Kubernetes

Lors de la mise en oeuvre de la protection en cas de sinistre pour Kubernetes, tenez compte des éléments 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 l'instance principale et l'instance secondaire. Les grappes Kubernetes des deux régions doivent avoir des ressources similaires disponibles, telles que le nombre de noeuds de travail (et leur capacité matérielle) et d'autres infrastructures (stockage partagé, équilibreurs de charge, bases de données, etc.). Les ressources dont dépend la grappe Kubernetes dans la région secondaire doivent pouvoir suivre les mêmes charges de travail que la grappe principale. En outre, les deux systèmes doivent être cohérents fonctionnellement avec les mêmes services dont dépend le système restauré, les voitures latérales, les cartes de configuration (CM) doivent être utilisées dans les deux endroits.
• 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 pour le plan de contrôle et les noeuds de travail doivent être "actifs" dans l'emplacement secondaire avant la restauration d'un instantané etcd à partir d'une grappe Kubernetes principale. Les noms de noeud sont stockés dans différents artefacts d'une grappe Kubernetes pour identifier les noeuds de travail, marquer les affectations de pods, dans des mappages de configuration décrivant la grappe elle-même et dans plusieurs fichiers de configuration et entrées. Votre emplacement secondaire doit identifier les adresses kube-api de traitement, de plan de contrôle et frontales avec les mêmes noms d'hôte utilisés dans la grappe Kubernetes principale (un nom complet peut différer dans le nom de domaine, mais le nom d'hôte doit être le même). Sans alias de nom d'hôte, une restauration d'instantané etcd ne fonctionnera pas correctement car les kubelets, les programmateurs, les contrôleurs et, en général, les services de plan de contrôle ne pourront pas atteindre les points d'extrémité et hôtes appropriés utilisés par la configuration répliquée. N'utilisez pas d'adresses IP pour identifier les noeuds de Kubernetes. Utilisez toujours des noms d'hôte à la place.
• Les images présentent un paradigme similaire aux fichiers binaires : Il est possible que les images ne changent pas aussi fréquemment que la configuration de Kubernetes et que vous n'ayez pas besoin de mettre à jour les images avec chaque réplication de grappe Kubernetes. Les images utilisées par le système principal doivent être les mêmes que 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 jeu. Il existe plusieurs stratégies que vous pouvez utiliser pour maintenir une utilisation cohérente des images entre deux emplacements, notamment :
  • Enregistrer les images dans les noeuds de travail principaux et les charger dans les noeuds de travail secondaires. Cette approche est très facile à mettre en œuvre, mais entraîne des frais généraux de gestion. L'utilisation de registres de conteneurs présente des avantages considérables et l'enregistrement local des images 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 principale et la base 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 résider dans des registres de conteneurs situés dans la base principale et la base de secours. Chaque région est mise à jour en parallèle lorsqu'une nouvelle version d'une image est publiée. Cela fournit un meilleur contrôle sur le logiciel utilisé, mais entraîne une surcharge de gestion plus élevée. Il faut dupliquer des images et gérer les données d'identification pour accéder à deux registres différents. Les outils d'intégration et de déploiement continus sont généralement utilisés pour cette approche.
• Différences entre la grappe principale et la grappe secondaire : Comme c'est généralement le cas pour les systèmes RS, les grappes principale et secondaire sont une réplique l'une de l'autre en termes de versions et de configuration utilisées. Les aspects suivants sont particulièrement pertinents :
  1. Versions de Kubernetes
  2. Module d'exécution de conteneurs et version de module d'exécution de conteneurs
  3. Versions de plugiciel de réseau et de plugiciel de réseau
  4. podSubnet et servicesubnet
  5. Répertoire du chemin d'hôte etcd et version de l'image etcd
  6. Plugiciel de réseau et version d'image dns
  7. Référentiel d'images pour les pods de plan de contrôle

  Les configurations de protection contre les catastrophes avec des différences mineures entre les sites de la version de Kubernetes peuvent fonctionner, mais elles peuvent laisser la grappe dans un état incohérent après une restauration à partir de l'instantané etcd d'une instance principale. Les informations sur les sockets d'exécution de conteneur, la version de Kubernetes, etc., sont stockées dans Kubernetes lui-même. Par exemple, les informations cri-socket sont spécifiques à chaque noeud en fonction de l'exécution de conteneur utilisée et sont stockées dans des mappages de configuration internes. De nombreuses informations utilisées pour les mises à niveau par kubeadm sont basées sur des mappages de configuration dans l'espace de noms kube-system. Par conséquent, il est important que le primaire et le secondaire utilisent les mêmes informations dans ces mappages de configuration. Vous pouvez utiliser cette commande pour stocker toutes les informations pertinentes des mappages de configuration importants à la fois dans la base principale et dans la base de secours dans les fichiers yaml.

  [prompt]$ kubectl get cm -n kube-system | grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get cm "$1" -o yaml -n kube-system > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}

  De même, vous pouvez effectuer une copie de la configuration de noeud dans chaque site à l'aide de la commande suivante :

  [prompt]$ kubectl get node |grep -v NAME | awk '{print $1}'| xargs -I{} sh -c 'kubectl get node "$1" -o yaml > "$1-`date +%y-%m-%d-%H-%M-%S`.yaml"' -- {}
  

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

À propos des produits et des rôles requis

Cette solution nécessite les produits et les rôles suivants :

• Grappe Kubernetes
• Hôte bastion capable de gérer l'accès du système Kubernetes aux points d'extrémité etcd de la grappe et d'accéder aux différents noeuds de plan de contrôle à l'aide de SSH
• (Facultatif) Oracle Cloud Infrastructure (OCI)

  Ce livre de jeu est basé sur l'utilisation de régions et de ressources OCI pour les régions principale et secondaire. Toutefois, cette solution s'applique également aux grappes Kubernetes qui sont situées sur place.

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

Nom de service : Rôle	Requis pour...
Grappe Kubernetes (principale) : administrator	exécuter tous les scripts.
Noeuds Kubernetes (principaux) : utilisateur ayant des droits sudo sur la racine	Exécutez les scripts suivants : maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh
Grappe Kubernetes (secondaire) : administrator	exécuter tous les scripts.
Noeuds Kubernetes (secondaires) : utilisateur avec droits sudo à la racine	Exécutez les scripts suivants : maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh

Voir Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.