Déployer des bases de données Postgres dans Kubernetes avec CNPG

le 10/02/2025 par Yannig Perre
Tags: Cloud & Platform, Devops, Infra as Code

Hébergé des bases Postgres dans Kubernetes

Pour faire tourner une base PostgreSQL dans Kubernetes ?

Depuis quelques années, j’héberge des bases de données dans Kubernetes, une approche qui peut surprendre. En effet, qui n’a jamais entendu que les conteneurs ne sont pas faits pour les workloads stateful ?

Pourtant, je me sens bien plus à l’aise avec cette solution qu’avec d’autres méthodes d’hébergement et ce pour plusieurs raisons :

  • Réduction des coûts par rapport aux solutions cloud managées.
  • Liberté et flexibilité, notamment en comparaison avec les offres cloud propriétaires.
  • Fiabilité accrue en environnement on-premise, surtout face aux méthodes classiques d’hébergement basées sur des machines virtuelles installées manuellement.

Prenons quelques alternatives pour comparer :

  • Une base installée manuellement sur une VM
  • Une base managée dans le cloud

Dans le cas de la machine virtuelle, cette approche ne garantit en rien les bonnes pratiques d’exploitation notamment sur la gestion des sauvegardes et des tests de restauration ainsi que le monitoring des bases.

Concernant une base managée dans le cloud, bien que séduisante, cette option présente plusieurs inconvénients :

  • Dépendance à une solution propriétaire.
  • Manque de souplesse pour les besoins spécifiques.
  • Coûts parfois prohibitifs.
  • Contraintes légales ou réglementaires, notamment vis-à-vis du RGPD.

Concernant l’optimisation des coûts, il est intéressant d’exploiter au maximum les instances disponibles, par exemple en les mutualisant pour plusieurs usages :

  • Stockage des données applicatives (ex : schéma backend).
  • Stockage des données pour un gestionnaire d’identité (ex : Keycloak).

Cette approche à le défaut de mélanger parfois des contenus très différents et de rendre difficile l’exploitation de la plateforme. En effet, comme le système est couplé à une seule base, elle devient précieuse ce qui entraîne automatiquement des risques opérationnels importants.

Enfin, dans certains cas, l’hébergement sur un GAFAM est tout simplement impossible pour des raisons légales, des contraintes de protection des données ou encore parce que l’application concernée n’est pas prévue pour le cloud.

La suite de l’article explorera comment Kubernetes (et notamment avec la notion d’opérateur) peut répondre à ces défis et offrir une alternative viable aux solutions traditionnelles.

Qu’est-ce qu’un opérateur Kubernetes

Avant de se lancer dans le choix d’un opérateur, je vais d’abord définir ce que c’est.

Il s’agit d’un composant qui automatise la gestion d’un élément complexe, comme par exemple une base de données, un moteur de cache, un gestionnaire de certificats, etc. Son rôle est d’intégrer et faciliter les bonnes pratiques d’exploitation directement dans le cluster.

Il va pour cela étendre les fonctionnalités de Kubernetes en ajoutant un nouveau type de ressources (créé à l’aide de CRD) qui va ensuite surveiller et orchestrer pour la plupart des tâches courantes : création, configuration, sauvegardes, etc.

Dans le cas d’un opérateur de base de données, ce dernier prendra en charge automatiquement le failover, la réplication ou l’ajout de nouveaux nœuds sans intervention manuelle.

Ce qu’il faut retenir, c’est que ces composants sont là pour simplifier la gestion et le cycle de vie des charges applicatives complexes.

Quel opérateur choisir ?

Le concept d’opérateur existe depuis plusieurs années, et pour les bases de données PostgreSQL, le besoin s’est rapidement fait sentir. Cela se reflète dans la diversité des solutions disponibles, parmi lesquelles on trouve :

  • Crunchy Data, qui peut être complexe à installer,
  • Zalando Operator, qui ne propose pas de métriques compatibles avec Prometheus (malgré une PR que j’ai soumise il y a trois ans sans succès),
  • KubeDB, qui repose sur un modèle payant.

