This makes Redis a good choice to produce a platform for solving problems that other databases can't, such as communication between components and languages.Bitnami has released a Helm chart that allows you to deploy Redis simply and reliably in a production environment. The Bitnami Redis chart configures a cluster with four nodes by default, ensuring the data persistence at the primary node.
This chart, compared to other available solutions such as Redis-HA, provides high availability using Kubernetes native mechanisms and it is not necessary to rely on other solutions like Redis-Sentinel. Let's discover how the chart is configured, its deployment options, and how to scale and update your deployment at any time.
How is the Bitnami Redis chart configured?
The Bitnami Redis chart is configured to be deployed on any Kubernetes cluster. It includes two values.yml files:
- values.yml: ideal for testing. Unlike the values-production.yml, this file only defines a single-node cluster.
- values-production.yml: defines production parameters.
Checking the values-production.yml file, you can see how the chart configuration allows you to immediately run a Redis cluster in any production environment. Using the Bitnami Redis Helm chart, you can take advantage of having enabled:
- A four-node cluster: one read/write primary and three read-only replica nodes.
- Readiness and Liveness probes that provide information about the application pod status.
- Persistence to avoid data loss in the primary node.
- Node toleration so you can decide in which node you want to run the Redis pod.
- Annotations and labels to integrate Redis with other third party tools.
- Resource requests and limits: you can adapt the solution to different loads in your cluster. For example, if your cluster has 1024 of RAM, you could force Redis not to consume more than 512 MB, so other applications deployed on the cluster are not affected by unexpected spikes in Redis.
- Application properties: “port”, “arguments”, and “not allowed operations” values are defined by default.
- Data exporters to integrate your cluster with metrics and monitoring tools such as Prometheus and Grafana.
- Network policies that allow remote access from any source.
- Authentication using a randomly generated password (you can also provide a secret if you want to set your own password).
- Pod security context: all the containers in the pod will be executed as non-root containers.
This blog post uses Microsoft Azure Container Service (AKS) as the example cluster management system, but the Bitnami Redis chart can be deployed on any Kubernetes cluster. You can also deploy it on Google Kubernetes Engine (GKE), on Amazon Elastic Container Service (EKS), or by using Minikube to test it locally.
The best way to learn about something is to see it in action. We are going to deploy the cluster and in real-time check how the configuration, set by Bitnami in this Helm chart, makes Bitnami Redis perfect to use in production.
Deploying the Bitnami Redis Helm chart
The following instructions walk you through the process of deploying the Bitnami Redis Helm chart on a Kubernetes cluster running in AKS. To use Microsoft Azure as a cluster management platform, you need to provision a Kubernetes cluster on AKS and install Helm and Tiller to start using it. Learn the basics in our Get started with the Azure Container Service (AKS) guide.
| IMPORTANT: For a basic setup, the default AKS cluster size should be large enough (three nodes standard DS1 v2 with one 1vcpu and 3.5 GB memory). In a production environment, bigger instance sizes (like standard B4ms with 4vcpus and 16 GB memory) are recommended.
To deploy the Bitnami Redis Helm chart:
- Download the Redis chart repository:
$ wget https://raw.githubusercontent.com/kubernetes/charts/master/stable/redis/values-production.yaml
- Install the latest version of the chart:
$ helm install stable/redis --values values-production.yaml
It will deploy a cluster with four nodes (one primary and three replicas) and a total number of five pods, one per node and an additional one for metrics. After running the command above, you will see an output similar to this:
Observe that the "Notes" section, shown at the bottom, contains important instructions about how to obtain your application's IP address or credentials. You can also find essential information to help you connect to Redis nodes by using the
- Check the pods by running the following:
$ kubectl get pods
Bitnami Redis chart default network and security configuration
As seen in the output above, the Bitnami Redis Helm chart generates a randomly generated password that can be used to authenticate you to connect to Redis. If you prefer, you can configure a secret to secure your deployment.
For security reasons, Bitnami has enabled the pod security context, which means that all containers in the pod are executed as non-root containers. That way, if a container engine security issue occurs, running the container as an unprivileged user will prevent the malicious code from scaling permissions on the host node.
Since NetworkPolicy is enabled, Redis will work without any trouble, in any cluster regardless of the network policies defined for that cluster. For example, if you want to deploy the chart on a production cluster where all access is denied by default, Redis will run on it smoothly. In addition, the chart allows a more restrictive access policy, in which only those nodes with a specific tag will be able to access Redis.
The Bitnami Redis chart doesn't require RBAC rules to be deployed. However, it is possible to define a custom set of RBAC rules in values.yaml and values-production.yaml files. In order to do so, a serviceAccount will be created and bound to the Redis deployment. This is extremely useful in case you want to use a custom Redis image that requires RBAC (for example, a non-Bitnami image such as quay.io/smile/redis).
The deployment operates on port 6379 and allows remote connections in this port by default.
Testing Redis cluster data replication and checking node metrics
The Bitnami Redis Helm chart deploys a four-node cluster comprised of one primary and three replicas. The primary node allows write and read operations. It persists the data using a persistent volumes. To learn more about data persistence in Redis, check the official documentation.
Replicas are configured as read-only nodes. All the data received by the primary node is replicated in replicas so they keep a copy of the primary node data. In addition to this, if the primary node fails, Kubernetes mechanisms will respawn the primary node and all the replicas will reconnect to it.
To test the redundancy in the Redis cluster, follow these instructions:
IMPORTANT: RELEASE-NAME is a placeholder. Replace it with the release name displayed when installing the Helm chart in the "NAME" section:
- Run a Redis pod that you can use as a client (In this case, the command shown below was retrieved at the first deployment of the chart.):
$ kubectl run --namespace default RELEASE-NAME-client --rm --tty -i \ --env REDIS_PASSWORD=$REDIS_PASSWORD \--labels="redis-client=true" \ --image docker.io/bitnami/redis:4.0.10-debian-9 -- bash
- Connect to the primary node using the
$ redis-cli -h RELEASE-NAME-master -a $REDIS_PASSWORD
INFO command, you can see a complete report of the node status. In the “Replication" section you can check the role of the node you are connected in (in this case, the primary node), the number of connected replica nodes, or the IP address of each replica:
- Define a new variable and set it to a new value. Then check that this value has been successfully defined by executing the
- Disconnect from the primary node and connect to one of its replicas (You can use the
redis-clicommand displayed when you have installed the chart or use the node IP address you want to connect for SSH connections):
$ redis-cli -h RELEASE-NAME-slave -a $REDIS_PASSWORD
- Execute the
getcommand to check that the value introduced in the primary node has been replicated into all replicas in the cluster:
Scaling Redis deployment
You can scale up and down your deployment at any time only using the
kubectl scale command and specifying the total number of nodes you want to have in your cluster. For example, if you want to add a new node to the current deployment, the total number of replicas will be 5:
$ kubectl scale --replicas 5 deployment <RELEASE-NAME>-slave
You can see in the screenshot that the number of replica nodes has been increased by one:
Upgrading your deployment to the latest version
Helm makes it easy to upgrade applications with the
helm upgrade command. Remember to replace the RELEASE-NAME and NEW VERSION placeholders with the name of your deployment and with the number of the version you want to update your deployment, respectively.
$ helm upgrade <release-name> --set image.tag=<NEW VERSION>
If you are searching for a distributed in-memory cache that is scalable and has a high performance, chances are that you select Redis as the appropriate solution for your application. With all this in mind, the Bitnami Redis Helm chart is an excellent choice to deal with production environments. This chart is ready to deploy on a Kubernetes cluster in any platform.