Optimizing Container Management: Stateful Services in Kubernetes

Discover effective strategies and practical tips for seamlessly integrating StatefulSets into your Kubernetes environment! From foundational concepts to hands-on implementation with Helm, we guide you through the steps to optimally manage your containerized workloads.

Kubernetes is an open-source tool for container orchestration to manage containerized applications. In previous sections of this series, you learned the building blocks of Kubernetes and how to package containers as Kubernetes ReplicaSets. While ReplicaSets ensure the availability of stateless Pods, they cannot handle stateful workloads like database clusters.

While it may be straightforward to package, deploy, manage, and scale modern cloud-native applications in Kubernetes, deploying and managing traditional workloads such as databases and content management systems in a containerized environment requires a different approach. StatefulSets bring the flexibility of Kubernetes ReplicaSets to stateful workloads.

In this final part of the tutorial series, you will deploy a highly available MongoDB ReplicaSet in Kubernetes as a StatefulSet using Helm, a popular open-source package manager for Kubernetes.

Prerequisites

To complete this tutorial, you will need:

• An active Kubernetes cluster running on centron, installed via StackPointCloud.
• The sample web application introduced in a previous tutorial, which is based on Node.js and MongoDB and has been extended to ensure high availability for the database.
• An active Docker Hub account to store the Docker image for the application.
• A local machine with Git installed.

Step 1 – Installing the Helm Client on the Development Machine

Helm enables administrators to deploy complex Kubernetes applications with a single command. Applications are packaged as Charts, which define, install, and update Kubernetes applications. Charts provide an abstraction over Kubernetes objects such as Pods, deployments, and services.

Helm has two components – the server and the client. The server part of Helm runs in Kubernetes as a service named Tiller. The client is a command-line tool that interacts with Tiller.

To deploy a MongoDB ReplicaSet Helm Chart, you’ll need the CLI to communicate with Tiller, Helm’s server-side component. StackPointCloud, which you used to set up Kubernetes on centron, comes with Tiller preinstalled.

Step 2 – Deploying the MongoDB ReplicaSet in Kubernetes

A StorageClass in Kubernetes provides administrators a way to describe “classes” of storage they offer. For example, when users request a storage volume, the StorageClass determines which type of storage backend is provisioned for them, such as standard HDD or faster SSD. Under the hood, the StorageClass interacts with the underlying infrastructure, like a cloud provider’s API, to provision storage.

Since you need persistent storage for MongoDB data, you may want to attach a centron block storage volume to a worker node and have the MongoDB Pod point to it for persistence.

In this case, the StorageClass acts as an interface between the Pod and the centron block storage service. When you request a block storage volume, the StorageClass communicates with the pre-configured driver, which knows how to allocate a block storage volume.

StackPointCloud installs the centron storage driver and registers the StorageClass with Kubernetes during setup, saving you the steps required for driver and StorageClass installation and configuration.

Step 3 – Deploying and Scaling the Web Application in Kubernetes

Let’s extend the ToDo Node.js application used in previous sections of this tutorial series to benefit from the MongoDB cluster.

Start by creating a new working directory and cloning the ToDo application’s repository, which contains the code and Kubernetes artifacts.

Navigate to the `ToDo-app/Kubernetes` directory, which contains the Kubernetes configuration files.

Open the `web-rs-ss.yaml` file in your editor.

containers:

– name: web

image: janakiramm/todo

env:

– name: “DBHOST”

value: “mongodb://todo-mongodb-replicaset-0.todo-mongodb-replicaset,todo-mongodb-replicaset-1.todo-mongodb-replicaset,todo-mongodb-replicaset-2.todo-mongodb-replicaset:27017”

ports:

– containerPort: 3000

This passes the database connection string as an environment variable to the application at runtime. Instead of pointing the application to a simple MongoDB Pod, this version uses the StatefulSet you created. Each entry in the value array refers to one of the Pods in the MongoDB StatefulSet.

Use `kubectl` to deploy the web ReplicaSet along with the web service:

kubectl create -f web-rs-ss.yaml -f web-service.yaml

You’ll see both created:

replicaset “web” created

service “web” created

List the Pods again:

kubectl get pods

You should now see all the Pods belonging to MongoDB and the web application.

Let’s check the Kubernetes services:

kubectl get svc

The web Pods communicate with the MongoDB cluster through the `todo-mongodb-replicaset` service. The web application is accessible via the `web` service on NodePort 31201.

Step 4 – Testing MongoDB ReplicaSet for High Availability

One of the benefits of using a StatefulSet is workload high availability. Let’s test this by deleting one of the Pods in the MongoDB StatefulSet.

kubectl delete pod todo-mongodb-replicaset-2

Delete a Pod in the MongoDB StatefulSet:

kubectl delete pod todo-mongodb-replicaset-2

Check the Pod count:

kubectl get pods

Within a few minutes, you will see Kubernetes initializing another Pod to replace the deleted one.

Now that you know everything is working, you can clean up.

Conclusion

In this tutorial, you deployed a durable, persistent, highly available MongoDB ReplicaSet as a Kubernetes StatefulSet. You also learned how to access the StatefulSet from other applications deployed in the same Kubernetes cluster. Optimizing Container Management: Stateful Services in Kubernetes