VMware SQL with Postgres for Kubernetes 2.0 - What's New

January 09, 2023

VMware SQL with Postgres for Kubernetes (VMware Postgres for K8s) is a relational database-as-a-service that automates the installation, management, monitoring, and updating of containerized Postgres instances running on-premises or in any cloud. The engineering team for VMware Postgres for K8s ended 2022 by reaching a major milestone in the release of version 2.0. Here is a summary of key new features:

  • Multiple Read Replicas to improve query performance
  • Customization of Configuration File for specific use cases
  • Postgres 15.x Support to take advantage of the latest database functionality
  • FIPS support for improved security and compliance

Let's unwrap some of the gifts that were delivered in this latest release.

Multiple Read Replicas

VMware Postgres for K8s has supported High Availability (HA) for VMware Postgres Operator since the initial 1.0 product release. HA offers automatic failover to ensure continuous operations without downtime. The VMware Postgres Operator uses the pg_auto_failover extension to provide a highly available Postgres cluster on K8s. The following diagram shows the topology of the HA cluster configuration, which consists of three pods: one monitor pod, one primary, and one hot-standby mirror.

image 378

Over time, database performance may deteriorate due to increased load placed on the primary instance. This performance degradation is often a byproduct of increasing read-heavy workloads, like business reporting, that place too much load on a single instance. While HA is used to ensure system availability, it does not increase performance. In this scenario, read replicas are often implemented.

In the latest release of VMware Postgres for K8s, the number of read replicas is now configurable. Users can scale up or down the number of mirrors, or read replicas, in an HA configuration. This feature adds a new field spec.highAvailability.readReplicas for controlling the number of read replicas. For more details see the Postgres CRD API Reference. The diagram below shows the topology of the HA cluster configuration with multiple read replicas enabled:

image 379

Implementing read replicas helps to offload traffic from the primary database, therefore bolstering the overall performance.  It is possible to deploy more than one read replica for a primary database, and there are a number of use cases that would benefit from multiple read replicas. One of the more common use cases is scaling your read performance for a wider range of applications that need to query data without being restricted to a single read replica.

For detailed instructions on implementing read replicas, see the following link to the product documentation.

Customization of Configuration File (postgresql.conf)

In VMware Postgres for K8s, deployed Postgres Instances are configured with predetermined PostgreSQL server parameter settings. While these settings may work for most use cases, the latest release allows users to customize the PostgreSQL server parameters for new or existing Postgres instances. As such, VMware Postgres for K8s version 2.0 introduces a new Postgres Custom Resource Definition field called customConfig.

When preparing to customize Postgres instance parameter settings, please refer to the Customizing the PostgreSQL Server section of the product documentation for a detailed listing of the prerequisites, exceptions, and the step-by-step process. The available parameters that can be modified are determined by the PostgreSQL version that is deployed. Not all parameters can be modified, as outlined here. Please refer to the following link for a detailed parameter list.

The customized parameters are not configured in the default postgresql.conf file. These parameters will be listed in an override file located at /etc/customconfig/postgresql.conf.

The parameter customization process is summarized as follows:

1. In the same namespace as your Postgres instance, edit the ConfigMap with the desired parameter changes for your PostgreSQL server. For details refer to Kubernetes ConfigMaps. Below is an example of a ConfigMap:

image-20230109151300-3

2. Apply the ConfigMap to your Postgres instance:

image-20230109151450-4

3. The result of the above command for a new instance will be the following:

image-20230109151857-5

   The result of the above command for an existing instance will be the following:

image-20230109151919-6

4. For new instance deployments, you will need to edit the YAML file for your Postgres instance, modifying the customConfig field to reflect the name of your ConfigMap:

image-20230109151946-7

   Then deploy the instance with the new customConfig setting as follows:

image-20230109152003-8

   For existing Postgres instances, apply the changes with the following command:

image-20230109152016-9

   The changes will be applied and the pods could be restarted if any of the changed parameters have a Restart value

4. Once the changes have been applied and the Postgres instance has a "Running" status, you can verify the modified parameters by logging into the pods and using the show command as follows:

image-20230109152151-10

Postgres 15.x Support

The initial releases of VMware Postgres for K8s only supported PostgreSQL database version 11. Starting with the 1.4 release through the 1.9 release, support was added for PostgreSQL database versions 12, 13, and 14. The latest release of VMware Postgres for K8s now includes PostgreSQL 15 in the list of supported database versions. In fact, version 2.0 of the VMware Postgres Operator deploys Postgres 15.1 as the default version for managed Postgres instances.

To view the list of supported Postgres versions for your Operator, run the following command:

image-20230109152643-14

The command will display the following output:

image-20230109152733-15

From the above output, you can see that the 2.0 release supports PostgreSQL database versions 11 through 15. To deploy a specific version other than the default, you will need to modify the Postgres instance manifest file using the values listed under the NAME column. An example of the modified portion of the manifest file will look like the following:

image-20230109152816-16

Based on the above example, newly deployed Postgres instances would be PostgreSQL 13.9. It is worth mentioning that existing VMware Postgres instances cannot be upgraded to a new major version. These instances would need to be deleted and recreated with the new major version.

FIPS support

Data is arguably the most critical resource of any organization. The security of sensitive data, such as Personally Identifiable Information (PII) is an essential part of every business. A number of standards, best practices, and regulations have been created to help organizations in their data security efforts. One such standard is the Federal Information Processing Standard, referred to as FIPS.

FIPS is a security standards framework developed by the United States Federal Government that U.S. federal agencies, government contractors, and service providers, are required to comply with in order to work with any federal government entity that collects, stores, and transfers sensitive information. This requirement ensures government data handled by third-party organizations is securely maintained, with the appropriate levels of confidentiality, integrity, and authenticity.

While U.S. Federal Government agencies are required to be FIPS compliant, many organizations have developed information security policies of becoming FIPS compliant, as it makes their organization, its software, and its services seem more secure and trusted.

In VMware Postgres for K8s version 2.0, FIPS is now supported and can be enabled for instances that are version 14 or 15. As stated in the previous section (Postgres 15 Support), VMware Postgres SQL for K8s supports Postgres 11, 12, 13, 14, and 15. However, Postgres 11, 12, and 13 are not FIPS compliant because Postgres provides a built-in md5 function and supports MD5 password encryption instead of delegating to the underlying Openssl library.

In this latest release, Postgres 14 and 15 use OpenSSL with FIPS enabled, and does not support MD5 authentication any longer. Users will need to update any existing Postgres roles that use md5 password authentication to scram-sha-256 authentication. Converting to scram-sha-256 authentication is fairly simple and there are several internet searchable "how-to" articles to walk you through the process.

Conclusion

VMware Postgres for K8s version 2.0 gave us some pretty awesome gifts just in time for the 2022 holiday season. From FIPS support to multiple read replicas, ultimately providing flexible scalability, increased performance, and enhanced security.

Now that you are done unwrapping these gifts, why not try them out?  Use the links below to get started!

Links

 

Filter Tags

Modern Applications Blog Databases Overview