Ces solutions, bien que fonctionnelles, présentent chacune des limitations.

Cependant, l’opérateur Cloud Native PostgreSQL (CNPG) a changé la donne. Cet article propose d’explorer en quoi il se distingue et améliore la gestion des bases PostgreSQL dans Kubernetes.

Mise en place de CNPG

Installation de CNPG

L’installation est relativement standard et passe par un chart Helm.

Ci-dessous la suite d’instruction à suivre afin de réaliser l’installation de ce composant :

# Ajout de la référence des charts de CNPG
$ helm repo add cnpg https://cloudnative-pg.github.io/charts
# Mise à jour des références des charts
$ helm repo update
# Installation 
$ helm upgrade --install cnpg cnpg/cloudnative-pg \
  --namespace cnpg-system --create-namespace

L’installation est en principe relativement rapide. N’hésitez pas à scruter l’état du déploiement à l’aide de l’instruction suivante :

$ kubectl -n cnpg-system get pods --watch

Ci-dessous l’état attendu une fois que l’opérateur aura fini de se déployer :

NAME                                   READY   STATUS    RESTARTS        AGE
cnpg-cloudnative-pg-5979878bf7-l6c8g   1/1     Running   5 (5d22h ago)   14d

Création d’une instance PostgreSQL

Une fois l’opérateur déployé, il devient possible de créer des nouveaux objets : des Clusters PostgreSQL.

La déclaration est relativement simple et ne nécessite qu’un nombre limité d’informations :

  • Les entêtes classiques de Kubernetes : champs kind, apiVersion et metadata
  • Le nombre de réplicas de la base : champ replica
  • La taille de l’espace disque associé à la base : champ storage
  • L’image à utiliser pour le cluster : champ imageName

À noter que concernant le champ imageName, la version spécifiée de l’image détermine la version de la base PostgreSQL à créer. Il y a notamment un certain nombre de limitations. Il n’est pas possible par exemple de changer de version majeure de base de données sans procéder à la création d’une nouvelle base de données.

Ci-dessous un exemple de déclaration minimale :

---
*# Manifeste cluster.yaml*
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
 name: simple-postgres
spec:
 instances: 1
 imageName: ghcr.io/cloudnative-pg/postgresql:17.2
 storage:
   size: 10Gi

Sauvegardez cette définition sous le nom de fichier cluster.yaml puis appliquez-le auprès de l’API du cluster :

$ kubectl apply -f cluster.yaml

L’application de ce manifeste va avoir de nombreuses conséquences :

Connexion à la base de données

Exploitation des bases avec CNPG

Mise en place de Minio

Mécanisme de sauvegarde

Restaurer une BDD

Mécanisme de réplication

Conclusion

Avantages clés :

Open-source, économique et personnalisable.

Excellente solution pour des infrastructures on-premise ou hybrides.

Fonctionnalités riches (réplication, sauvegardes, intégration avec Kubernetes).

Points d’attention :

Nécessite une expertise Kubernetes pour la maintenance.

Peut être plus complexe à gérer qu’un service managé, notamment en cas de panne.

Recommandations :

CNPG est idéal pour les organisations souhaitant un contrôle total sur leur infrastructure et maîtriser leurs coûts.

Une alternative sérieuse aux services managés pour les environnements déjà investis dans Kubernetes.

Call-to-action :

Testez CNPG dès aujourd’hui : Fournir des liens vers la documentation officielle et des guides d'installation.

Encourager les lecteurs à partager leurs expériences ou poser des questions en commentaire.

Objectifs du plan

Présenter clairement les avantages et limites de CNPG.

Guider pas à pas dans l’installation, l’utilisation et les fonctionnalités clés.

Offrir une vue équilibrée pour aider le lecteur à choisir CNPG en connaissance de cause.

Écrit nous le plus bel article ;)