Utilisation de clichés d'artefact pour protéger vos clusters OCI Kubernetes Engine des sinistres
Oracle Maximum Availability Architecture (Oracle MAA) fournit des recommandations et des utilitaires qui vous permettent de procéder à une récupération dans les scénarios de sinistre affectant un emplacement et de forcer la redirection des charges globales vers un site de réplique. Ce contenu se concentre sur la réplication de configuration Kubernetes pour les applications. Les applications exécutées sur des clusters Kubernetes dépendent de nombreux composants différents à utiliser, notamment les noeuds de plan de contrôle, les noeuds de processus actif, les équilibreurs de charge et le stockage. En même temps, les données d'exécution générées par les applications exécutées sur Kubernetes présentent les mêmes défis que les applications traditionnelles. Pendant l'exécution, les applications peuvent générer, lire et mettre à jour les données persistantes. Ce guide de solutions fournit des recommandations pour répliquer la configuration d'une application exécutée sur Kubernetes. La protection contre les sinistres des données d'exécution n'entre pas dans le champ d'application de 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, notamment :
- Evitez la persistance polyglotte. L'utilisation de différents types de stockage persistant pour les données d'exécution est presque impossible à résoudre, selon le théorème de cohérence de la disponibilité de sauvegarde (BAC).
- Utilisez un magasin 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 en cas de sinistre de vos données d'exécution.
En outre, vous devez protéger le plan de contrôle de cluster Kubernetes. Utilisez les instantanés etcd appropriés pour éviter les corruptions et les pannes, et pour fournir un flashback aux clusters en cours de fonctionnement. Bien qu'Oracle MAA fournisse les meilleures pratiques en matière de protection des plans de contrôle contre les sinistres, il ne fait pas partie du champ d'application de ce document pour décrire les techniques requises dans ce domaine.
Avant de commencer
Pour plus de détails, reportez-vous aux sections suivantes :
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 (K8s) requise est répliquée via des instantanés ETCD pour la protection du plan de contrôle et avec des instantanés YAML pour la protection de la configuration de l'application. Vous pouvez utiliser des instantanés d'artefact ou vous pouvez utiliser des copies etcd ou des instantanés d'artefact pour la protection de configuration propre à l'application pour la protection de configuration propre à l'application. Pour plus d'informations, reportez-vous à Restauration de clusters Kubernetes basée sur des clichés etcd. Les images utilisées par le conteneur sont hébergées dans des registres, locaux à 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-multiregion-dr.png
kubernetes-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
Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs.
- 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.
- 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.
- 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.
- 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-apiserverdu plan de contrôle Kubernetes. Il exécute le serveur d'API Kubernetes. - Sauvegarde ETCD
La sauvegarde ETCD est une sauvegarde du composant
etcddu plan de contrôle Kubernetes.etcdcontient 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 espaces de noms Kubernetes concernés 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.
- Les images présentent un paradigme similaire aux fichiers binaires : les images ne changent pas 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.
Bien que ce guide présente un exemple d'utilisation d'Oracle Cloud Infrastructure, les recommandations sont génériques pour les clusters Kubernetes personnalisés installés dans les systèmes sur site. Vous pouvez utiliser les étapes et les scripts fournis entre un cluster Kubernetes principal exécuté dans OCI Kubernetes Engine (OKE) et un cluster secondaire exécuté dans un cluster Kubernetes sur site ou personnalisé. Vous pouvez également utiliser les étapes et les scripts entre un cluster Kubernetes principal exécuté dans OKE et un cluster secondaire exécuté également dans OKE, ou entre deux clusters Kubernetes sur site ou personnalisés.
A propos des produits et rôles requis
Cette solution nécessite les produits et rôles suivants :
- Cluster Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine ou OKE)
- Noeud bastion capable de gérer le système kubernetes
- 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 qui ne sont pas situés sur OCI.
Il s'agit des rôles nécessaires pour chaque service.
| Nom de service : rôle | Obligatoire pour... |
|---|---|
Oracle Cloud Infrastructure : admin |
provisionner et configurer des ressources et des services si vous utilisez des régions OCI. |
Cluster de moteur Kubernetes (principal) : administrator |
Exécuter tous les scripts. |
| Noeuds de moteur Kubernetes (principaux) : utilisateur de système d'exploitation avec des droits d'exécution et des droits d'accès SSH au secondaire |
exécuter les scripts suivants :
|
Cluster de moteur Kubernetes (secondaire) : administrator |
Exécuter tous les scripts. |
| Noeuds (secondaires) Kubernetes Engine : utilisateur de système d'exploitation avec droits d'exécution |
exécuter les scripts suivants :
|
Reportez-vous à Produits, solutions et services Oracle pour obtenir ce dont vous avez besoin.