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 des clusters 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é les énormes changements que l'adoption de 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 (telle qu'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'inactivité dans la région principale.

Ce manuel 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 dans les scénarios de sinistre affectant un emplacement et de forcer la redirection des charges de travail vers un site de réplique.

Bien que ce manuel 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 en 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 les suivants :

• Lorsque le plan de contrôle est mal configuré.
• Lorsque la base de données etcd est perdue, endommagée ou lorsque etcd ne s'affiche pas correctement.
• Lorsqu'une erreur de déploiement ou d'utilisateur incorrecte affecte plusieurs applications ou microservices et que le cluster doit revenir à une version ou une incarnation précédente. Une restauration d'instantané ETCD rétablira tous les artefacts 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'un cluster Kubernetes sont stockées dans etcd, qui est une banque de valeurs de clé utilisée en tant que banque de sauvegarde de Kubernetes pour les données du cluster. Ce guide 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/) sur la base de etcd restore. Les procédures de configuration et les scripts fournis peuvent nécessiter des personnalisations pour d'autres types de cluster (ceux qui n'ont pas été créés avec kubeadm), mais sont généralement valides tant qu'il y a accès aux adresses etcd utilisées par le plan de contrôle Kubernetes. Cette solution de réplication requiert une configuration spécifique pour le cluster secondaire et utilisera une copie de etcd (également appelée etcd snapshots) pour afficher exactement les mêmes artefacts que ceux 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 dans les systèmes Kubernetes. Toutefois, ils ne protègent pas les clusters contre les altérations et les erreurs de configuration des fichiers 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 clusters Kubernetes à un point de travail antérieur dans le temps. Si votre système etcd store et etcd cluster ne sont pas en bon é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 pourquoi la conservation de etcd doit être une partie essentielle de toute procédure de cycle de vie de cluster 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 liés aux données d'exécution n'est pas couverte par 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 polyglotte (l'utilisation de différents types de stockage persistant pour les données d'exécution est un problème "presque" impossible à résoudre selon le théorème BAC)
• Utiliser un seul magasin pour tous les différents types de données, microservices et applications avec autant que possible des dépendances
• Reportez-vous à Meilleures pratiques Oracle MAA pour Oracle Database afin d'obtenir une protection en cas de sinistre pour votre exécution

Avant de commencer

Il existe plusieurs présentations techniques Oracle Maximum Availability Architecture (MAA) qui 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 de protection en cas de sinistre pour les composants d'infrastructure externes (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, reportez-vous aux sections suivantes :

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

Reportez-vous à Utilisation de clichés d'artefact pour protéger vos clusters OCI Kubernetes Engine contre les sinistres afin d'obtenir des détails sur l'utilisation de clichés d'artefact pour la protection de configuration propre à l'application.

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 instantanés d'artefact pour protéger la configuration propre à l'application. 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).

Remarques :

La configuration d'Oracle Autonomous Data Guard pour la base de données d'exécution n'est pas couverte par 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 précise, incluant 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 (entre pays, voire continents).

• Equilibreur de charge

  Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatique à partir d'un seul point d'entrée vers plusieurs serveurs dans le back-end.

• Passerelle de routage dynamique

  Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de 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 et Oracle Active Data Guard fournissent 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, et permettant aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard conserve 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 coupure planifiée ou non, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, réduisant ainsi le temps d'inactivité associé à la coupure. Oracle Active Data Guard offre la possibilité de décharger les charges globales en lecture principalement vers les bases de données de secours, ainsi que des fonctionnalités 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 se connectant à des instances Oracle RAC peuvent basculer et réexécuter les modifications en toute sécurité pendant les pannes, sans aucune modification des applications utilisateur final.

• Registry

  Oracle Cloud Infrastructure Registry est un registre géré par Oracle qui vous permet de simplifier votre workflow du développement jusqu'à la 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 garantit un déploiement et une gestion fiables des applications.

• Kubernetes Engine

  Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine ou OKE) 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 requises par vos applications et Kubernetes Engine les provisionne sur Oracle Cloud Infrastructure dans une location existante. OKE utilise Kubernetes pour automatiser le déploiement, le redimensionnement et la gestion des applications en conteneur dans les clusters d'hôtes.

