RK Kuppala
Jan 18 · 3 min read
Image Credit: Bhuvi

If the post’s title brought you here — you either know SQL Server or Kubernetes(or both), so we will skip the intros.

It was possible to run Microsoft SQL Server on Docker and it was generally used by enthusiastic DBAs to geek out or dev/experimental environments. With SQL Server’s availability in Linux and the way the platform has been evolving, I think there will soon come a time when running SQL Server workloads on Kubernetes for production will no longer be frowned upon. Also, imagine running .NET core apps with SQL Server backend. Both on GKE. How cool would that be? :)

So, how do we deploy SQL Server on GKE?

Let’s start creating a GKE cluster. For the sake of brevity, we will use gcloud command line tools. We are going to spin a two worker node GKE cluster.

gcloud beta container --project "searce-sandbox" clusters create "mssql-gke-rk" --zone "asia-south1-a" --username "admin" --cluster-version "1.10.9-gke.5" --machine-type "custom-1-2048" --image-type "COS" --disk-type "pd-standard" --disk-size "100"  --num-nodes=2

let’s switch to working on this cluster — this command will generate a kubeconfig entry so that we can interact with the cluster in next steps using kubectl

gcloud container clusters get-credentials mssql-gke-rk \
--zone=asia-south1-a

SQL Server installations require a system admin account, sa . Let’s create a Kubernetes secret which will later use in deployment.

kubectl create secret generic mssql-secrets --from-literal=SA_PASSWORD="YourSuperComplexPassword!!"

Since this is a database server, we need our storage to be durable and persist across pods coming up and going down etc. When you are doing generic VM based installations of SQL Server — its one of the best practices that the SQL Server database data files (mdf) and log files(ldf) and TempDB are configured in different storage volumes because SQL Server’s access methods of data and log files are different — random read/writes vs sequential. We could tap into environment variables and define different volumes for user data and log files for a production like deployment. Unfortunately, the tempdb location is not configurable via environment variable, so we have to live with it for now. We will use GKE’s Persistent Volume Claims and create three volumes.

Create volume claims

kubectl apply -f mssql-base-volume.yaml
kubectl apply -f mssql-mdf-volume.yaml
kubectl apply -f mssql-ldf-volume.yaml

Verify volume claims

Let’s deploy SQL Server now using the following deployment file.

Deploy

kubectl apply -f mssql-deploy.yaml

Check services

There you go! SQL Server is now deployed on GKE and can be accessed using your favorite client. Mine happens to be SSMS.

Just for kicks and giggles — I deleted the pod and saw a new pod coming up, SQL Server accepting connections in under 20 sec.

In the next post, we will deploy SQL Server in HA mode using Availability Groups on Kubernetes.

Hope you find this useful. Happy containerizing!

Searce Engineering

We identify better ways of doing things!

RK Kuppala

Written by

Director — Cloud Engineering, Searce Inc

Searce Engineering

We identify better ways of doing things!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade