![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Hello \u00e0 toutes et tous !<\/p>\n Pour faire suite \u00e0 l’article d’Emmanuel<\/a> sur l’installation de PostgreSQL sur un cluster minikube local, aujourd’hui nous allons d\u00e9couvrir l’op\u00e9rateur Kubegres <\/a>qui permet de facilement d\u00e9ployer un cluster PostgreSQL avec Primary et Standby \u00e0 l’int\u00e9rieur de pods K8s, sans avoir \u00e0 cr\u00e9er chaque brique une par une comme on devrait le faire avec un simple StatefulSet. <\/p>\n En un mot : SIM-PLI-CI-TE !<\/strong> <\/p>\n Parce qu’il introduit un nouveau type d’objet : <\/p>\n Les specs \u00e0 l’int\u00e9rieur de cet objet encapsulent d\u00e9j\u00e0 tout ce qui est n\u00e9cessaire pour cr\u00e9er les StatefulSets, les ClusterIPs, le Physical Volumes et le PVC associ\u00e9, la ConfigMap et les Pods. Pas besoin de tout cr\u00e9er \u00e0 l’avance et le fichier de d\u00e9ploiement est beaucoup plus compact !<\/p>\n Nous utiliserons minikube <\/a>pour montrer comment d\u00e9ployer Kubegres, je vous renvoie \u00e0 l’article d’Emmanuel cit\u00e9 plus haut pour son installation. Comme nous allons devoir attribuer des fractions de ressource RAM et CPU entre les pods, j’activerai juste en plus la partie metrics-server :<\/p>\n La premi\u00e8re \u00e9tape consiste \u00e0 installer l’op\u00e9rateur. Cette premi\u00e8re \u00e9tape va cr\u00e9er un nombre importants d’objets pour nous, comme en t\u00e9moigne le contenu de son fichier de d\u00e9ploiement <\/p>\n : Un namespace kubegres-system<\/em> a \u00e9t\u00e9 cr\u00e9\u00e9, dans lequel notre cluster pourra \u00e9ventuellement s’inscrire. Cela dit, la bonne pratique consisterait \u00e0 cr\u00e9er un namespace \u00e0 part et laisser le controller-manager kubegres dans son namespace syst\u00e8me, mais pour ne pas interf\u00e9rer avec mes autres namespaces, je vais volontairement rajouter le cluster dedans:<\/p>\n Avant de cr\u00e9er le cluster PostgreSQL, il va falloir cr\u00e9er un secret qui va contenir les mots de passe du primaire et de sa standby. <\/p>\n Enfin nous pouvons cr\u00e9er le cluster avec un seul fichier de d\u00e9ploiement:<\/p>\n Remarques sur les sections <\/strong>: La liste compl\u00e8te des propri\u00e9t\u00e9s peut \u00eatre retrouv\u00e9e sur la page de documentation <\/a>de Kubegres.<\/p>\n Une fois le cluster d\u00e9ploy\u00e9, nous pouvons v\u00e9rifier tous les nouveaux objets qui ont \u00e9t\u00e9 cr\u00e9\u00e9s:<\/p>\n En plus du controller manager<\/em>, nous avons donc 2 nouveaux pods, 2 services ClusterIP et 2 StatefulSets, un pour chaque instance PostgreSQL. Le deploiement est configur\u00e9 avec 2 sondes (liveness et readiness) qui toutes 2 utilisent la commande pg_isready pour v\u00e9rifier la disponibilit\u00e9 des instances primaire et standby. D’ailleurs on peut le tester nous-m\u00eames pour v\u00e9fifier le retour de la commande :<\/p>\n Notre Failover est param\u00e9tr\u00e9 sur automatique, avec une pr\u00e9f\u00e9rence pour repartir sur le noeud 2, on va simuler une perte du service en faisant un pg_ctl stop sur le premier pod:<\/p>\n On voit que la reconnexion imm\u00e9diate ne fonctionne pas tout de suite: <\/p>\n D’apr\u00e8s les logs le failover dure une dizaine de secondes seulement:<\/p>\n La nouvelle connexion indique que l’on a chang\u00e9 de host:<\/p>\n Si on inventorie les objets, on voit qu’un nouveau Pod et StatefulSet ont \u00e9t\u00e9 cr\u00e9\u00e9s (AGE=43s):<\/p>\n Pour pouvoir g\u00e9n\u00e9rer des sauvegardes de type pg_dumpall, il suffit de cr\u00e9er un PVC d\u00e9di\u00e9 et de rajouter une planification dans notre fichier de d\u00e9ploiement, qui \u00e0 son tour va cr\u00e9er une ressource de type CronJob: <\/p>\n Le CronJob est alors en place, on a programm\u00e9 toutes les 5 minutes pour en voir passer un assez rapidement quand m\u00eame :<\/p>\n Pour g\u00e9rer le backup, kubegres cr\u00e9\u00e9 un nouveau pod \u00e0 chaque fois, ce qui permet de contr\u00f4ler le bon fonctionnement des sauvegardes: <\/p>\n Kubegres apporte une grande aisance dans le d\u00e9ploiement de clusters PostgreSQL avec Streaming Replication. Il aurait \u00e9t\u00e9 beaucoup plus fastidieux ici de tout cr\u00e9er \u00e0 la main. A bient\u00f4t et doucement sur les chocolats \ud83d\ude42 !<\/p>\n Hello \u00e0 toutes et tous ! Pour faire suite \u00e0 l’article d’Emmanuel sur l’installation de PostgreSQL sur un cluster minikube local, aujourd’hui nous allons d\u00e9couvrir l’op\u00e9rateur Kubegres qui permet de facilement d\u00e9ployer un cluster PostgreSQL avec Primary et Standby \u00e0… Continuer la lecture ![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/04\/2containers.png\")
<\/a><\/p>\nPourquoi Kubegres apporte un vrai plus<\/h2>\n
kind: Kubegres\r\n<\/pre>\n
Installation de Kubegres <\/h2>\n
$ minikube addons enable metrics-server<\/pre>\n
\r\n$ curl --silent https:\/\/raw.githubusercontent.com\/reactive-tech\/kubegres\/v1.16\/kubegres.yaml \\\r\n | grep -w 'kind:' | awk -F':' '{print $2}' \\ \r\n | sort -u\r\n\r\n ClusterRole\r\n ClusterRoleBinding\r\n ConfigMap\r\n ControllerManagerConfig\r\n CustomResourceDefinition\r\n Deployment\r\n Kubegres\r\n Namespace\r\n Role\r\n RoleBinding\r\n Service\r\n ServiceAccount\r\n\r\n<\/pre>\n
\nOn d\u00e9ploie donc via kubectl<\/a>:<\/p>\n\r\n$ kubectl apply -f https:\/\/raw.githubusercontent.com\/reactive-tech\/kubegres\/v1.16\/kubegres.yaml\r\nnamespace\/kubegres-system created\r\ncustomresourcedefinition.apiextensions.k8s.io\/kubegres.kubegres.reactive-tech.io created\r\nserviceaccount\/kubegres-controller-manager created\r\nrole.rbac.authorization.k8s.io\/kubegres-leader-election-role created\r\nclusterrole.rbac.authorization.k8s.io\/kubegres-manager-role created\r\nclusterrole.rbac.authorization.k8s.io\/kubegres-metrics-reader created\r\nclusterrole.rbac.authorization.k8s.io\/kubegres-proxy-role created\r\nrolebinding.rbac.authorization.k8s.io\/kubegres-leader-election-rolebinding created\r\nclusterrolebinding.rbac.authorization.k8s.io\/kubegres-manager-rolebinding created\r\nclusterrolebinding.rbac.authorization.k8s.io\/kubegres-proxy-rolebinding created\r\nconfigmap\/kubegres-manager-config created\r\nservice\/kubegres-controller-manager-metrics-service created\r\ndeployment.apps\/kubegres-controller-manager created\r\n<\/pre>\n
\r\n$ kubectl get all --namespace=kubegres-system\r\nNAME READY STATUS RESTARTS AGE\r\npod\/kubegres-controller-manager-794468bbff-bxzxk 2\/2 Running 0 3m35s\r\n\r\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\r\nservice\/kubegres-controller-manager-metrics-service ClusterIP 10.100.182.92 <none> 8443\/TCP 3m35s\r\n\r\nNAME READY UP-TO-DATE AVAILABLE AGE\r\ndeployment.apps\/kubegres-controller-manager 1\/1 1 1 3m35s\r\n\r\nNAME DESIRED CURRENT READY AGE\r\nreplicaset.apps\/kubegres-controller-manager-794468bbff 1 1 1 3m35s\r\n<\/pre>\n
Cr\u00e9ation du cluster en 15.2<\/h2>\n
\r\n$ vi postgres-secret.yaml\r\n(...)\r\napiVersion: v1\r\nkind: Secret\r\nmetadata:\r\n name: mypostgres-secret\r\n namespace: kubegres-system\r\ntype: Opaque\r\nstringData:\r\n superUserPassword: capdata\r\n replicationUserPassword: capdatarep\r\n\r\n$ kubectl apply -f postgres-secret.yaml -n kubegres-system\r\nsecret\/mypostgres-secret created\r\n<\/pre>\n
\r\napiVersion: kubegres.reactive-tech.io\/v1\r\nkind: Kubegres\r\nmetadata:\r\n name: kpostgres\r\n namespace: kubegres-system\r\n\r\nspec:\r\n\r\n replicas: 2\r\n image: postgres:15.2\r\n port: 5432\r\n\r\n database:\r\n size: 200Mi\r\n storageClassName: standard\r\n volumeMount: \/var\/lib\/postgresql\/data\r\n\r\n failover:\r\n isDisabled: false\r\n promotePod: "kpostgres-2-0"\r\n\r\n resources:\r\n limits:\r\n memory: "1Gi"\r\n cpu: "1"\r\n requests:\r\n memory: "500Mi"\r\n cpu: "0.5"\r\n\r\n probe:\r\n livenessProbe:\r\n exec:\r\n command:\r\n - sh\r\n - -c\r\n - exec pg_isready -U postgres -h $POD_IP\r\n failureThreshold: 10\r\n initialDelaySeconds: 60\r\n periodSeconds: 20\r\n successThreshold: 1\r\n timeoutSeconds: 15\r\n\r\n readinessProbe:\r\n exec:\r\n command:\r\n - sh\r\n - -c\r\n - exec pg_isready -U postgres -h $POD_IP\r\n failureThreshold: 3\r\n initialDelaySeconds: 5\r\n periodSeconds: 5\r\n successThreshold: 1\r\n timeoutSeconds: 3\r\n\r\n env:\r\n - name: POSTGRES_PASSWORD\r\n valueFrom:\r\n secretKeyRef:\r\n name: mypostgres-secret\r\n key: superUserPassword\r\n\r\n - name: POSTGRES_REPLICATION_PASSWORD\r\n valueFrom:\r\n secretKeyRef:\r\n name: mypostgres-secret\r\n key: replicationUserPassword\r\n<\/pre>\n
\n– La spec database.size permet de dimensionner le PVC \u00e0 une taille initiale, mais attention ! En fonction de la version de Kubernetes, il peut \u00eatre compliqu\u00e9 de modifier cette valeur ensuite comme rapport\u00e9 dans cet issue du github Kubegres<\/a>.
\n– On ne cr\u00e9\u00e9 ‘que’ 2 r\u00e9plicas au sens StatefulSet, c’est \u00e0 dire un primaire et une standby.
\n– La spec failover permet de d\u00e9sactiver ou d’activer le promote automatique de la standby, et de dire quel est le noeud pr\u00e9f\u00e9rentiel.
\n– 2 types de sondes : une pour d\u00e9cider de red\u00e9marrer le container en cas d’\u00e9chec de connexion (livenessProbe), et une autre pour autoriser les connexions (readinessProbe). Le fonctionnement du failover est expliqu\u00e9 plus loin.
\n– resources permet de limiter l’utilisation des pods \u00e0 des plages de CPU et RAM en jouant avec requests et limit.
\n– Il est aussi possible d’utiliser l’anti-affinit\u00e9 pour emp\u00eacher les pods primary et standby d’atterrir sur le m\u00eame node K8s. On ne le fait \u00e9videmment pas dans notre exemple car sur minikube cela n’aurait aucun sens. <\/p>\n\r\n$ kubectl apply -f postgres-cluster.yaml -n kubegres-system\r\nkubegres.kubegres.reactive-tech.io\/kpostgres created\r\n\r\n$ kubectl get all -n kubegres-system\r\nNAME READY STATUS RESTARTS AGE\r\npod\/kpostgres-1-0 1\/1 Running 2 5d16h\r\npod\/kpostgres-2-0 1\/1 Running 3 5d16h\r\npod\/kubegres-controller-manager-794468bbff-bxzxk 2\/2 Running 13 (23m ago) 5d18h\r\n\r\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\r\nservice\/kpostgres ClusterIP None <none> 5432\/TCP 5d16h\r\nservice\/kpostgres-replica ClusterIP None <none> 5432\/TCP 5d16h\r\nservice\/kubegres-controller-manager-metrics-service ClusterIP 10.100.182.92 <none> 8443\/TCP 5d18h\r\n\r\nNAME READY UP-TO-DATE AVAILABLE AGE\r\ndeployment.apps\/kubegres-controller-manager 1\/1 1 1 5d18h\r\n\r\nNAME DESIRED CURRENT READY AGE\r\nreplicaset.apps\/kubegres-controller-manager-794468bbff 1 1 1 5d18h\r\n\r\nNAME READY AGE\r\nstatefulset.apps\/kpostgres-1 1\/1 5d16h\r\nstatefulset.apps\/kpostgres-2 1\/1 5d16h\r\n<\/pre>\n
\nNous pouvons \u00e0 partir de l\u00e0 tester la connexion au service (kpostgres), en d\u00e9marrant un conteneur client ephemeral<\/em> (kubectl run … –rm). On rappelle que kubegres ne cr\u00e9\u00e9 par d\u00e9faut que des Headless Services <\/em>(ClusterIP sans adresse attribu\u00e9e) pour \u00e9viter de les rendre visibles depuis l’ext\u00e9rieur du cluster. On partira toujours du principe que sur un cluster Kubernetes, tout est deployment \/ pod<\/strong> :<\/p>\n\r\n$ kubectl run postgresql-postgresql-client --rm --tty -i --restart='Never' \\\r\n --namespace kubegres-system --image postgres:15.2 \\\r\n --env="PGPASSWORD=capdata" --command -- psql \\\r\n --host kpostgres -U postgres -c "select version();"\r\n\r\n version\r\n\r\n--------------------------------------------------------------------------------\r\n---------------------------------------------\r\n PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by g\r\ncc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit\r\n(1 row)\r\n\r\npod "postgresql-postgresql-client" deleted\r\n<\/pre>\n
Comportement en cas d’\u00e9chec du serveur primaire<\/h2>\n
\r\n$ kubectl exec --tty --stdin -n kubegres-system kpostgres-1-0 -- pg_isready -U postgres && echo $?\r\n\/var\/run\/postgresql:5432 - accepting connections\r\n0\r\n<\/pre>\n
\r\n$ kubectl exec --tty --stdin -n kubegres-system kpostgres-1-0 -- su postgres \\\r\n -c "pg_ctl stop -D \/var\/lib\/postgresql\/data\/pgdata -m fast" \r\nwaiting for server to shut down....command terminated with exit code 137\r\n<\/pre>\n
\r\n$ kubectl run postgresql-postgresql-client --rm --tty -i --restart='Never' --namespace kubegres-system --image postgres:15.2 --env="PGPASSWORD=capdata" --command -- psql --host kpostgres -U postgres -c "select inet_server_addr();"\r\n(...)\r\npsql: error: could not translate host name "kpostgres" to address: Temporary failure in name resolution\r\npod "postgresql-postgresql-client" deleted\r\npod kubegres-system\/postgresql-postgresql-client terminated (Error)\r\n<\/pre>\n
\r\n$ kubectl logs pod\/kubegres-controller-manager-794468bbff-bxzxk -c manager -n kubegres-system --timestamps | grep 'FailOver:'\r\n2023-04-19T20:11:22.687346601Z 1.6819350826873376e+09 INFO controllers.Kubegres FailOver: Deleting the failing Primary StatefulSet. {"Primary name": "kpostgres-1"}\r\n2023-04-19T20:11:22.690961293Z 1.6819350826909401e+09 INFO controllers.Kubegres FailOver: Waiting before promoting a Replica to a Primary... {"Replica to promote": "kpostgres-2"}\r\n2023-04-19T20:11:33.712923151Z 1.6819350937128017e+09 INFO controllers.Kubegres FailOver: Promoting Replica to Primary. {"Replica to promote": "kpostgres-2"}\r\n2023-04-19T20:11:33.713030040Z 1.6819350937129502e+09 DEBUG events Normal {"object": {"kind":"Kubegres","namespace":"kubegres-system","name":"kpostgres","uid":"56c2a503-93f5-4bf8-8d0a-fe88cdaf2bde","apiVersion":"kubegres.reactive-tech.io\/v1","resourceVersion":"95195"}, "reason": "FailOver", "message": "FailOver: Promoting Replica to Primary. 'Replica to promote': kpostgres-2"}\r\n<\/pre>\n\r\n$ kubectl run postgresql-postgresql-client --rm --tty -i --restart='Never' --namespace kubegres-system --image postgres:15.2 --env="PGPASSWORD=capdata" --command -- psql --host kpostgres -U postgres -c "select inet_server_addr();"\r\n inet_server_addr\r\n------------------\r\n 172.17.0.6\r\n(1 row)\r\n\r\npod "postgresql-postgresql-client" deleted\r\n<\/pre>\n
\r\n$ kubectl get pods,svc,statefulset -n kubegres-system\r\nNAME READY STATUS RESTARTS AGE\r\npod\/kpostgres-2-0 1\/1 Running 0 85s\r\npod\/kpostgres-3-0 1\/1 Running 0 43s\r\npod\/kubegres-controller-manager-794468bbff-bxzxk 2\/2 Running 18 (41m ago) 6d7h\r\n\r\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\r\nservice\/kpostgres ClusterIP None <none> 5432\/TCP 6d5h\r\nservice\/kpostgres-replica ClusterIP None <none> 5432\/TCP 6d5h\r\nservice\/kubegres-controller-manager-metrics-service ClusterIP 10.100.182.92 <none> 8443\/TCP 6d7h\r\n\r\nNAME READY AGE\r\nstatefulset.apps\/kpostgres-2 1\/1 6d5h\r\nstatefulset.apps\/kpostgres-3 1\/1 43s\r\n<\/pre>\n
Param\u00e9trer des sauvegardes<\/h2>\n
\r\n$ vi postgres-backup.yaml\r\n(...)\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: my-backup-pvc\r\n namespace: kubegres-system\r\nspec:\r\n storageClassName: "standard"\r\n accessModes:\r\n - ReadWriteOnce\r\n resources:\r\n requests:\r\n storage: 200Mi\r\n\r\n$ kubectl apply -f postgres-backup.yaml\r\npersistentvolumeclaim\/my-backup-pvc created\r\n\r\n$ kubectl get pvc -n kubegres-system\r\nNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE\r\nmy-backup-pvc Bound pvc-b84656cd-904b-4a2b-89b1-e43ddb062be8 200Mi RWO standard 16s\r\npostgres-db-kpostgres-1-0 Bound pvc-03f2e981-a1aa-446e-8f63-e5164a59f742 200Mi RWO standard 6d6h\r\npostgres-db-kpostgres-2-0 Bound pvc-cbdf5810-e5e0-4950-8b06-5243f835be7d 200Mi RWO standard 6d6h\r\npostgres-db-kpostgres-3-0 Bound pvc-dffef05b-f7b6-4618-802f-5fbfff2a0cba 200Mi RWO standard 37m\r\n<\/pre>\n
\r\n$ kubectl get CronJob -n kubegres-system\r\nNAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE\r\nbackup-kpostgres *\/5 * * * * False 0 72s 3m38s\r\n<\/pre>\n
\r\n$ kubectl get pods -n kubegres-system\r\nNAME READY STATUS RESTARTS AGE\r\nbackup-kpostgres-28032310-97jqx 0\/1 Completed 0 85s\r\nkpostgres-4-0 1\/1 Running 0 5m2s\r\nkpostgres-5-0 1\/1 Running 0 4m4s\r\nkubegres-controller-manager-794468bbff-bxzxk 2\/2 Running 18 (99m ago) 6d8h\r\n\r\n$ kubectl logs backup-kpostgres-28032310-97jqx -n kubegres-system\r\n19\/04\/2023 21:10:01 - Starting DB backup of Kubegres resource kpostgres into file: \/var\/lib\/backup\/kpostgres-backup-19_04_2023_21_10_01.gz\r\n19\/04\/2023 21:10:01 - Running: pg_dumpall -h kpostgres-replica -U postgres -c | gzip > \/var\/lib\/backup\/kpostgres-backup-19_04_2023_21_10_01.\r\ngz\r\n19\/04\/2023 21:10:01 - DB backup completed for Kubegres resource kpostgres into file: \/var\/lib\/backup\/kpostgres-backup-19_04_2023_21_10_01.gz\r\n<\/pre>\n
Conclusion<\/h2>\n
\nNous ne l’avons pas abord\u00e9 ici, mais il est aussi possible de customiser la configuration en r\u00e9alisant son propre ConfigMap, cr\u00e9er d’autres PVC pour g\u00e9rer les archives etc… Dans le prochain \u00e9pisode, nous le comparerons \u00e0 PGO<\/a>, l’op\u00e9rateur concurrent de CrunchyDB.<\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"