• Cluster Kubernetes

  Un cluster Kubernetes est un ensemble d'ordinateurs qui exécutent des applications en conteneur. Kubernetes fournit une plate-forme open source portable et extensible pour la gestion des charges de travail et des 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 d'un cluster Kubernetes. Les composants du plan de contrôle détectent les événements et y répondent, effectuent la planification et déplacent les ressources du cluster. Voici les composants du plan de contrôle :

  • 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 le noeud sur lequel les nouveaux pods non affectés seront exécutés.
  • kube-controller-manager : exécute les processus de 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 un ordinateur 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 d'entrée

  Un contrôleur d'entrée 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 service approprié et effectue l'équilibrage de charge et la terminaison SSL. Le contrôleur d'entrée s'exécute généralement sous la forme d'un pod distinct dans le cluster et peut être redimensionné indépendamment des services qu'il gère.

• API d'adresse KUBE

  L'API d'adresse KUBE 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 afin de récupérer des clusters Kubernetes pour la récupération après sinistre.

• Clichés YAML

  Un instantané 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 catastrophes de Kubernetes

Lors de l'implémentation 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é de ressource et la même configuration dans la base de données principale et 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 suivre les mêmes charges globales que la région principale. En outre, les deux systèmes doivent être cohérents fonctionnellement avec les mêmes services sur lesquels le système restauré dépend, les wagons latéraux, les cartes de configuration (CM) doivent être utilisés 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 sur le site secondaire. Les noms d'hôte ou les noms d'hôte d'alias pour le plan de contrôle et les noeuds de processus actif doivent être "actifs" à 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 (config) décrivant le cluster lui-même, ainsi que dans plusieurs fichiers et entrées de configuration. Votre emplacement secondaire doit identifier les adresses de processus actif, de plan de contrôle et de front-end kube-api avec les mêmes noms d'hôte que ceux utilisés dans le cluster Kubernetes principal (un nom qualifié complet peut différer 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 les 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 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 les mêmes que celles utilisées dans le système secondaire ou des incohérences et une défaillance peuvent survenir. Cependant, la réplication d'image n'est pas couverte par ce guide. Vous pouvez utiliser plusieurs stratégies pour maintenir une utilisation cohérente des images entre deux emplacements, notamment les suivantes :
  • Enregistrez les images dans la base principale et chargez-les sur les noeuds de processus actif de la base secondaire. 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 d'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 les bases de données principale et 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 les registres 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 un meilleur contrôle sur 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.
• Différences entre le cluster principal et le cluster secondaire : il est attendu (comme c'est généralement le cas pour les systèmes de récupération après sinistre) que le cluster principal et le cluster secondaire soient une réplique l'un de l'autre en termes de versions et de configuration utilisées. Les aspects suivants sont particulièrement pertinents :
  1. Versions Kubernetes
  2. Programme d'exécution de conteneur et version d'exécution de conteneur
  3. Versions des plug-ins réseau et des plug-ins réseau
  4. podSubnet et servicesubnet
  5. Répertoire de chemin d'hôte etcd et version de l'image etcd
  6. Version d'image dns et de module d'extension réseau
  7. Référentiel d'images pour les pods de plan de contrôle

  Les configurations de protection en cas de sinistre avec des différences mineures entre les sites dans la version de Kubernetes peuvent fonctionner, mais elles peuvent laisser le cluster dans un état incohérent après une restauration à partir de l'instantané etcd d'un serveur principal. 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 propres à chaque noeud en fonction de l'exécution de conteneur utilisée et sont stockées dans des mappes de configuration internes. De nombreuses informations utilisées pour les mises à niveau par kubeadm sont basées sur les mappes 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 configmaps. Vous pouvez utiliser cette commande pour stocker toutes les informations pertinentes des mappes de configuration importantes dans les fichiers principal et de secours 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 manuel de solutions présente un exemple d'utilisation de clusters Kubernetes créés à l'aide de l'outil kubeadm. Les recommandations sont génériques pour les 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 à l'aide de l'outil kubeadm. Vous devez utiliser les étapes et les scripts fournis entre les clusters Kubernetes exécutant la même version de etcd et de 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 nécessite les produits et rôles suivants :

• Cluster Kubernetes
• Bastion capable de gérer le système Kubernetes pour accéder aux adresses etcd du cluster et aux différents noeuds de plan de contrôle avec SSH
• (Facultatif) Oracle Cloud Infrastructure (OCI)

  Ce guide stratégique est basé 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 des 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 des droits sudo sur root	exécuter les scripts suivants : maak8s-force-stop-cp.sh maak8-etcd-backup.sh maak8-etcd-restore.sh

Reportez-vous à Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.