Edit

Deploy a Valkey cluster on Azure Kubernetes Service (AKS)

This article summarizes the steps to deploy Valkey, an open source (BSD) high-performance key/value datastore, on Azure Kubernetes Service (AKS). The Valkey deployment focuses on leveraging replicas and availability zones for high availability and resilience. We also provide guidance to test the resilience of your Valkey deployment using the Locust load testing framework.

Important

Open-source software is mentioned throughout AKS documentation and samples. Software that you deploy is excluded from AKS service-level agreements, limited warranty, and Azure support. As you use open-source technology alongside AKS, consult the support options available from the respective communities and project maintainers to develop a plan.

Microsoft takes responsibility for building the open-source packages that we deploy on AKS. That responsibility includes having complete ownership of the build, scan, sign, validate, and hotfix process, along with control over the binaries in container images. For more information, see Vulnerability management for AKS and AKS support coverage.

What is Valkey?

Valkey is a fork of the Redis project that preserves its original open-source license. Valkey is a high performance database that supports a key-value datastore, and you can use it for caching, session storage, message queues, and more. A Valkey cluster has multiple nodes that are responsible for hosting your Valkey data stores. Valkey shards data into smaller portions and disperses it among the nodes. In a simplified Valkey cluster consisting of three primary nodes, a single replica node supports each node to enable basic failover capabilities. The data is distributed across the nodes, enabling the cluster to continue functioning even if one of the nodes fails.

Architecture diagram of Valkey deployed on AKS with three primary nodes and one replica for each primary.

For more information, see the Valkey documentation.

Valkey solution overview

This solution deploys three Valkey primary pods across two availability zones with one replica pod per primary in a third zone, running on Standard_E64_v5 SKU nodes. You create two distinct StatefulSet resources with spec.affinity rules that ensure zone distribution for high availability. You create one StatefulSet for the Valkey primary pods and another for the replica pods.

Note

Note that the solution suggested in this article differs from the Valkey documentation, where cluster Pods belong to a single StatefulSet, and the spec.affinity only ensures that the Pods are placed on different nodes. The automatic Valkey cluster initialization presented in the Valkey documentation doesn't ensure that the primary and replica Pods for the same shard are placed in different availability zones.

Next step

Create the infrastructure resources for running a Valkey cluster on AKS

Contributors

Microsoft maintains this article. The following contributors originally wrote it:

  • Nelly Kiboi | Service Engineer
  • Saverio Proto | Principal Customer Experience Engineer
  • Don High | Principal Customer Engineer
  • LaBrina Loving | Principal Service Engineer
  • Ken Kilty | Principal TPM
  • Russell de Pina | Principal TPM
  • Colin Mixon | Product Manager
  • Ketan Chawda | Senior Customer Engineer
  • Naveed Kharadi | Customer Experience Engineer
  • Erin Schaffer | Content Developer 2
  • Last updated on