Advanced Kubernetes Namespace Management with the PostgreSQL Operator

Crunchy PostgreSQL for Kubernetes provides enterprises with an open source, cloud-agnostic platform for building Database as a Service in their environments by leveraging the Crunchy PostgreSQL Operator. In order to support the range of enterprise use cases, Crunchy Data continues to develop enhanced features aimed at ensuring the scalability and security of Crunchy PostgreSQL Operator deployments.

Large enterprise Database as a Service users often require the ability to support PostgreSQL users across a variety of an organization’s teams and users, who may have different requirements. Supporting different types of Kubernetes namespace deployments lets enterprises better model their business structures onto Kubernetes and better allocate PostgreSQL resources to specific users or groups of users within their organizations.

In order to support advanced organizational user architectures, the Crunchy PostgreSQL Operator 4.0 release incorporates enhancements to provide further integration of the PostgreSQL Operator with Kubernetes Namespaces. Further, the latest PostgreSQL Operator 4.1 release provides significantly more control over namespace management, allowing users to dynamically create and remove namespaces. When combined with Crunchy PostgreSQL Operator-provided, Role-Based Access Control (RBAC), the Crunchy PostgreSQL Operator provides enterprises with the ability to tailor the best match to their PostgreSQL as a Service offering with their enterprise requirements.

This post provides an introduction to how the Crunchy PostgreSQL Operator interacts with Kubernetes Namespaces, and guidance on the different configurations available to PostgreSQL Operator users and how they can support enterprise Database as a Service requirements.

Background on Kubernetes Namespaces and the PostgreSQL Operator

In Kubernetes, namespaces provide the user the ability to divide cluster resources between multiple users (via a resource quota). Namespaces are intended for use in Kubernetes environments with many users spread across multiple teams or projects. In particular, namespaces become increasingly important as the number of Kubernetes workloads in a particular environment grows. This is because they provide a convenient mechanism for organizing workloads and providing finer-grained security access to them. However, namespaces also provide advantages for smaller workloads as well based upon the security requirements for your applications.

The PostgreSQL Operator makes use of the Kubernetes Namespace support in order to define the Namespace to which the PostgreSQL Operator will deploy PostgreSQL clusters. This provides easier system administration and enables enterprises to more easily allocate Kubernetes resources to specific areas within their business (users, projects, departments). With the version 4.0 release, the PostgreSQL Operator lets enterprises deploy a single PostgreSQL Operator on their Kubernetes clusters and watch any number of enterprise-defined namespaces. The PostgreSQL Operator 4.1 release adds additional capabilities for users to dynamically manage namespaces for their PostgreSQL workloads.

Namespaces Applied to Organizational Requirements

Prior to version PostgreSQL Operator 4.0, the operator could only be deployed with a Namespace deployment pattern where both the PostgreSQL Operator and the PostgreSQL Clusters it deployed existed within a single Kubernetes namespace. This allows the PostgreSQL Operator to support a variety of Namespace deployment patterns, including:

• Development: The Operator and PostgreSQL clusters deployed to the same Kubernetes Namespace.
• Single Tenant: The Operator and PostgreSQL clusters each exist in their own namespace.
• Multitenant: The Operator manages multiple namespaces that can contain multiple PostgreSQL clusters, and a user assigned to a namespace does not have visibility into the PostgreSQL clusters in other namespaces.
• One-Cluster-Per-Namespace: The Operator creates a namespace for each PostgreSQL cluster it manages, allowing every workload to be isolated to a particular namespace.

The PostgreSQL Operator’s namespace support lets you better map your business models onto your Kubernetes infrastructure. For example, you can define namespaces along with individual users (e.g Bob, Paul), departments (e.g. engineering, quality assurance, research), or life-cycle boundaries (e.g. dev, test, QA). The Operator can then be deployed with a unique configuration to uniquely service each group.

Kubernetes Namespaces and the PostgreSQL Operator

