Deploying SolrCloud with Zookeeper on Azure Kubernetes Service (AKS)

SolrCloud on Azure Kubernetes Service (AKS)

Running SolrCloud on Kubernetes — particularly Azure Kubernetes Service (AKS) — can provide you with a highly scalable, cost-efficient, and cloud-native architecture. 

This guide walks through how I deployed SolrCloud 8.11.2 with Zookeeper on AKS.

Why This Matters for Sitecore Deployments

If you're running Sitecore XP or XM, you know that Solr is a mandatory dependency — powering xDB indexing, content search.

While Sitecore provides a developer-friendly Solr container for local use, it clearly states:

⚠️ The included Solr image is intended only for development and testing.

This means Sitecore does not provide a production-ready Solr setup. If you're deploying Sitecore in production — especially in Kubernetes — you need to create your own scalable, HA SolrCloud cluster.

That’s why this deployment matters:

• You’re building a production-grade SolrCloud setup

• You’re deploying 3 Solr + 3 Zookeeper nodes for high availability and fault tolerance

• You’re preparing a reliable and scalable search backend for Sitecore that meets enterprise requirements

Goals

• Deploy SolrCloud 8.11.2 on AKS (for Sitecore 10.3 and 10.4)

• Use a 3-node Zookeeper ensemble for coordination

• Provide a setup ready for Sitecore production workloads

 Architecture Overview

AKS Cluster

├── Namespace: solr

│   ├── StatefulSet: solr (3 replicas)

│   └── StatefulSet: zookeeper (3 replicas)

│

├── Namespace: ingress-nginx

│   └── Service: ingress-nginx-controller

Step-by-Step Deployment

Folder structure

If you've worked with Sitecore AKS deployments, this folder structure may look familiar. I started with Sitecore Container Deployment Package and kept only the relevant files.

Here's a breakdown of the directory layout:

solr/

Contains all core workloads related to SolrCloud:

• solr.yaml: StatefulSet + Service for Solr pods

• zookeeper.yaml: StatefulSet + headless Service for the Zookeeper ensemble

• solr-external.yaml: Optional service for external communication

• kustomization.yaml: Registers the above resources for patching or reuse

ingress-nginx/

Handles all ingress traffic into the cluster:

• ingress.yaml: The Ingress resource routing /solr to the solr external service

• configuration.yaml: Ingress controller settings (e.g., proxy buffer size, rewrite-target)

• kustomization.yaml: Combines them for deployment via kubectl apply -k

secrets/

Stores sensitive data (either generated or pre-mounted via Kustomize patches):

• tls/global-solr/tls.crt & tls.key: TLS certs for your domain (solr.globalhost)

• sitecore-solr-connection-string.txt: Connection string used by Sitecore apps

• sitecore-solr-core-prefix-name.txt: Optional core naming conventions for Sitecore roles

• kustomization.yaml: To wrap them as Secret resources or patches

⚠️ Tip: For production, consider using Azure Key Vault to securely store TLS keys and connection strings instead of committing them as Kubernetes Secrets. (Not used in this demo.) 

configmaps/

Used for passing non-sensitive configuration values:

• solr-hostname: Used in init jobs or env variables (e.g., solr.globalhost)

• kustomization.yaml: Generates ConfigMap from file(s)

init/

Contains initialization logic that runs once per cluster or after deploys:

• solr-init.yaml: Kubernetes Job  that sets up Sitecore Solr collections/cores (sitecore_master_index, etc.)

• kustomization.yaml: So you can deploy or re-run init logic when needed

You can find all the files in GitHub page.

I used k8s-init.ps1 to generate TLS certificates and added a host entry for Solr: $SolrHost = "solr.globalhost"

When your files are ready, you can deploy them to your cluster.

This setup gives you a production-ready SolrCloud cluster on AKS with Sitecore compatibility, HA, TLS, and a clean deployment structure using Kustomize. Whether you're scaling out Sitecore or just building a more resilient search backend, this foundation is ready for real-world workloads.

Good luck!