Cette page décrit les bonnes pratiques à adopter pour exécuter des bases de données dans des conteneurs sur GKE. Vous pouvez utiliser un déploiement pour créer un ensemble d'instances de base de données conteneurisées gérées par Kubernetes. Vous créez ensuite un Service pour fournir l'accès à la base de données indépendamment de n'importe quel pod. Le service reste inchangé même si le pod est déplacé vers un autre nœud.
Pour accéder aux données de votre instance de base de données, créez une ressource PersistentVolumeClaim (PVC) et mettez-la à la disposition de votre charge de travail.
Pour assurer la persistance, les bases de données s'appuient sur des disques locaux. Une base de données qui s'exécute en tant que service dans un cluster Kubernetes et exécute ses fichiers de base de données dans un PersistentVolumeClaim est liée au cycle de vie du cluster. Si le cluster est supprimé, la base de données est également supprimée.
Si vous créez ou déployez une application avec état s'exécutant dans GKE, envisagez d'utiliser l'une des options de déploiement suivantes pour les instances de base de données :
- Bases de données entièrement gérées : une base de données gérée, telle que Cloud SQL ou Spanner, permet de réduire les coûts opérationnels et est optimisées pour l'infrastructure Google Cloud. Les bases de données gérées demandent moins d'efforts en termes de maintenance et de fonctionnement qu'une base de données que vous déployez directement dans Kubernetes.
- Application Kubernetes : vous pouvez déployer et exécuter une instance de base de données (telle que MySQL ou PostgreSQL) sur un Cluster GKE.
Éléments à prendre en compte pour les déploiements de bases de données sur GKE
Chacune des options précédentes présente des compromis en fonction de vos objectifs et contraintes métier. Utilisez le tableau suivant pour déterminer si le déploiement de base de données sur GKE est la solution adaptée à vos besoins.
| Considération | Description |
|---|---|
| Indépendance de la base de données | Le cycle de vie d'un PersistentVolumeClaim est lié au cluster GKE correspondant. Si vous ne souhaitez pas que le cycle de vie de votre base de données dépende d'un cluster GKE particulier, envisagez de garder la base de données séparée, en tant que base de données gérée ou dans une instance de VM. |
| Procéder au scaling avec GKE | Scaling vertical : vous pouvez configurer le scaling automatique de vos requêtes pods. Cependant, vous devez vous assurer que votre application de base de données peut résister aux interruptions lorsque vos pods évoluent à la hausse avec l'autoscaling vertical des pods. Scaling horizontal : votre base de données peut être en mesure d'effectuer un scaling horizontal des lectures ou des écritures en ajoutant des instances dupliquées. La compatibilité de votre base de données avec le scaling horizontal varie selon qu'elle possède une architecture à écriture unique ou multi-écriture. Pour utiliser le scaling horizontal, vous devrez peut-être mettre à jour la configuration de la base de données, en plus d'augmenter le nombre d'instances dupliquées. |
| Frais liés à GKE | Sur les clusters Autopilot, les réservations de ressources ne vous sont pas facturées. Seules les demandes de ressources le sont. Sur les clusters standards, GKE réserve des ressources pour ses propres opérations. Le scaling des bases de données sur des clusters standards ne s'effectue pas automatiquement. Les frais peuvent donc être élevés pour les petits pods. |
| Nombre d'instances de base de données | Dans le contexte de Kubernetes, chaque instance de base de données s'exécute dans son propre pod et possède son propre objet PersistentVolumeClaim. Si vous disposez d'un grand nombre d'instances, vous devez utiliser et gérer un grand nombre de pods, de nœuds et de demandes de volume. Il peut être préférable d'utiliser une base de données gérée. |
| Sauvegarde de base de données dans GKE | Un PersistentVolumeClaim est limité à un cluster GKE. Ce champ d'application signifie que lorsqu'un cluster GKE est supprimé, la demande de volume est elle aussi supprimée. Tous les fichiers de base de données du cluster sont également supprimés. Pour éviter toute perte accidentelle de fichiers de base de données, nous vous recommandons d'effectuer une réplication ou des sauvegardes fréquentes. Vous pouvez utiliser Sauvegarde pour GKE pour effectuer des instantanés de la configuration de votre application et des données de volume à intervalles réguliers. La fonctionnalité Sauvegarde pour GKE gère la planification des sauvegardes de volumes, le cycle de vie des sauvegardes et la restauration des sauvegardes sur un cluster. |
| Comportement de récupération spécifique à Kubernetes | Lorsqu'un pod échoue dans Kubernetes, il est recréé. Du point de vue de l'instance de base de données, cela signifie que lorsqu'un pod est recréé, toute configuration non persistante dans une base de données ou sur un espace de stockage stable en dehors des pods est également recréée. |
| Architecture de base de données | Si votre base de données est configurée pour utiliser une architecture active-passive, vous devez vous assurer qu'une seule instance répliquée est configurée en tant qu'instance principale. De nombreuses bases de données relationnelles proposent une option de basculement actif-passif, où un serveur secondaire peut être promu en instance principale en cas de défaillance de celle-ci. |
| Migration de bases de données | Si vous envisagez de migrer votre système de base de données existant vers GKE, consultez les pages Migration de bases de données : concepts et principes (partie 1) et Migration de bases de données : concepts et principes (partie 2) |
| Réentraînement des utilisateurs | Réentraînement : si vous passez d'un déploiement autogéré ou géré par un fournisseur à un déploiement de base de données dans Kubernetes, vous devez réentraîner les administrateurs de base de données pour qu'ils s'exécutent dans le nouvel environnement avec le même degré de fiabilité que dans l'environnement actuel. Dans une moindre mesure, les développeurs d'applications peuvent également avoir besoin d'en savoir plus sur les différences. |
Le tableau précédent présente certains critères liés au déploiement d'une base de données. Il n'inclut toutefois pas tous les critères envisageables. Vous devez également prendre en compte la reprise après sinistre, le regroupement de connexions et la surveillance.
Étapes suivantes
- Découvrez comment déployer une topologie MySQL à disponibilité élevée sur GKE.
- Découvrez comment déployer une instance PostgreSQL à disponibilité élevée sur GKE.
- Découvrez Sauvegarde pour GKE, un service de sauvegarde et de restauration des charges de travail dans GKE.
- Découvrez les Volumes persistants plus en détail.