The PostgreSQL Operator is both aware of which Kubernetes namespace it is running within and can be configured to service different Kubernetes namespaces. Both the configurations take place at startup time through modifications to the environment variables within the PostgreSQL Operator’s Deployment definition.

The PostgreSQL Operator’s environment variables are configured at startup time through modification of YAML in the PostgreSQL Operator’s configuration file. The following refers specifically to the environment variables related to the Namespace configuration. For full installation instructions using both an automated Ansible playbook and Bash installation, please see the PostgreSQL Operator documentation.

The Operator installers also allow you to add a new watched namespace into your Operator configuration after the initial installation. In future versions of the Operator, adding new watched namespaces will be automated and more dynamic.

Configuration of the Namespace to which PostgreSQL Operator is Deployed

In order to configure the Kubernetes namespace which the PostgreSQL Operator will run within, it is necessary to configure the PGO_OPERATOR_NAMESPACE environment variable. Both the Ansible and Bash installation methods enable you to modify this PGO_OPERATOR_NAMESPACE environment variable in connection with the Operator installation.

The Operator namespace can be named anything you would like, in this blog we have used pgo as the Operator namespace.

Configuration of the Namespaces to which PostgreSQL Operator Will Deploy PostgreSQL Clusters

The Operator at startup time determines which namespaces it will service based on what it finds in the NAMESPACE environment variable that is passed into the Operator when it starts up. The NAMESPACE variable can hold different values that determine the namespaces which will be watched by the PostgreSQL Operator. This variable is specified and set as part of the Operator installation process. The format of the NAMESPACE value in the PostgreSQL Operator is modeled after the Operator Lifecycle Manager project.

Watched namespaces can be named anything you want, in this blog, we have used the names pgouser1 and pgouser2 as sample namespace names. How a namespace is named and how many namespaces are used is up to the user to determine, these watched namespaces could represent users, groups or departments within an enterprise.

Development Example

The development deployment pattern provides for both the PostgreSQL Operator, and the PostgreSQL Clusters that the PostgreSQL Operator Deploys, to be deployed within a single Kubernetes Namespace.

The advantage of this deployment pattern is simplicity. This deployment pattern is likely most useful for:

• Single developer PostgreSQL Operator installations.
• Use cases where you have only a single purpose in mind for your Kubernetes environment.
• When you have a very limited set of PostgreSQL databases to deploy and manage.

The drawback of this deployment pattern is that it requires users who require PostgreSQL clusters within multiple Kubernetes Namespaces to perform multiple PostgreSQL Operator installs and administer multiple PostgreSQL Operators within a single Kubernetes cluster.

Single-Tenant Example

The single-tenant deployment pattern provides for the PostgreSQL Operator to be deployed within an indicated Kubernetes Namespace (ex: pgo), but the managed PostgreSQL Clusters to be deployed to a single different Kubernetes Namespace (ex: pgouser1).

The advantage of this deployment pattern is that it provides additional flexibility in that it allows a user to specify PostgreSQL Operator RBAC controls more specifically within each Kubernetes Namespace, with the watched namespace (in this case, pgouser1) having less RBAC permissions that the namespace that holds the Operator itself (in this case, pgo). The additional granularity of RBAC permission control provided by this deployment pattern provides users with additional security isolation apart from the Kubernetes Namespace where the PostgreSQL Clusters are deployed.

With this type of Operator deployment, you can also support multitenant Kubernetes scenarios in that you can run many different PostgreSQL Operators on a single Kubernetes cluster, with each Operator having a unique configuration.

In order to deploy the PostgreSQL Operator with the single-tenant deployment pattern, it is necessary to configure the PostgreSQL Operator environment variables as follows (pgo and pgouser1 are example identifiers).

export PGO_OPERATOR_NAMESPACE=pgo

export NAMESPACE=pgouser1

Multitenant Example

The multitenant deployment pattern provides for the PostgreSQL Operator to be deployed to its own Kubernetes Namespace (ex: pgo), but the managed PostgreSQL Clusters to be deployed to multiple different Kubernetes Namespace (ex: pgouser1; pgouser2).

