Exécuter des bases de données sur Kubernetes – DZone

Les volumes persistants sont des abstractions qui permettent la gestion du stockage brut ; allant du disque local au NFS, au stockage de blocs spécifique au cloud, etc. Ceux-ci fonctionnent de concert avec PersistentVolumeClaims qui représentent les demandes d’accès d’un pod au stockage géré par un PV. Un utilisateur peut lier un PVC à un PV pour revendiquer la propriété d’un ensemble de ressources de disque brutes englobées par le PV. Ensuite, vous pouvez ajouter ce PVC à n’importe quelle spécification de pod en tant que volume, ce qui vous permet de monter n’importe quel type de support de stockage persistant sur une charge de travail particulière. La séparation du PV et du PVC vous permet également de contrôler entièrement le cycle de vie de votre stockage de blocs sous-jacent, notamment en le montant sur différentes charges de travail ou en le libérant tous ensemble une fois la demande expirée.

Les StatefulSets gèrent les cycles de vie des pods qui nécessitent plus de stabilité que ce qui existe dans d’autres primitives telles que Deployments et ReplicaSets. En créant un StatefulSet, vous pouvez garantir que lorsque vous supprimez un pod, le stockage géré par ses PVC montés n’est pas supprimé avec lui. Vous pouvez imaginer à quel point cette propriété est utile si vous hébergez une base de données ! Les StatefulSets permettent également un déploiement ordonné, une mise à l’échelle et des mises à jour progressives, qui créent tous plus de prévisibilité (et donc de stabilité) dans nos charges de travail. C’est aussi quelque chose qui semble aller de pair avec ce que vous attendez de l’infrastructure de votre base de données.

Quoi d’autre?

Bien que StatefulSets, PV et PVC fassent beaucoup de travail pour nous, il reste encore de nombreuses actions d’administration et de configuration que vous devez effectuer sur une base de données de niveau production. Par exemple, comment orchestrez-vous les sauvegardes et les restaurations ? Celles-ci peuvent devenir assez complexes lorsqu’il s’agit de bases de données à fort trafic qui incluent des fonctionnalités telles que les WAL. Qu’en est-il du clustering et de la haute disponibilité ? Ou des mises à niveau de version ? Ces opérations sont-elles sans temps d’arrêt ? Chaque base de données traite ces fonctionnalités de différentes manières, dont beaucoup nécessitent une coordination précise entre les composants pour réussir. Kubernetes seul ne peut pas gérer cela. Par exemple, vous ne pouvez pas faire en sorte qu’un StatefulSet configure automatiquement votre SGBDR moyen en mode lecture-réplica très facilement sans une orchestration supplémentaire.

Non seulement vous devez implémenter vous-même bon nombre de ces fonctionnalités, mais vous devez également gérer la nature éphémère des charges de travail Kubernetes. Pour garantir des performances optimales, vous devez garantir que le planificateur k8s place vos pods sur des nœuds déjà pré-réglés pour exécuter votre base de données, avec suffisamment de ressources libres pour l’exécuter correctement. Si vous avez affaire à un clustering, comment gérez-vous la mise en réseau pour vous assurer que les nœuds de base de données peuvent se connecter les uns aux autres (idéalement dans la même région cloud) ? Cela m’emmène au point suivant…

Une fois que vous commencez à prendre en compte des éléments tels que le réglage des performances des nœuds et la mise en réseau, ainsi que la nécessité de stocker les données de manière persistante dans le cluster, tout d’un coup, votre infrastructure commence à se transformer en un ensemble de serveurs pour animaux de compagnie soigneusement entretenus au lieu de troupeaux de bétail sans nom. Mais l’un des principaux avantages de l’exécution de votre application dans k8s est la possibilité exacte de traiter votre infrastructure comme du bétail plutôt que comme des animaux de compagnie ! Toutes les abstractions les plus courantes telles que les déploiements, les entrées et les services, ainsi que des fonctionnalités telles que la mise à l’échelle verticale et horizontale, sont rendues possibles car vous pouvez exécuter vos charges de travail sur un ensemble de composants d’infrastructure de haut niveau afin que vous n’ayez pas à vous soucier de votre couche d’infrastructure physique. Ces abstractions vous permettent de vous concentrer davantage sur ce que vous essayez de atteindre avec votre infrastructure au lieu de comment vous allez y parvenir.

Alors pourquoi même s’embêter avec les K8 ?

