diff --git a/docs/guides/pgbouncer/concepts/autoscaler.md b/docs/guides/pgbouncer/concepts/autoscaler.md new file mode 100644 index 0000000000..103d91eb54 --- /dev/null +++ b/docs/guides/pgbouncer/concepts/autoscaler.md @@ -0,0 +1,73 @@ +--- +title: PgBouncerAutoscaler CRD +menu: + docs_{{ .version }}: + identifier: pb-autoscaler-concepts + name: PgBouncerAutoscaler + parent: pb-concepts-pgbouncer + weight: 35 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# PgBouncerAutoscaler + +## What is PgBouncerAutoscaler + +`PgBouncerAutoscaler` is a Kubernetes `Custom Resource Definitions` (CRD). It provides a declarative configuration for autoscaling [PgBouncer](https://pgbouncer.net/mediawiki/index.php/Main_Page) compute resources of PgBouncer components in a Kubernetes native way. + +## PgBouncerAutoscaler CRD Specifications + +Like any official Kubernetes resource, a `PgBouncerAutoscaler` has `TypeMeta`, `ObjectMeta`, `Spec` and `Status` sections. + +Here, some sample `PgBouncerAutoscaler` CROs for autoscaling different components of pgbouncer is given below: + +**Sample `PgBouncerAutoscaler` for pgbouncer:** + +```yaml +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: PgBouncerAutoscaler +metadata: + name: pgbouncer-auto-scale + namespace: demo +spec: + databaseRef: + name: pgbouncer-server + compute: + pgbouncer: + trigger: "On" + podLifeTimeThreshold: 24h + minAllowed: + cpu: 250m + memory: 350Mi + maxAllowed: + cpu: 1 + memory: 1Gi + controlledResources: ["cpu", "memory"] + containerControlledValues: "RequestsAndLimits" + resourceDiffPercentage: 10 +``` + +Here, we are going to describe the various sections of a `PgBouncerAutoscaler` crd. + +A `PgBouncerAutoscaler` object has the following fields in the `spec` section. + +### spec.databaseRef + +`spec.databaseRef` is a required field that point to the [PgBouncer](/docs/guides/pgbouncer/concepts/pgbouncer.md) object for which the autoscaling will be performed. This field consists of the following sub-field: + +- **spec.databaseRef.name :** specifies the name of the [PgBouncer](/docs/guides/pgbouncer/concepts/pgbouncer.md) object. + +### spec.compute + +`spec.compute` specifies the autoscaling configuration for the compute resources i.e. cpu and memory of PgBouncer components. This field consists of the following sub-field: + +- `trigger` indicates if compute autoscaling is enabled for this component of the pgbouncer. If "On" then compute autoscaling is enabled. If "Off" then compute autoscaling is disabled. +- `minAllowed` specifies the minimal amount of resources that will be recommended, default is no minimum. +- `maxAllowed` specifies the maximum amount of resources that will be recommended, default is no maximum. +- `controlledResources` specifies which type of compute resources (cpu and memory) are allowed for autoscaling. Allowed values are "cpu" and "memory". +- `containerControlledValues` specifies which resource values should be controlled. Allowed values are "RequestsAndLimits" and "RequestsOnly". +- `resourceDiffPercentage` specifies the minimum resource difference between recommended value and the current value in percentage. If the difference percentage is greater than this value than autoscaling will be triggered. +- `podLifeTimeThreshold` specifies the minimum pod lifetime of at least one of the pods before triggering autoscaling. \ No newline at end of file diff --git a/docs/guides/pgbouncer/concepts/opsrequest.md b/docs/guides/pgbouncer/concepts/opsrequest.md new file mode 100644 index 0000000000..45ba3aaa92 --- /dev/null +++ b/docs/guides/pgbouncer/concepts/opsrequest.md @@ -0,0 +1,330 @@ +--- +title: PgBouncerOpsRequests CRD +menu: + docs_{{ .version }}: + identifier: pb-opsrequest-concepts + name: PgBouncerOpsRequest + parent: pb-concepts-pgbouncer + weight: 25 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# PgBouncerOpsRequest + +## What is PgBouncerOpsRequest + +`PgBouncerOpsRequest` is a Kubernetes `Custom Resource Definitions` (CRD). It provides a declarative configuration for [PgBouncer](https://pgbouncer.net/mediawiki/index.php/Main_Page) administrative operations like version updating, horizontal scaling, vertical scaling etc. in a Kubernetes native way. + +## PgBouncerOpsRequest CRD Specifications + +Like any official Kubernetes resource, a `PgBouncerOpsRequest` has `TypeMeta`, `ObjectMeta`, `Spec` and `Status` sections. + +Here, some sample `PgBouncerOpsRequest` CRs for different administrative operations is given below: + +**Sample `PgBouncerOpsRequest` for updating version:** + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-version-update + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: pgbouncer-server + updateVersion: + targetVersion: 1.18.0 +``` + +**Sample `PgBouncerOpsRequest` Objects for Horizontal Scaling:** + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-horizontal-scale + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: pgbouncer-server + horizontalScaling: + replicas: 2 +``` + +**Sample `PgBouncerOpsRequest` Objects for Vertical Scaling:** + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-vertical-scale + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: pgbouncer-server + verticalScaling: + pgbouncer: + resources: + requests: + memory: "1200Mi" + cpu: "0.7" + limits: + memory: "1200Mi" + cpu: "0.7" +``` + +**Sample `PgBouncerOpsRequest` Objects for Reconfiguring:** + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-reconfigure + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: pgbouncer-server + configuration: + pgbouncer: + applyConfig: + pgbouncer.conf: |- + auth_type = scram-sh-256 +``` + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-reconfigure + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: pgbouncer-server + configuration: + removeCustomConfig: true +``` + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: pgbouncer-reconfigure + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: pgbouncer-server + configuration: + configSecret: + name: new-custom-config +``` + + +**Sample `PgBouncerOpsRequest` Objects for Reconfiguring TLS:** + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: pgbouncer-server + tls: + sslMode: verify-ca + clientAuthMode: cert + issuerRef: + name: pgbouncer-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + certificates: + - alias: client + subject: + organizations: + - kubedb + organizationalUnits: + - client +``` + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: pgbouncer-server + tls: + rotateCertificates: true +``` + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: PgBouncerOpsRequest +metadata: + name: tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: pgbouncer-server + tls: + remove: true +``` + +Here, we are going to describe the various sections of a `PgBouncerOpsRequest` crd. + +A `PgBouncerOpsRequest` object has the following fields in the `spec` section. + +### spec.databaseRef + +`spec.databaseRef` is a required field that point to the [PgBouncer](/docs/guides/pgbouncer/concepts/pgbouncer.md) object for which the administrative operations will be performed. This field consists of the following sub-field: + +- **spec.databaseRef.name :** specifies the name of the [PgBouncer](/docs/guides/pgbouncer/concepts/pgbouncer.md) object. + +### spec.type + +`spec.type` specifies the kind of operation that will be applied to the database. Currently, the following types of operations are allowed in `PgBouncerOpsRequest`. + +- `UpdateVersion` +- `HorizontalScaling` +- `VerticalScaling` +- `Reconfigure` +- `ReconfigureTLS` +- `Restart` + +> You can perform only one type of operation on a single `PgBouncerOpsRequest` CR. For example, if you want to update your database and scale up its replica then you have to create two separate `PgBouncerOpsRequest`. At first, you have to create a `PgBouncerOpsRequest` for updating. Once it is completed, then you can create another `PgBouncerOpsRequest` for scaling. + +> Note: There is an exception to the above statement. It is possible to specify both `spec.configuration` & `spec.verticalScaling` in a OpsRequest of type `VerticalScaling`. + +### spec.updateVersion + +If you want to update your PgBouncer version, you have to specify the `spec.updateVersion` section that specifies the desired version information. This field consists of the following sub-field: + +- `spec.updateVersion.targetVersion` refers to a [PgBouncerVersion](/docs/guides/pgbouncer/concepts/catalog.md) CR that contains the PgBouncer version information where you want to update. + + +### spec.horizontalScaling + +If you want to scale-up or scale-down your PgBouncer cluster or different components of it, you have to specify `spec.horizontalScaling` section. This field consists of the following sub-field: + +- `spec.horizontalScaling.replicas` indicates the desired number of pods for PgBouncer cluster after scaling. For example, if your cluster currently has 4 pods, and you want to add additional 2 pods then you have to specify 6 in `spec.horizontalScaling.replicas` field. Similarly, if you want to remove one pod from the cluster, you have to specify 3 in `spec.horizontalScaling.replicas` field. + +### spec.verticalScaling + +`spec.verticalScaling` is a required field specifying the information of resources like `cpu`, `memory` etc. that will be scaled. This field consists of the following sub-fields: + +- `spec.verticalScaling.pgbouncer` indicates the desired resources for PetSet of PgBouncer after scaling. +- `spec.verticalScaling.exporter` indicates the desired resources for PetSet of PgBouncer Exporter after scaling. + +It has the below structure: + +```yaml +requests: + memory: "200Mi" + cpu: "0.1" +limits: + memory: "300Mi" + cpu: "0.2" +``` + +Here, when you specify the resource request, the scheduler uses this information to decide which node to place the container of the Pod on and when you specify a resource limit for the container, the `kubelet` enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. You can found more details from [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). + + +### spec.configuration + +If you want to reconfigure your Running PgBouncer cluster or different components of it with new custom configuration, you have to specify `spec.configuration` section. This field consists of the following sub-field: + +- `configSecret` points to a secret in the same namespace of a PgBouncer resource, which contains the new custom configurations. If there are any configSecret set before in the database, this secret will replace it. +- `applyConfig` contains the new custom config as a string which will be merged with the previous configuration. + +- `applyConfig` is a map where key supports 1 values, namely `pgbouncer.ini`. + +```yaml + applyConfig: + pgbouncer.conf: |- + max_pool = 30 +``` + +- `removeCustomConfig` is a boolean field. Specify this field to true if you want to remove all the custom configuration from the deployed pgbouncer server. + +### spec.tls + +If you want to reconfigure the TLS configuration of your pgbouncer cluster i.e. add TLS, remove TLS, update issuer/cluster issuer or Certificates and rotate the certificates, you have to specify `spec.tls` section. This field consists of the following sub-field: + +- `spec.tls.issuerRef` specifies the issuer name, kind and api group. +- `spec.tls.certificates` specifies the certificates. You can learn more about this field from [here](/docs/guides/pgbouncer/concepts/pgbouncer.md#spectls). +- `spec.tls.rotateCertificates` specifies that we want to rotate the certificate of this database. +- `spec.tls.remove` specifies that we want to remove tls from this database. +- `spec.tls.sslMode` specifies what will be the ssl mode of the cluster allowed values are: disable,allow,prefer,require,verify-ca,verify-full +- `spec.tls.clientAuthMode` specifies what will be the client authentication mode of the cluster allowed values are: md5,scram,cert + +### spec.timeout +As we internally retry the ops request steps multiple times, This `timeout` field helps the users to specify the timeout for those steps of the ops request (in second). +If a step doesn't finish within the specified timeout, the ops request will result in failure. + +### spec.apply +This field controls the execution of opsRequest depending on the database state. It has two supported values: `Always` & `IfReady`. +Use IfReady, if you want to process the opsRequest only when the database is Ready. And use Always, if you want to process the execution of opsReq irrespective of the Database state. + + +### PgBouncerOpsRequest `Status` + +`.status` describes the current state and progress of a `PgBouncerOpsRequest` operation. It has the following fields: + +### status.phase + +`status.phase` indicates the overall phase of the operation for this `PgBouncerOpsRequest`. It can have the following three values: + +| Phase | Meaning | +|-------------|------------------------------------------------------------------------------------| +| Successful | KubeDB has successfully performed the operation requested in the PgBouncerOpsRequest | +| Progressing | KubeDB has started the execution of the applied PgBouncerOpsRequest | +| Failed | KubeDB has failed the operation requested in the PgBouncerOpsRequest | +| Denied | KubeDB has denied the operation requested in the PgBouncerOpsRequest | +| Skipped | KubeDB has skipped the operation requested in the PgBouncerOpsRequest | + +Important: Ops-manager Operator can skip an opsRequest, only if its execution has not been started yet & there is a newer opsRequest applied in the cluster. `spec.type` has to be same as the skipped one, in this case. + +### status.observedGeneration + +`status.observedGeneration` shows the most recent generation observed by the `PgBouncerOpsRequest` controller. + +### status.conditions + +`status.conditions` is an array that specifies the conditions of different steps of `PgBouncerOpsRequest` processing. Each condition entry has the following fields: + +- `types` specifies the type of the condition. PgBouncerOpsRequest has the following types of conditions: + +| Type | Meaning | +|--------------------------------|---------------------------------------------------------------------------| +| `Progressing` | Specifies that the operation is now in the progressing state | +| `Successful` | Specifies such a state that the operation on the database was successful. | +| `DatabasePauseSucceeded` | Specifies such a state that the database is paused by the operator | +| `ResumeDatabase` | Specifies such a state that the database is resumed by the operator | +| `Failed` | Specifies such a state that the operation on the database failed. | +| `UpdatePetSetResources` | Specifies such a state that the PetSet resources has been updated | +| `UpdatePetSet` | Specifies such a state that the PetSet has been updated | +| `IssueCertificatesSucceeded` | Specifies such a state that the tls certificate issuing is successful | +| `UpdateDatabase` | Specifies such a state that the CR of PgBouncer is updated | + +- The `status` field is a string, with possible values `True`, `False`, and `Unknown`. + - `status` will be `True` if the current transition succeeded. + - `status` will be `False` if the current transition failed. + - `status` will be `Unknown` if the current transition was denied. +- The `message` field is a human-readable message indicating details about the condition. +- The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition. +- The `lastTransitionTime` field provides a timestamp for when the operation last transitioned from one state to another. +- The `observedGeneration` shows the most recent condition transition generation observed by the controller. diff --git a/docs/guides/pgbouncer/sync-users/_index.md b/docs/guides/pgbouncer/sync-users/_index.md new file mode 100755 index 0000000000..43e4e2a7a8 --- /dev/null +++ b/docs/guides/pgbouncer/sync-users/_index.md @@ -0,0 +1,10 @@ +--- +title: Runtime users sync to PgBouncer +menu: + docs_{{ .version }}: + identifier: pb-sync-users + name: Sync Users + parent: pb-pgbouncer-guides + weight: 30 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/pgbouncer/sync-users/sync-users-pgbouncer.md b/docs/guides/pgbouncer/sync-users/sync-users-pgbouncer.md new file mode 100644 index 0000000000..641fadfc0e --- /dev/null +++ b/docs/guides/pgbouncer/sync-users/sync-users-pgbouncer.md @@ -0,0 +1,195 @@ +--- +title: Runtime users sync to PgBouncer +menu: + docs_{{ .version }}: + identifier: pb-sync-users-pgbouncer + name: Sync users pgbouncer + parent: pb-sync-users + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Using Sync Users + +KubeDB supports providing a way to add/update users to PgBouncer in runtime simply by creating secret with defined keys and labels. This tutorial will show you how to use KubeDB to sync a user to PgBouncer on runtime. + +## Before You Begin + +- At first, you need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. Run the following command to prepare your cluster for this tutorial: + + ```bash + $ kubectl create ns demo + namespace/demo created + ``` + +> Note: The yaml files used in this tutorial are stored in [docs/examples/pgbouncer](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/pgbouncer) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Overview + +KubeDB operator allows us to sync additional Postgres users to PgBouncer on runtime by setting `spec.syncUsers` to `true`, if this option is true KubeDB operator searches for secrets in the namespace of the Postgres mentioned with some certain labels. Then if the secret have username and password as key KubeDB operator will sync the username and password to PgBouncer. Again not only to add a user but also this feature can also be used for updating a user's password. + +At first, we need to create a secret that contains a `user` key and a `password` key which contains the `username` and `password` respectively. Also, we need to add two labels `` and `postgreses.kubedb.com`. The namespace must be ``. Below given a sample structure of the secret. + +Example: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + labels: + app.kubernetes.io/instance: ha-postgres + app.kubernetes.io/name: postgreses.kubedb.com + name: pg-user + namespace: demo +stringData: + password: "12345" + username: "alice" +``` +- `app.kubernetes.io/instance` should be same as`appbinding name mentioned in .spec.postgresRef.name`. +- `app.kubernetes.io/name` should be `postgreses.kubedb.com`. +- `namespace` should be same as `namespace mentioned in .spec.postgresRef.namespace`. + +In every `20 seconds` KubeDB operator will sync all the users to PgBouncer. + +Secrets provided by users are not managed by KubeDB, and therefore, won't be modified or garbage collected by the KubeDB operator (version 0.13.0 and higher). + +### Prepare Postgres +For a PgBouncer surely we will need a Postgres server so, prepare a KubeDB Postgres cluster using this [tutorial](/docs/guides/postgres/clustering/streaming_replication.md), or you can use any externally managed postgres but in that case you need to create an [appbinding](/docs/guides/pgbouncer/concepts/appbinding.md) yourself. In this tutorial we will use 3 node Postgres cluster named `ha-postgres`. + +### Prepare PgBouncer + +Now, we are going to deploy a `PgBouncer` with version `1.23.1`. + +### Deploy PgBouncer + +Below is the YAML of the `PgBouncer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1 +kind: PgBouncer +metadata: + name: pgbouncer-sync + namespace: demo +spec: + version: "1.23.1" + replicas: 1 + database: + syncUsers: true + databaseName: "postgres" + databaseRef: + name: "ha-postgres" + namespace: demo + deletionPolicy: WipeOut +``` + +Let's create the `PgBouncer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/pgbouncer/sync-users/pgbouncer-sync.yaml +pgbouncer.kubedb.com/pgbouncer-sync created +``` + +Now, wait until `pgbouncer-sync` has status `Ready`. i.e, + +```bash +$ kubectl get pb -n demo +NAME TYPE VERSION STATUS AGE +pgbouncer-sync kubedb.com/v1 4.5.0 Ready 41s +``` + +### Sync Users + +Now, create a secret with structure defined [here](/docs/guides/pgbouncer/concepts/pgbouncer.md#specsyncusers). Below is the YAML of the `secret` that we are going to create, + +```yaml +apiVersion: v1 +kind: Secret +metadata: + labels: + app.kubernetes.io/instance: ha-postgres + app.kubernetes.io/name: postgreses.kubedb.com + name: sync-secret + namespace: demo +stringData: + password: "12345" + username: "john" +``` + +Now, create the secret by applying the yaml above. + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/pgbouncer/sync-users/secret.yaml +secret/sync-secret created +``` + +Now, after `20 seconds` you can exec into the pgbouncer pod and find if the new user is there, + +```bash +$ kubectl exec -it -n demo pgbouncer-sync-0 -- /bin/sh +/$ cat /var/run/pgbouncer/secret/userlist +"postgres" "md5AESOmAkfj+zX8zXLm92d6Vup6a5yASiiGScoHNDTIgBwH8=" +"john" "md5AEScbLKDSMb+KVrILhh7XEmyQ==" +"pgbouncer" "md5AESOmAkfj+zX8zXLm92d6Vup6a5yASiiGScoHNDTIgBwH8=" +/$ exit +exit +``` +We can see that the user is there in PgBouncer. So, now let's create this user and try to use this user through PgBouncer. +Now, you can connect to this pgbouncer through [psql](https://www.postgresql.org/docs/current/app-psql.html). Before that we need to port-forward to the primary service of pgbouncer. + +```bash +$ kubectl port-forward svc/pgbouncer-sync -n demo 9999:5432 +Forwarding from 127.0.0.1:9999 -> 5432 +Forwarding from [::1]:9999 -> 5432 +``` +We will use the root Postgres user to create the user, so let's get the password for the root user, so that we can use it. +```bash +$ kubectl get secrets -n demo ha-postgres-auth -o jsonpath='{.data.\password}' | base64 -d +qEeuU6cu5aH!O9CI⏎ +``` +We can use this password now, +```bash +$ export PGPASSWORD='qEeuU6cu5aH!O9CI' +$ psql --host=localhost --port=9999 --username=postgres postgres +psql (16.3 (Ubuntu 16.3-1.pgdg22.04+1), server 16.1) +Type "help" for help. + +postgres=# CREATE USER john WITH PASSWORD '12345'; +CREATE ROLE +postgres=# exit +``` +Now, let's use this john user. +```bash +$ export PGPASSWORD='12345' +$ psql --host=localhost --port=9999 --username=john postgres +psql (16.3 (Ubuntu 16.3-1.pgdg22.04+1), server 16.1) +Type "help" for help. + +postgres=> exit +``` +So, we can successfully verify that the user is registered in PgBouncer and also we can use it. + +## Cleaning up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete -n demo pb/pgbouncer-sync +kubectl delete -n demo secret/sync-secret +kubectl delete pg -n demo ha-postgres +kubectl delete ns demo +``` + +## Next Steps + +- Monitor your PgBouncer database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/pgbouncer/monitoring/using-prometheus-operator.md). +- Monitor your PgBouncer database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/pgbouncer/monitoring/using-builtin-prometheus.md). +- Detail concepts of [PgBouncer object](/docs/guides/pgbouncer/concepts/pgbouncer.md). +- Detail concepts of [PgBouncerVersion object](/docs/guides/pgbouncer/concepts/catalog.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md).