The advantage of this deployment pattern is that it provides even greater flexibility than the single-tenant pattern. This allows enterprises additional flexibility in how they model their Kubernetes environments to their business models. For example, watched namespaces can be created to be users, groups, or departments within their company. A single Operator can then process all of the namespaces in a consistent manner with a single configuration.

To have the Operator deployed into its own namespace but create Postgres Clusters into more than one namespace the variables would be as follows:

export PGO_OPERATOR_NAMESPACE=pgo

export NAMESPACE=pgouser1,pgouser2

Starting with version 4.1, you can dynamically add more namespaces under management of the PostgreSQL Operator:

pgo create namespace pgouser3

One-Cluster-Per-Namespace Example

The “one-cluster-per-namespace” deployment pattern provides for the PostgreSQL Operator to be deployed to its own Kubernetes Namespace (ex: pgo), and for the managed PostgreSQL Clusters to be deployed to any Kubernetes Namespace (ex: cluster1; cluster2… clusterN).

To have the Operator deployed into its own namespace but create Postgres Clusters into any target namespace the variables would be as follows:

export PGO_OPERATOR_NAMESPACE=pgo

export NAMESPACE=

Here the empty string value represents all namespaces.  It is still a requirement by the Operator for you to have the correct RBAC controls in place for each namespace you want to deploy PostgreSQL clusters into. Within the Operator project, a script is provided that installs the Operator-specific RBAC controls into any one of the targeted namespaces.

To successfully deploy this pattern, you can use the following commands:

pgo create namespace cluster1

pgo create cluster –n cluster1 cluster1

PostgreSQL Operator RBAC

To provide additional granularity of access controls on PostgreSQL Operator deployments, the PostgreSQL Operator provides native RBAC. This PostgreSQL Operator native RBAC enables a PostgreSQL Operator admin to allow for configuration of the operator permissions required to create Jobs, access Namespaces, create Deployments and other Kubernetes resources.

In connection with support for the new namespace pattern, the PostgreSQL Operator also adds support for the application and configuration of distinct RBAC permissions against each namespace to be watched and requires a specific PostgreSQL Operator. When you perform an Operator installation, the installation process causes the PostgreSQL Operator to iterate through the list of namespaces to be watched, creating the required RBAC resources into each of those namespaces.

The example deployment creates the following RBAC structure on your Kubernetes system after running the install scripts:

pgo Clients and Namespaces

Starting in PostgreSQL Operator 4.0, the PostgreSQL Operator common line interface (pgo CLI) is now required to identify which namespace it wants to use when issuing commands to the PostgreSQL Operator.

Users of pgo CLI can either create a PGO_NAMESPACE environment variable to set the namespace in a persistent manner or they can specify it on the pgo command line using the –namespace flag. If a pgo CLI request does not contain a valid namespace the request will be rejected.

pgo CLI users now are configured for access to certain namespaces to prevent or provide access to PostgreSQL clusters within certain namespaces. pgo CLI users can view what namespaces they have access to by using a new pgo command:

$ pgo show namespace

namespace: pgouser1 (accessible)

namespace: pgouser2 (accessible)

Conclusion

Supporting different types of Kubernetes namespace deployments lets enterprises better model their business structure onto Kubernetes and better allocate Postgres resources to specific people or groups within their organizations.

Starting with PostgreSQL Operator 4.0, enterprises have the ability to deploy a single PostgreSQL Operator on their Kubernetes clusters and watch any number of enterprise-defined namespaces. This provides easier system administration and enables enterprises to more easily allocate Kubernetes resources to specific areas within their business (users, projects, departments).

Please give the PostgreSQL Operator a try and let us know what you think. Easy instructions on getting started are available here. Crunchy Data welcomes GitHub issues, collaboration and pull requests for the PostgreSQL Operator project.

Feature image via Pixabay.