Malgré ces aspérités, il existe de nombreuses raisons de vouloir exécuter votre base de données sur k8. Il est indéniable que la popularité des k8 a considérablement augmenté au cours des dernières années, tant dans les startups que dans les entreprises. L’écosystème k8s est en développement constant afin que son ensemble de fonctionnalités continue de s’étendre et de s’améliorer régulièrement. Et son modèle d’opérateur permet aux utilisateurs finaux de gérer par programmation leurs charges de travail en écrivant du code sur les API k8s principales pour effectuer automatiquement des tâches qui devaient auparavant être effectuées manuellement. K8s permet une gestion facile de type GitOps afin que vous puissiez tirer parti des pratiques de développement de logiciels éprouvées lors de la gestion de l’infrastructure de manière reproductible et sûre. Bien que le verrouillage du fournisseur existe toujours dans le monde des k8, son effet peut être minimisé pour vous permettre de passer plus facilement au multi-cloud (ou même d’échanger l’un contre l’autre).

Alors, que pouvons-nous faire si nous voulons profiter de tous les avantages que k8s a à offrir tout en l’utilisant pour héberger notre base de données ?

Vers la fin du chat en direct, quelqu’un a demandé à Kelsey, « qu’est-ce faire vous avez réellement besoin de construire un RDS sur k8s? » Il a répondu en plaisantant avec l’expertise, le financement et les clients. Bien que nous soyons certainement sur la bonne voie avec ceux-ci chez QuestDB, je pense que cela peut être mieux formulé dans la mesure où vous devez implémenter Jour 2 Opérations pour obtenir ce qu’un service de base de données géré typique fournirait.

Les opérations du jour 2 englobent bon nombre des éléments dont j’ai discuté; sauvegardes, restaurations, arrêt/démarrage, réplication, haute disponibilité et clustering. Ce sont les fonctionnalités qui différencient un service de base de données géré d’une simple base de données hébergée sur des primitives k8s, ce que j’appellerais une opération du jour 1. Alors que k8s et son écosystème peuvent faciliter l’installation d’une base de données dans votre cluster, vous devrez éventuellement commencer à penser aux opérations du jour 2 une fois que vous aurez dépassé la phase de prototype.

Ici, j’aborderai plus en détail ce qui rend ces opérations si difficiles à mettre en œuvre et pourquoi une attention particulière doit être portée lors de leur mise en œuvre, que ce soit par un administrateur de base de données ou un fournisseur de services de base de données gérée.

L’arrêt et le démarrage des bases de données sont une opération courante dans les pratiques DevOps d’aujourd’hui et sont indispensables pour tout service de base de données géré complet. Il est assez facile de trouver au moins une raison de vouloir arrêter et démarrer une base de données. Par exemple, vous souhaiterez peut-être utiliser une base de données pour exécuter des tests d’intégration qui s’exécutent selon un calendrier prédéfini. Ou vous avez peut-être une instance partagée qui est utilisée par une équipe de développement pour l’assurance qualité en direct avant de fusionner un commit. Vous pouvez toujours créer et supprimer des instances de base de données à la demande, mais il est parfois plus facile d’avoir une référence à une chaîne de connexion à une base de données statique et à une URL dans votre harnais de test ou votre code d’orchestration.

Alors que l’arrêt/démarrage peut être automatisé dans k8s (peut-être en définissant simplement le nombre de répliques d’un StatefulSet sur 0), il y a encore d’autres aspects qui doivent être pris en compte. Si vous fermez une base de données pour économiser de l’argent, allez-vous également arrêter une infrastructure ? Si oui, comment pouvez-vous vous assurer que cette infrastructure sera disponible lorsque vous lancerez la sauvegarde de la base de données ? K8s fournit des primitives telles que l’affinité de nœud et les rejets pour aider à résoudre ce problème, mais la situation et le budget de provisionnement de l’infrastructure de chacun sont différents, et il n’y a pas d’approche unique à ce problème.

Un point intéressant que Kelsey a soulevé dans son chat était que le fait d’avoir la possibilité de démarrer une instance à partir de zéro (passer d’une stopped -> running état), n’est pas anodin. De nombreux défis doivent être résolus, notamment la recherche de l’infrastructure appropriée pour exécuter la base de données, la configuration de la connectivité réseau, le montage du volume correct et la garantie de l’intégrité des données une fois le volume monté. En fait, il s’agit d’un sujet tellement approfondi que Kelsey compare le passage de 0 -> 1 instance en cours d’exécution à un véritable test de sauvegarde et de restauration. Si vous pouvez effectivement créer une instance à partir de zéro tout en chargeant des données préexistantes, vous avez réussi un test de restauration en direct !