Server Discovery

Crunchy Postgres for Kubernetes (CPK) is capable of discovering PostgresClusters so that any user who can sign in to that pgAdmin deployment can any discovered PostgresCluster. How does that work?

In this guide we will walk through two ways that dynamic discovery can discover clusters. These two discovery types can be used to support different deployment methods, notably one PGAdmin to one PostgresCluster and one PGAdmin to many PostgresClusters.

Discovery Types

CPK will use selectors that you provide through the serverGroups field to dynamically discover PostgresClusters. The field provides two ways that you can select PostgresClusters, by name and by labels.

The serverGroups field is a list type meaning you can configure a combination of discovery types, allowing for more flexibility. Take the following serverGroup example:

serverGroups:
- name: selector-discovery
    postgresClusterSelector:
      matchLabels:
        environment: production
- name: name-discovery
    postgresClusterName: cluster-name
Copy

If you were to create a PGAdmin with this serverGroup definition, your pgAdmin deployment would discover the PostgresCluster named cluster-name and any PostgresCluster that has the environment label set to production.

If the serverGroups field is omitted or if the specified selectors do not match any PostgresClusters, then no servers will be found. In this case, users will need to manually manage ServerGroups and Servers.

Discovery By PostgresCluster Name

Discovery by name is fairly simple, you set the postgresClusterName field and provide the name of a PostgresCluster. This PostgresCluster should exists in the same Namespace as your PGAdmin. CPK will then add that PostgresCluster to your defined server group. This discovery type is helpful when you want to deploy one PGAdmin per PostgresCluster.

Discovery by selector

Discovery by Selector provides more options and is helpful when you want to deploy one PGAdmin instance that will monitor many PostgresClusters. The postgresClusterSelector field accepts a Kubernetes Label Selector and can be used in a few ways. Let's walk through the following pgadmin example to see how you can use Selectors.

spec:
  serverGroups:
  - name: demand
    postgresClusterSelector:
      matchLabels:
        owner: logistics
  - name: supply
    postgresClusterSelector: {}
  - name: maintenance
    postgresClusterSelector:
      matchExpressions:
      - { key: owner, operator: In, values: [logistics, transportation] }
Copy

Here we have defined three serverGroups, showing three separate ways to select on labels.

1. The demand group has a postgresClusterSelector in the matchLabels form: any PostgresCluster that matches all of the labels here will be registered automatically.

2. The supply group matches an empty postgresClusterSelector. This is a Kubernetes-specific idiom that will match all PostgresClusters in the namespace.

3. The maintenance group uses the matchExpressions format to define what labels to match on.

To be clear, this example is meant to demonstrate several different ways you can define the postgresClusterSelector. If you had a PostgresCluster with the label owner: logistics, you should be able to log in to your pgAdmin instance and see that PostgresCluster in all three ServerGroups.

Discovered Servers

When a PostgresCluster has been discovered, that cluster will be registered in pgAdmin as a shared server.

Because the server is shared, any user who logs into this pgAdmin will be able to see that PostgresCluster, but will be unable to delete or rename it.

So if you want to deploy one pgAdmin to manage all the PostgresClusters in a namespace and share those servers with all the pgAdmin users, you can set your pgadmin deployment to register all those PostgresClusters automatically and skip manually importing them one-by-one!