Kubernetes Mastery: Efficient Scaling of Node.js and MongoDB with Helm

Learn how to efficiently scale your Node.js application with MongoDB on Kubernetes using Helm. Our comprehensive guide provides practical steps for setting up and managing your application in a clustered environment. Optimize your development and deployment processes for maximum efficiency and reliability.

Kubernetes is a system for running modern, containerized applications at scale. Developers can deploy and manage applications across clusters of machines. It not only improves efficiency and reliability in single-instance environments but is also designed to run multiple instances of an application across groups of machines.

Many developers choose Helm as a package manager when creating multi-service deployments with Kubernetes. Helm simplifies the process of creating multiple Kubernetes resources by offering charts and templates that coordinate how these objects interact. It also provides pre-built charts for popular open-source projects.

In this tutorial, we will deploy a Node.js application with a MongoDB database on a Kubernetes cluster using Helm charts. We will use the official Helm MongoDB Replica Set Chart to create a StatefulSet object that consists of three pods, a headless service, and three PersistentVolumeClaims. Additionally, we will create a chart to deploy a multi-replica Node.js application using a custom application image. The setup created in this tutorial will mirror the functionality described in “Containerizing a Node.js Application with Docker Compose” and will provide a solid starting point for building a robust Node.js application with a MongoDB datastore that can scale as needed.

Prerequisites

To complete this tutorial, you will need:

• A Kubernetes cluster 1.10+ with Role-Based Access Control (RBAC) enabled. This tutorial uses a centron Kubernetes cluster, but you can create a cluster in other ways.
• The kubectl command-line tool installed and configured on your local machine or development server to connect to your cluster.
• Helm installed on your local machine or development server, and Tiller installed on your cluster.
• Docker installed on your local machine or development server.
• A Docker Hub account.

Step 1: Cloning and Packaging the Application

To use our application with Kubernetes, we need to package it so the kubelet agent can pull the image. However, before packaging the application, we need to modify the MongoDB connection URI in the application code to ensure our app can connect to the members of the replica set that we will create with the Helm MongoDB Replica Set Chart.

Our first step is to clone the node-mongo-docker-dev repository from the centron Community GitHub account. This repository contains the code from the setup described in “Containerizing a Node.js Application for Development With Docker Compose.” It uses a demo Node.js application with a MongoDB database to demonstrate how to set up a development environment with Docker Compose.

Clone the repository into a directory named node_project:

git clone https://github.com/do-community/node-mongo-docker-dev.git node_project

Navigate to the node_project directory:

cd node_project

The node_project directory contains files and directories for a shark information application that works with user inputs. It has been modernized to work with containers: sensitive and specific configuration information has been removed from the application code and restructured to be injected at runtime, and the application’s state has been offloaded to a MongoDB database.

Step 2: Creating Secrets for the MongoDB Replica Set

The stable/mongodb-replicaset chart provides various options for using secrets, and we will create two of them to use with our chart deployment:

• A secret for our replica key file, which acts as a shared password between the members of the replica set, allowing them to authenticate one another.
• A secret for our MongoDB admin user, which will be created as the root user in the admin database.

With these secrets, we can set our preferred parameter values in a dedicated values file and create the StatefulSet object and the MongoDB replica set using the Helm chart.

Step 3: Configuring the MongoDB Helm Chart and Creating a Deployment

Helm comes with an actively maintained repository called stable that contains the chart we will use: mongodb-replicaset. To use this chart with the secrets we just created, we will create a file of configuration parameter values named mongodb-values.yaml, and then install the chart using this file.

Our mongodb-values.yaml file will largely follow the default values.yaml file in the mongodb-replicaset chart repository. However, we will make the following changes to our file:

• Set the auth parameter to true to ensure that our database instances start with authorization enabled. This means that all clients must authenticate to use database resources and operations.
• Add information about the secrets we created in the previous step, so the chart can use these values to create the replica key file and the admin user.
• Reduce the size of the PersistentVolumes assigned to each pod in the StatefulSet to use the minimum usable centron block storage unit of 1 GB, though you can adjust this according to your storage needs.

Before writing the mongodb-values.yaml file, ensure that you have created and configured a StorageClass to provision storage resources.

Step 4: Creating a Custom Helm Chart

deploy our Node.js application on a Kubernetes cluster, we will begin by creating a custom Helm chart. We execute the following command:

helm create nodeapp

This will create a new directory named nodeapp in the ~/node_project directory. Inside this directory, you’ll find basic files for our chart, including Chart.yaml, values.yaml, and the templates/ directory for Kubernetes manifests.

Step 5: Configuring Parameters

Next, we edit the values.yaml file to set parameters such as the number of replicas, the image for our application, and the service type. We open the file with a text editor:

nano nodeapp/values.yaml

In this file, we will set values like the number of replicas, the Docker image to be used, and the service type (e.g., LoadBalancer). We also define environment variables for accessing the database.

Step 6: Creating ConfigMaps and Secrets

We create files for ConfigMaps and Secrets to securely store and use configuration data in our application. To do this, we open secret.yaml and configmap.yaml files in the templates/ directory and add the appropriate data.

Step 7: Integrating Environment Variables

In the next step, we modify the application’s deployment template to use the environment variables from the ConfigMaps and Secrets we created. We open the deployment.yaml file in the templates/ directory and add the relevant environment variables.

Step 8: Deploying the Application with Helm

Finally, we deploy our application using Helm and monitor the deployment process. We use the following command to install our Helm chart and deploy the application to the Kubernetes cluster:

helm install –name nodejs ./nodeapp

After successful deployment, we can check the status of the pods and services to ensure the application is running correctly and accessible.

Conclusion

With Helm, we successfully deployed a replicated Node.js application on a Kubernetes cluster. This process offers a scalable and flexible way to run applications in a Kubernetes environment. By utilizing custom Helm charts, we can efficiently manage and scale the configuration and deployment of our application.