Sitecore 10 on Azure Kubernetes Service: My Learning Journey, the Installation Process and a Simple Solution to Save Money

At the end of last summer Sitecore 10 has been released with a very detailed installation guide on how to deploy a containerized Sitecore application to the Azure Kubernetes Service (AKS) and with a complete deployment package with Kubernetes specification files. In this blog post I am going to share how I approached my learning journey with Kubernetes and AKS, I will describe an issue that I encountered during the Sitecore installation and its resolution, and finally how you can save your money starting and stopping an existing Sitecore AKS cluster when needed.

My learning journey

I have started to explore Kubernetes in depth only few weeks ago and I am still at the beginning of my learning journey. Last year I have been playing with Docker quite a bit and I consider learning Kubernetes like the next natural chapter. If you haven’t been introduced to Docker yet, I highly recommend to start from there first and then approach Kubernetes later. You don’t need to know or run Docker to deploy a containerized application distributed with public images in AKS, but you will probably miss some key concepts that would make this learning experience smoother and easier. If you haven’t yet, watch Sitecore Technical Evangelist Rob Earlam’s videos in the Docker and Containers playlist on the Discover Sitecore Youtube channel.

I started my learning journey with Kubernetes watching his last video in the playlist: Running Sitecore on Azure Kubernetes Services, where Rob starts with clearly and concisely explaining the core Kubernetes concepts. While the video is great and the official Sitecore installation guide is very detailed, I felt like I needed to start from deploying something simpler to AKS first and then come back to them later.

The official Azure Kubernetes Service documentation contains a quick tutorial to explore the deployment process of a simpler multi-container application with only two containers in AKS using the Azure CLI. This tutorial gave me the opportunity to gradually get familiar with the core Kubernetes concepts, like cluster, node and service, and the basic Azure CLI commands to create and manage AKS resources. If you want to explore the AKS concepts in more details, I recommend to read the Concepts section in the AKS documentation, in particular the Clusters and Workloads page and the Networking page.

After this initial tutorial exercise, I felt ready to embark on my first Sitecore installation on AKS!

The Sitecore installation on AKS

The official Sitecore Installation Guide for Production Environments with Kubernetes for Sitecore 10.0.1 documents very well the installation process and it is easy to follow in each of its steps. It does directly link to external resources when needed, like for example to the official AKS documentation for the initial step of creating an AKS cluster with a Windows Server 2019 node.

The only issue that I experienced was while deploying an ingress controller following the instructions described at page 15 of the installation guide. The shared helm install command for the ingress controller don’t seem to work. The referred helm chart repository to get a stable image of the nginx ingress controller is not publicly accessible and the deployment command is also missing the following deployment parameter, needed in newer versions of the controller:

--set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux

I ended up using these commands to deploy an ingress controller, based on the steps documented on the AKS documentation portal with the addition of the parameters defined in the Sitecore installation guide (highlighted in bold):

# Create a namespace for your ingress resources
kubectl create namespace ingress-basic

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# Use Helm to deploy an NGINX ingress controller
helm install nginx-ingress ingress-nginx/ingress-nginx `
    --namespace ingress-basic `
    --set controller.replicaCount=2 `
    --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux `
    --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux `
    --set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux `
    --set-string controller.config.proxy-body-size=10m `
    --set controller.service.externalTrafficPolicy=Local

A task of the installation process that seemed a little bit too manual was the creation and update of all secret values in individual secrets files. Some of the secrets need a specific format, as documented in Appendix B of the installation guide. I see an opportunity in the future to automate this step to facilitate the creation process and enforce formatting and best practices

UPDATE on 02/19/2021: I automated the secrets generation step with a PowerShell script based on Sitecore Install Framework module to generate passwords and keys with the required complexity. It can be viewed and downloaded here.

The overall installation process takes usually less than 30 minutes if everything goes smoothly without errors. That is relatively fast in comparison with Azure PaaS installations or distributed on-premises installations.

How expensive is my Sitecore 10 AKS installation?

If you were just experimenting the AKS deployment process and you don’t need the deployed instance, you can easily delete the deployed cluster, its resource group and the related resources with the following Azure CLI command:

az group delete --name myResourceGroup --yes --no-wait

But if you want to keep your deployed Sitecore AKS instance, then you will probably wonder how much it will cost. In general an AKS cluster is always created by default with a Linux node pool and it is recommended to have two nodes for reliability purposes. The AKS cluster created during the installation process has a total of 3 nodes in 2 node pools: 2 nodes in the Linux OS node pool and 1 node in the Windows OS node pool. Each node corresponds to a virtual machine. The scaling and the size of each node pool determines the final cost of the deployed AKS cluster.

If you don’t specify the size of the node VMs in the cluster creation command or in the node creation command using the node-vm-size parameter, the Linux nodes are created with a Standard_DS2_v2 VM size and the Windows node is created with a Standard_D2s_v3 VM size. I created my Windows node with a Standard_D8s_v3 VM size, that meets the minimum installation requirements with 32GB of RAM and 8 CPU cores. The overall cost of my deployed Sitecore AKS cluster was about $450/month and that was definitely more than my available MSDN Azure monthly credit.

Stop and start (when needed) an existing Sitecore AKS cluster

Luckily few months ago the Azure CLI introduced a new command in preview to stop or start an existing AKS cluster, as described here on the AKS documentation. The command requires to install the aks-preview Azure CLI extensions and to register the StartStopPreview preview feature.

The process to stop a cluster takes only a couple of minutes when executing the following command:

az aks stop --name myAKSCluster --resource-group myResourceGroup

The process to start a cluster takes a little bit longer instead, about 15 minutes, mainly spent to provision new VM nodes, pull images from the container registry and start the containers in each pod. Because Kubernetes jobs, like the mssql-init or the solr-init jobs, are executed only once, the only way to execute them again is to delete them first and deploy them again. This is the complete sequence of commands to be invoked to start an existing Sitecore AKS cluster:

# Start the AKS cluster
az aks start --name myAKSCluster --resource-group myResourceGroup

# Delete the existing SQL and Solr init jobs
kubectl delete job mssql-init
kubectl delete job solr-init 

# Deploy SQL and Solr init jobs
kubectl apply -f ./init/

This approach not only allows developers to experiment with a Sitecore AKS sandbox environment without worrying too much about costs, but also allows companies to have non-production AKS environments that mimic production configurations with the same level of scaling and resourcing and starting them only when needed, for example to run regression tests or performance tests.

Conclusions

In this blog post I shared how I started my learning journey with AKS and my experience during the installation process. I also shared a solution to start and stop an existing Sitecore AKS cluster to run a deployed Sitecore solution only when needed and control hosting costs. As always, if you have any questions please don’t hesitate to reach out or comment on this post.

Thank you for reading!