Synergizing Helm Charts and Kubernetes Operators for Database Deployment

The Kubernetes orchestrator debuted in 2014 to help engineers solve the challenges of deployments and controlled release pipelines. This orchestrator fully automates the entire DevOps pipeline. A DevOps engineer can easily trigger the software lifecycle management pipeline by pushing a commit to a remote version control repository. These engineers can spawn hundreds of containers and pods in a few minutes while Kubernetes handles their lifecycle and deployment order to quickly launch all services. Helm charts and Operators assist in deploying and operating databases on Kubernetes. Helm charts are YAML code that helps define, install, and upgrade applications on Kubernetes clusters. Kubernetes Operators are application-specific controllers that help handle certain tasks by extending the Kubernetes API’s functionality.

This article will highlight the main differences between Kubernetes Operators and Helm charts. You’ll learn when Helm charts are helpful and when Kubernetes Operators may best suit your business needs. Since this article focuses on database deployments, we’ll discuss Kubernetes storage objects and why Kubernetes stateful deployments are challenging. We’ll also highlight a use case combining both technologies for your database deployments.

Kubernetes Operators

A Kubernetes Operator is a pattern of writing Kubernetes extensions. The Kubernetes Operator software automatically performs all actions of a system administrator or DevOps engineer, including checking deployment status and locating any errors. It takes the necessary steps to deploy and redeploy any crashed containers and it can perform advanced actions, such as backing up and restoring applications.

You can use a Kubernetes Operator to configure your deployment’s default settings. Operators are an essential part of your Kubernetes clusters because they extend the existing functionality and automate your Kubernetes use.

Since it automates a DevOps engineer’s actions, the Kubernetes Operator has access to the Kubernetes API and reacts to unwanted cluster changes in real-time.

Helm Charts

Helm is a package manager for Kubernetes applications, and a Helm chart is a single script that manages your package deployment. The package in this context is an application or deployment, like NGINX or Apache Tomcat. If you have ever used package managers on Linux or Windows, such as APT or Chocolatey, you will likely notice similarities to Helm. Helm installs or deploys an application using the information in a Helm chart script.

Helm charts enable simple and accessible application deployment and upgrades. NGINX provides an example of how you can deploy NGINX using Helm charts.

The purpose of Helm charts is to generate and maintain YAML files for various deployment and upgrade options. Software vendors can then configure the software packages with the desired default configuration. This approach helps quickly deploy the packages using charts — YAML files with defined default settings.

To learn more about Helm charts, check out the public repository of Helm charts for databases.

Database Deployments

Kubernetes offers two modes of application deployment: stateless and stateful. As the name suggests, a stateless application does not need to persist state to function. Examples include a traffic manager, a content delivery network (CDN) server, or a streaming service. In these situations, the data is persisted outside of the container.

In contrast, the container aims to persist the data for stateful applications. Examples include database deployments, where the database engine needs to save the created data. If a container crashes, it loses all its information. For such an event, Kubernetes offers several ways to store the data.

A database deployment requires:

• Volumes to persist the data
• Application configurations: Secrets to store connection strings and certificates, if any, and environment variables for database or administration
• YAML (or API) to deploy to Kubernetes

Database deployments are stateful and require a storage object in Kubernetes. This storage object manages persisting data and resource-sharing between containers.

For example, a Kubernetes Operator for PostgreSQL can deploy a database as a Kubernetes object and create additional resources, such as secrets and load balancers. An Operator could then configure the cluster, if necessary. Using an Operator enables you to build a more robust cluster, resilient to any changes from external sources.

A Helm chart is the easiest way to deploy the PostgreSQL cluster on Kubernetes. The main reason to use a Helm chart is that Helm manages the underlying Kubernetes objects for you. You can deploy the Kubernetes instance in the cloud or on-premises and the Helm chart handles the resource allocation for you.

Helm charts provide configuration support for the deployments. This support enables system administrators to use custom configurations to deploy the cluster. It should be noted that while Kubernetes Operators can modify the values on the fly using the Kubernetes API, Helm charts would have to alter the deployments to make changes.

Synergizing Helm Charts and Kubernetes Operators

The sections above highlight the similarities in Kubernetes Operators and Helm charts features. Both approaches offer the ability to deploy, configure, and upgrade an existing cluster on Kubernetes. However, certain operations perform more efficiently on one or the other. Helm charts target the YAML files and cross-architecture Kubernetes application deployments, whereas Kubernetes Operators make it easy to integrate with the Kubernetes API to perform maintenance tasks.

Helm charts enable you to accelerate the deployment of Kubernetes applications. After generating a Helm chart that deploys the application with default settings, you can use a Kubernetes Operator to deploy a database using the Helm chart.

This open-source project encourages deploying Helm charts using Kubernetes Operators and here is an example of a PostgreSQL Helm chart.
You can use a chart to:

• Configure the data storage options, including creating any necessary storage objects in Kubernetes
• Generate and save secrets
• Provision a load balancer to allow traffic

Additionally, you can use Helm to upgrade this cluster. However, modifying the default settings for a chart requires passing them as arguments to the command line while upgrading the release.

Kubernetes Operators can also help upgrade existing database deployments by scheduling a database backup and restore.

Operators provide support for secret management and certificates because all of the required information remains isolated from version control and human reach. The Operator can read the metrics from the Kubernetes API to add more resources or deployments. You can efficiently perform some advanced tasks, such as maintaining database schema, storing secrets in the cluster, and backing up with Kubernetes Operators.

Due to their synergistic relationship, several industry-leading database providers already use Helm and Kubernetes Operators technology to provide their services.

Conclusion

Because Kubernetes Operators and Helm charts have their differences, you can employ both platforms for your database deployments, rather than having to choose between them. Kubernetes Operators can help you provision and manage backups for stateful clusters, whereas Helm can accelerate stateful deployments.

You can use the Kubernetes Operator and Helm chart approaches with Portworx to set up stateful applications on Kubernetes and manage your data. Learn how Portworx storage management solutions for Kubernetes help you save on compute costs, storage costs, and time-to-market.