![\"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>Salut \u00e0 toutes et tous ! Cette semaine la suite de notre petit tour des op\u00e9rateurs Kubernetes pour PostgreSQL, et apr\u00e8s kubegres<\/a>, c’est au tour de PGO <\/a>de CrunchyData. <\/p>\n Compar\u00e9 \u00e0 Kubegres, PGO semble plus complet dans le sens o\u00f9 il int\u00e8gre de base un r\u00e9plica par d\u00e9faut, mais aussi la possibilit\u00e9 de backuper directement avec pgBackRest<\/a> dans des repositories locaux ou cloud, un pod pgBouncer<\/a>, et un exporter pour Prometheus<\/a>. <\/p>\n Comme pour kubegres, l’operateur PGO encapsule \u00e0 l’int\u00e9rieur de ses deployments <\/em>des objets de base Kubernetes tels que des StatefulSets pour les pods primaire et replicas, des Services, des PV et PVC pour le stockage, etc… comme nous allons le voir lors du deploiement de notre premier cluster. <\/p>\n Premi\u00e8re chose \u00e0 faire avant de cr\u00e9er notre premier cluster, d\u00e9ployer l’op\u00e9rateur PGO. Il est possible de le faire au choix soit via Kustomize <\/a>soit via Helm<\/a>. CrunchyData propose un repo git \u00e0 cloner<\/a> et qui contient d\u00e9j\u00e0 les fichiers de configuration de base, que nous pourrons modifier au besoin pour customiser notre d\u00e9ploiement. Une fois le git clon\u00e9 sur notre github Capdata, nous pouvons commencer \u00e0 r\u00e9cup\u00e9rer les fichiers en local et regarder le contenu des fichiers de d\u00e9finition. Nous utiliserons Kustomize pour l’exemple :<\/p>\n L’apply de ~kustomize\/install\/namespace\/namespace.yaml va cr\u00e9er un namespace d\u00e9di\u00e9 postgres-operator<\/em>: <\/p>\n Puis ~kustomize\/install\/default va cr\u00e9er le reste de l’op\u00e9rateur:<\/p>\n Maintenant que notre op\u00e9rateur est install\u00e9, c’est le moment de s’int\u00e9resser au param\u00e9trage du futur cluster. Tout se trouve dans ~kustomize\/postgres:<\/p>\n Le coeur de notre cluster se trouve dans postgresl.yaml :<\/p>\n Comme pour Kubegres, l’op\u00e9rateur PGO nous permet de cr\u00e9er un nouveau type d’objet dans Kubernetes :<\/p>\n Le nom du cluster par d\u00e9faut est ‘hippo<\/em>‘ mais nous pourrons le changer sans probl\u00e8me. Pour les pods (primaire, r\u00e9plicas, pgBackRest), les images sont pr\u00e9cis\u00e9es ainsi que les volumes qui sont rattach\u00e9s via des abstractions de PVC appel\u00e9es soit “dataVolumeClaimSpec<\/em>” pour les pods PostgreSQL soit “VolumeClaimSpec<\/em>” pour la partie sauvegarde. <\/p>\n Nous pouvons compl\u00e9ter le fichier de d\u00e9finition par d\u00e9faut avec quelques customisations: Pour la configuration des sauvegardes, nous verrons un peu plus tard. Dans l’imm\u00e9diat, cr\u00e9ons notre cluster:<\/p>\n Il se peut qu’il y ait des probl\u00e8mes de quota m\u00e9moire \/ CPU disponible, les pods vont rester en Pending, et la suppression \/ recr\u00e9ation des objets ne suffit pas. La suppression du namespace se bloque en Terminating il a fallu que je d\u00e9roule la proc\u00e9dure de suppression du namespace \u00e0 la main<\/a> pour repartir de z\u00e9ro. <\/p>\n Bref notre d\u00e9ploiement nous a donc cr\u00e9\u00e9 3 nouveaux pods et 3 StatefulSets (primaire, r\u00e9plica et pgBackRest), 4 services ClusterIP et notre nodePort. <\/p>\n Pour nous y connecter, nous avons besoin de r\u00e9cup\u00e9rer le secret<\/a> qui a \u00e9t\u00e9 cr\u00e9\u00e9 \u00e0 l’initialisation du cluster. Jetons un coup d’oeil au secret dans sa globalit\u00e9 pour voir ce qu’il contient:<\/p>\n On a donc la possibilit\u00e9 de r\u00e9cup\u00e9rer le user et le mot de passe :<\/p>\n Et tester la connexion (noter que l’adresse IP est celle du node, ie kubectl describe nodes<\/em>):<\/p>\n Lan\u00e7ons une connexion en boucle sur le nodePort pour r\u00e9cup\u00e9rer l’IP de l’instance primaire et voir ce qui se passe en cas de bascule. <\/p>\n Pour tester la bascule, nous allons carr\u00e9ment supprimer le StatefulSet de l’instance primaire, il faut commencer par r\u00e9cup\u00e9rer son nom, puis on supprime :<\/p>\n La connexion en boucle indique que l’on a bien chang\u00e9 d’IP:<\/p>\n … et minikube a d\u00e9tect\u00e9 la perte du StatefulSet pgcluster1-postgresdb1-9w2w<\/em> et l’a recr\u00e9\u00e9 en arri\u00e8re plan:<\/p>\n Il existe un certain nombre d’options compl\u00e9mentaires notamment de l’anti-affinit\u00e9 pour \u00e9viter que les pods ne tournent sur les m\u00eames nodes, voir la documentation <\/a>pour plus de d\u00e9tails.<\/p>\n Bien qu’il soit possible de sauvegarder directement sur AWS S3, Azure ou GCP, pour l’exemple nous avons d\u00e9ploy\u00e9 un volume Kubernetes simple. Kubernetes a cr\u00e9\u00e9 un cronjob associ\u00e9. Sachant que les backups peuvent \u00eatre aussi diff\u00e9rentiels ou incr\u00e9mentaux selon la strat\u00e9gie de sauvegarde envisag\u00e9e. Dans cette premi\u00e8re approche de PGO, nous n’avons fait qu’effleurer la surface des possibilit\u00e9s de cet op\u00e9rateur, qui semble aller plus loin que ses concurrents avec: Salut \u00e0 toutes et tous ! Cette semaine la suite de notre petit tour des op\u00e9rateurs Kubernetes pour PostgreSQL, et apr\u00e8s kubegres, c’est au tour de PGO de CrunchyData. Quelques infos g\u00e9n\u00e9rales sur l’op\u00e9rateur PGO Compar\u00e9 \u00e0 Kubegres, PGO semble… Continuer la lecture ![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/06\/pgo2.png\")
<\/a><\/p>\nQuelques infos g\u00e9n\u00e9rales sur l’op\u00e9rateur PGO<\/h2>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/06\/pgo1-1.png\")
<\/a>
\nInstallation de l’op\u00e9rateur PGO<\/h2>\n
\r\n$ git clone --depth=1 "https:\/\/github.com\/Capdata\/postgres-operator-examples.git"\r\nCloning into 'postgres-operator-examples'...\r\nremote: Enumerating objects: 140, done.\r\nremote: Counting objects: 100% (140\/140), done.\r\nremote: Compressing objects: 100% (105\/105), done.\r\nremote: Total 140 (delta 33), reused 81 (delta 26), pack-reused 0\r\nReceiving objects: 100% (140\/140), 150.57 KiB | 3.01 MiB\/s, done.\r\nResolving deltas: 100% (33\/33), done.\r\n\r\n$ cd postgres-operator-examples\/kustomize\r\n\r\n$ tree -a install\/namespace\/\r\ninstall\/namespace\/\r\n\u251c\u2500\u2500 kustomization.yaml\r\n\u2514\u2500\u2500 namespace.yaml\r\n\r\n$ tree -a install\/default\/\r\ninstall\/default\/\r\n\u251c\u2500\u2500 kustomization.yaml\r\n\u2514\u2500\u2500 selectors.yaml\r\n\r\n<\/pre>\n
\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: postgres-operator\r\n<\/pre>\n
\r\n$ kubectl apply --kustomize=kustomize\/install\/namespace\r\nnamespace\/postgres-operator created\r\n\r\n$ kubectl apply --server-side --kustomize=kustomize\/install\/default\r\ncustomresourcedefinition.apiextensions.k8s.io\/pgupgrades.postgres-operator.crunchydata.com serverside-applied\r\ncustomresourcedefinition.apiextensions.k8s.io\/postgresclusters.postgres-operator.crunchydata.com serverside-applied\r\nserviceaccount\/pgo serverside-applied\r\nserviceaccount\/postgres-operator-upgrade serverside-applied\r\nclusterrole.rbac.authorization.k8s.io\/postgres-operator serverside-applied\r\nclusterrole.rbac.authorization.k8s.io\/postgres-operator-upgrade serverside-applied\r\nclusterrolebinding.rbac.authorization.k8s.io\/postgres-operator serverside-applied\r\nclusterrolebinding.rbac.authorization.k8s.io\/postgres-operator-upgrade serverside-applied\r\ndeployment.apps\/pgo serverside-applied\r\ndeployment.apps\/pgo-upgrade serverside-applied\r\n\r\n$ kubectl get all --namespace=postgres-operator\r\nNAME READY STATUS RESTARTS AGE\r\npod\/pgo-774db98dbc-htm5d 1\/1 Running 0 74m\r\npod\/pgo-upgrade-785dd6dc4c-cw2ld 1\/1 Running 0 74m\r\n\r\nNAME READY UP-TO-DATE AVAILABLE AGE\r\ndeployment.apps\/pgo 1\/1 1 1 74m\r\ndeployment.apps\/pgo-upgrade 1\/1 1 1 74m\r\n\r\nNAME DESIRED CURRENT READY AGE\r\nreplicaset.apps\/pgo-774db98dbc 1 1 1 74m\r\nreplicaset.apps\/pgo-upgrade-785dd6dc4c 1 1 1 74m\r\n\r\n<\/pre>\n
Cr\u00e9ation d’un premier cluster PGO<\/h2>\n
\r\n$ tree -a postgres\/\r\npostgres\/\r\n\u251c\u2500\u2500 kustomization.yaml\r\n\u2514\u2500\u2500 postgres.yaml\r\n<\/pre>\n
\r\napiVersion: postgres-operator.crunchydata.com\/v1beta1\r\nkind: PostgresCluster\r\nmetadata:\r\n name: hippo\r\nspec:\r\n image: registry.developers.crunchydata.com\/crunchydata\/crunchy-postgres:ubi8-15.2-0\r\n postgresVersion: 15\r\n instances:\r\n - name: instance1\r\n dataVolumeClaimSpec:\r\n accessModes:\r\n - "ReadWriteOnce"\r\n resources:\r\n requests:\r\n storage: 1Gi\r\n backups:\r\n pgbackrest:\r\n image: registry.developers.crunchydata.com\/crunchydata\/crunchy-pgbackrest:ubi8-2.41-4\r\n repos:\r\n - name: repo1\r\n volume:\r\n volumeClaimSpec:\r\n accessModes:\r\n - "ReadWriteOnce"\r\n resources:\r\n requests:\r\n storage: 1Gi\r\n<\/pre>\n
\r\nkind: PostgresCluster\r\n<\/pre>\n
\n– Ajouter des quotas de ressources CPU et m\u00e9moire via instances.resources.limits<\/em>
\n– Ajouter un r\u00e9plica
\n– Renommer notre cluster ‘pgcluster1<\/em>‘
\n– Et enfin ajouter un nodePort pour exposer notre cluster au monde ext\u00e9rieur :<\/p>\n\r\napiVersion: postgres-operator.crunchydata.com\/v1beta1\r\nkind: PostgresCluster\r\nmetadata:\r\n name: pgcluster1\r\nspec:\r\n image: registry.developers.crunchydata.com\/crunchydata\/crunchy-postgres:ubi8-15.2-0\r\n postgresVersion: 15\r\n instances:\r\n - name: postgresdb1\r\n replicas: 2\r\n resources:\r\n limits:\r\n cpu: "0.5"\r\n memory: 1Gi\r\n dataVolumeClaimSpec:\r\n accessModes:\r\n - "ReadWriteOnce"\r\n resources:\r\n requests:\r\n storage: 1Gi\r\n backups:\r\n pgbackrest:\r\n image: registry.developers.crunchydata.com\/crunchydata\/crunchy-pgbackrest:ubi8-2.41-4\r\n repos:\r\n - name: repo1\r\n volume:\r\n volumeClaimSpec:\r\n accessModes:\r\n - "ReadWriteOnce"\r\n resources:\r\n requests:\r\n storage: 1Gi\r\n service:\r\n metadata:\r\n annotations:\r\n annotation1: "mdnodeport1"\r\n labels:\r\n label1: "32000"\r\n type: NodePort\r\n nodePort: 32000\r\n<\/pre>\n
\r\n$ kubectl apply -k kustomize\/postgres\/\r\npostgrescluster.postgres-operator.crunchydata.com\/pgcluster1 created\r\n\r\n$ kubectl get all --namespace=postgres-operator\r\nNAME READY STATUS RESTARTS AGE\r\npod\/pgcluster1-postgresdb1-55pl-0 4\/4 Running 0 11s\r\npod\/pgcluster1-postgresdb1-9w2w-0 4\/4 Running 0 11s\r\npod\/pgcluster1-repo-host-0 2\/2 Running 0 11s\r\npod\/pgo-774db98dbc-tshp6 1\/1 Running 0 68s\r\npod\/pgo-upgrade-785dd6dc4c-ntwkd 1\/1 Running 0 68s\r\n\r\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\r\nservice\/pgcluster1-ha NodePort 10.102.232.74 <none> 5432:32000\/TCP 51m\r\nservice\/pgcluster1-ha-config ClusterIP None <none> <none> 51m\r\nservice\/pgcluster1-pods ClusterIP None <none> <none> 51m\r\nservice\/pgcluster1-primary ClusterIP None <none> 5432\/TCP 51m\r\nservice\/pgcluster1-replicas ClusterIP 10.106.148.50 <none> 5432\/TCP 51m\r\n\r\nNAME READY UP-TO-DATE AVAILABLE AGE\r\ndeployment.apps\/pgo 1\/1 1 1 69s\r\ndeployment.apps\/pgo-upgrade 1\/1 1 1 68s\r\n\r\nNAME DESIRED CURRENT READY AGE\r\nreplicaset.apps\/pgo-774db98dbc 1 1 1 68s\r\nreplicaset.apps\/pgo-upgrade-785dd6dc4c 1 1 1 68s\r\n\r\nNAME READY AGE\r\nstatefulset.apps\/pgcluster1-postgresdb1-55pl 1\/1 11s\r\nstatefulset.apps\/pgcluster1-postgresdb1-9w2w 1\/1 11s\r\nstatefulset.apps\/pgcluster1-repo-host 1\/1 11s\r\n<\/pre>\n
\r\n$ kubectl get secret --namespace=postgres-operator pgcluster1-pguser-pgcluster1 -o json\r\n{\r\n "apiVersion": "v1",\r\n "data": {\r\n "dbname": "cGdjbHVzdGVyMQ==",\r\n "host": "cGdjbHVzdGVyMS1wcmltYXJ5LnBvc3RncmVzLW9wZXJhdG9yLnN2Yw==",\r\n "jdbc-uri": "amRiYzpwb3N0Z3Jlc3FsOi8vcGdjbHVzdGVyMS1wcmltYXJ5LnBvc3RncmVzLW9wZXJhdG9yLnN2Yzo1NDMyL3BnY2x1c3RlcjE\/cGFzc3dvcmQ9UHBybiUzQnZ1WDlrSiU1RE1WQnZwd3QzTk5wJTJBJnVzZXI9cGdjbHVzdGVyMQ==",\r\n "password": "UHBybjt2dVg5a0pdTVZCdnB3dDNOTnAq",\r\n "port": "NTQzMg==",\r\n "uri": "cG9zdGdyZXNxbDovL3BnY2x1c3RlcjE6UHBybjt2dVg5a0olNURNVkJ2cHd0M05OcCUyQUBwZ2NsdXN0ZXIxLXByaW1hcnkucG9zdGdyZXMtb3BlcmF0b3Iuc3ZjOjU0MzIvcGdjbHVzdGVyMQ==",\r\n "user": "cGdjbHVzdGVyMQ==",\r\n "verifier": "U0NSQU0tU0hBLTI1NiQ0MDk2Olo3OTNBUVIwU0xZUVBDY3BXNkRaSXc9PSRWUWdlc0VlSGVvVnpnakc4emkyRGJJNmlpemo1ZnJGWmN2K3c3NzZScVhVPTpDT1JDVStoQU1IeDBkRzBKaGU3dllwUTdFWTB4QzZ5RzJUUE5NWFV5MTlRPQ=="\r\n },\r\n "kind": "Secret",\r\n "metadata": {\r\n "creationTimestamp": "2023-06-05T11:39:32Z",\r\n "labels": {\r\n "postgres-operator.crunchydata.com\/cluster": "pgcluster1",\r\n "postgres-operator.crunchydata.com\/pguser": "pgcluster1",\r\n "postgres-operator.crunchydata.com\/role": "pguser"\r\n },\r\n "name": "pgcluster1-pguser-pgcluster1",\r\n "namespace": "postgres-operator",\r\n "ownerReferences": [\r\n {\r\n "apiVersion": "postgres-operator.crunchydata.com\/v1beta1",\r\n "blockOwnerDeletion": true,\r\n "controller": true,\r\n "kind": "PostgresCluster",\r\n "name": "pgcluster1",\r\n "uid": "80bbee62-0602-4012-9c06-dcd23ca7723b"\r\n }\r\n ],\r\n "resourceVersion": "169451",\r\n "uid": "fe833c97-0585-4910-95ca-fb1c7774d5b2"\r\n },\r\n "type": "Opaque"\r\n}\r\n<\/pre>\n\r\n$ export PGUSER=$(kubectl get secret --namespace=postgres-operator pgcluster1-pguser-pgcluster1 -o jsonpath={.data.user} | base64 -d)\r\n$ export PGPASSWORD=$(kubectl get secret --namespace=postgres-operator pgcluster1-pguser-pgcluster1 -o jsonpath={.data.password} | base64 -d)\r\n<\/pre>\n\r\n$ psql -h 192.168.59.101 -p 32000 -c "select version();"\r\n version\r\n---------------------------------------------------------------------------------------------------------\r\n PostgreSQL 15.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-16), 64-bit\r\n(1 row)\r\n<\/pre>\n
Bascules et haute disponibilit\u00e9<\/h2>\n
\r\n$ while(true); do psql -h 192.168.59.101 -p 32000 -c "select inet_server_addr();"; sleep 1; done\r\n inet_server_addr\r\n------------------\r\n 172.17.0.7\r\n(1 row)\r\n\r\n inet_server_addr\r\n------------------\r\n 172.17.0.7\r\n(1 row)\r\n\r\n(...)\r\n<\/pre>\n
\r\n$ kubectl -n postgres-operator get pods \\\r\n --selector=postgres-operator.crunchydata.com\/role=master \\\r\n -o jsonpath='{.items[*].metadata.labels.postgres-operator\\.crunchydata\\.com\/instance}'\r\npgcluster1-postgresdb1-9w2w\r\n\r\n$ kubectl delete statefulset --namespace=postgres-operator pgcluster1-postgresdb1-9w2w\r\nstatefulset.apps "pgcluster1-postgresdb1-9w2w" deleted\r\n<\/pre>\n\r\n(...)\r\n inet_server_addr\r\n------------------\r\n 172.17.0.7\r\n(1 row)\r\n\r\n inet_server_addr\r\n------------------\r\n 172.17.0.7\r\n(1 row)\r\n\r\n inet_server_addr\r\n------------------\r\n 172.17.0.6\r\n(1 row)\r\n\r\n inet_server_addr\r\n------------------\r\n 172.17.0.6\r\n(1 row)\r\n<\/pre>\n
\r\n$ kubectl get statefulset --namespace=postgres-operator\r\nNAME READY AGE\r\npgcluster1-postgresdb1-55pl 1\/1 96m\r\npgcluster1-postgresdb1-9w2w 1\/1 11s\r\npgcluster1-repo-host 1\/1 96m\r\n<\/pre>\n
Mise en place des backups via pgbackrest<\/h2>\n
\nPour ajouter une planification et une r\u00e9tention il faut rajouter quelques propri\u00e9t\u00e9s \u00e0 spec.backups.pgbackrest<\/em> :<\/p>\n\r\n backups:\r\n pgbackrest:\r\n image: registry.developers.crunchydata.com\/crunchydata\/crunchy-pgbackrest:ubi8-2.41-4\r\n global:\r\n\t repo1-retention-full: "14"\r\n repo1-retention-full-type: time\r\n repos:\r\n - name: repo1\r\n volume:\r\n volumeClaimSpec:\r\n accessModes:\r\n - "ReadWriteOnce"\r\n resources:\r\n requests:\r\n storage: 1Gi\r\n\tschedules:\r\n\t full: "50 15 * * *"\r\n<\/pre>\n
\r\n$ kubectl apply -k kustomize\/postgres\/\r\npostgrescluster.postgres-operator.crunchydata.com\/pgcluster1 configured\r\n\r\n$ kubectl get cronjobs --namespace=postgres-operator\r\nNAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE\r\npgcluster1-repo1-full 50 15 * * * False 0 <none> 106s\r\n<\/pre>\n
\nLa r\u00e9tention quant \u00e0 elle peut \u00eatre indiqu\u00e9e en jours (time<\/em>) ou en nombre de sauvegardes (count<\/em>). Gr\u00e2ce \u00e0 pgBackRest, PGO permettra ensuite d’utiliser les backups pour soit cloner les bases vers une autre cluster, soit le restaurer \u00e0 un point dans le temps vers un nouveau cluster (pour comparer les donn\u00e9es ou r\u00e9cup\u00e9rer des lignes supprim\u00e9es par erreur par exemple), ou restaurer in-place. Le sujet est assez long et cela pourra faire l’objet d’un futur \u00e9pisode, mais globalement la puissance de feu de pgBackRest au service de la restaurabilit\u00e9 donne un atout suppl\u00e9mentaire \u00e0 PGO par rapport \u00e0 ses concurrents. <\/p>\nConclusion<\/h2>\n
\n– La sauvegarde et restauration via pgBackRest int\u00e9gr\u00e9, et la possibilit\u00e9 de sauvegarder directement dans le cloud.
\n– Int\u00e9gration avec Promotheus.
\n– Int\u00e9gration avec pgBouncer.
\n– D\u00e9ployable directement via des standards tels que Kustomize ou Helm.
\n– Gestion des secrets int\u00e9gr\u00e9e.
\netc… S\u00fbrement que d’autres articles pour approfondir PGO viendront compl\u00e9ter celui-ci, en attendant bonne lecture et \u00e0 bient\u00f4t sur le blog Cap Data !<\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"