Utilisation de Patroni avec Kubernetes

Utilisation de Patroni avec les objets, étiquettes et la découverte de service Kubernetes.

Tâche

Patroni peut utiliser des objets Kubernetes afin de stocker l’état du cluster et gérer la clé du leader. Cela lui permet de fonctionner avec PostgreSQL dans un environnement Kubernetes sans nécessiter de magasin de cohérence, c’est-à-dire qu’il n’est pas nécessaire de déployer un Étcd supplémentaire. Patroni peut utiliser deux types d’objets Kubernetes pour stocker la clé du leader et les clés de configuration, configurés via les variables d’environnement kubernetes.use_endpoints ou PATRONI_KUBERNETES_USE_ENDPOINTS.

Utiliser les points de terminaison

Bien que ce soit le mode recommandé, il est désactivé par défaut pour des raisons de compatibilité. Lorsqu’il est activé, Patroni stocke la configuration du cluster et la clé du leader dans les champs metadata: annotations du Endpoints correspondant qu’il crée. Le changement de leader est plus sûr qu’avec ConfigMaps, car les annotations contenant les informations sur le leader ainsi que les adresses réelles pointant vers le pod leader en cours d’exécution sont mises à jour simultanément en une seule opération.

Utiliser les ConfigMaps

En ce mode, Patroni crée des ConfigMaps au lieu des Endpoints et stocke les clés dans les métadonnées de ces ConfigMaps. Le changement de leader nécessite au moins deux mises à jour : une pour le ConfigMap du leader, et une autre pour l’Endpoint correspondant.

Pour rediriger le trafic vers le leader PostgreSQL, vous devez configurer le service Kubernetes PostgreSQL afin d’utiliser un sélecteur d’étiquettes avec role_label (configuré dans la configuration Patroni).

Notez qu’il existe, dans certains cas — par exemple lors de l’exécution sur OpenShift — aucune alternative à l’utilisation des ConfigMaps.

Configuration

Les paramètres Patroni Kubernetes settings et les variables d’environnement environment variables sont décrits dans les chapitres généraux de la documentation.

Personnaliser l’étiquette de rôle

Par défaut, Patroni affecte des étiquettes correspondantes au pod dans lequel il s’exécute, en fonction du rôle du nœud, telles que role=primary. La clé et la valeur de l’étiquette peuvent être personnalisées à l’aide de kubernetes.role_label, kubernetes.leader_label_value, kubernetes.follower_label_value et kubernetes.standby_leader_label_value.

Remarque : si vous migrez des étiquettes de rôle par défaut vers des étiquettes personnalisées, vous pouvez réduire la durée d’indisponibilité en suivant les étapes de migration :

Ajoutez une étiquette temporaire en utilisant la valeur d’origine du rôle pour le pod avec kubernetes.tmp_role_label (comme tmp_role). Une fois les pods redémarrés, les étiquettes suivantes seront définies par Patroni :

étiquettes :
  nom-cluster : foo
  rôle : primaire
  rôle_temporaire : primaire

Une fois tous les pods mis à jour, modifiez le sélecteur de service pour qu’il sélectionne l’étiquette temporaire.

sélecteur :
  nom-cluster : foo
  rôle-temporaire : primaire

Ajoutez votre étiquette de rôle personnalisée (par exemple, définissez kubernetes.leader_label_value=primary). Une fois les pods redémarrés, ils recevront les nouvelles étiquettes suivantes définies par Patroni :

étiquettes :
  nom-cluster : foo
  rôle : primaire
  rôle_temporaire : primaire

Une fois que tous les pods ont été mis à jour, modifiez le sélecteur de service pour utiliser la nouvelle valeur de rôle.

sélecteur :
  nom-cluster : foo
  rôle : primaire

Enfin, supprimez l’étiquette temporaire de votre configuration et mettez à jour tous les pods.

étiquettes:
  nom-cluster : foo
  rôle : primaire

Exemples

Le dossier kubernetes du dépôt Patroni contient des exemples d’image Docker et du manifeste Kubernetes permettant de tester la configuration Patroni sous Kubernetes. Notez qu’en l’état actuel, il ne sera pas possible d’utiliser des PersistentVolumes en raison de problèmes de permissions.
Vous trouverez l’image Docker complète, capable d’utiliser des PersistentVolumes, dans le projet Spilo .
Il existe également un Helm chart permettant de déployer l’image Spilo configurée avec Patroni en exécution sous Kubernetes.
Pour exécuter vos clusters de bases de données à grande échelle avec Patroni et Spilo, consultez le projet postgres-operator . Il implémente le modèle d’opérateur pour gérer les clusters Spilo.