Can you, Should you: SQL Server and Kubernetes

Welcome to installment #1. This series will cover SQL Server capabilities, their best usages, and whether or not you should use them at all. I will cover a range of topics, from simple to complex. The main of these is to explain what the capability is and how to best implement it. (A little spoiler on the ‘should you’ question…the answer is almost always going to be ‘it depends’.) The first topic I’m going to cover here is a doozy: Kubernetes.

Containers, Pods and Kubelets, Oh My!

I won’t go very in-depth into these technologies, but I’d like to provide a quick overview of them for some context in this post.

With Docker standardizing containers, there has been a huge change in deployment and management of applications. Containers are…amazing. I’ve spent my career in the Windows world, but actively use and enjoy Linux at every opportunity. Containers have revolutionized the way we deploy and manage applications. They are lightweight, single tasked, easy to spin up, pretty resource-efficient and frankly, a joy to work with.

But with containers comes the need to manage them. That’s where Kubernetes comes in. Kubernetes originated from Google’s Borg container management system. Kubernetes manages containers through Deployments, which are typically composed of one or more containers (these are referred to as a pod) and other resources, such as services, persistent volumes and claims. It defines all the required components of your application. These Deployments can also define Readiness and Liveness health checks. These allow Kubernetes to maintain a consistent state of your application. The Readiness check confirms when an application is up and allowing connections and the Liveness check will ensure that if your application is unresponsive, it will be destroyed and recreated. Using these, Kubernetes automatically maintains high availability of your application.

Can you?

Yes! I’m not going to reinvent the wheel because Microsoft has a great tutorial on deploying SQL Server in Kubernetes. The requirements are:

• A Kubernetes cluster
• Persistent storage on that cluster
• A secret for the SA password
• A deployment file

On the surface they appear straightforward, but in practice (as with any infrastructure) decisions need to be made, based on requirements and adequate research. All your Kubernetes objects should be defined in yaml files to facilitate version control and documentation. You create these files, run a kubectl apply -f file.yaml and there you go.

Should you?

Well…it depends. If you want to mess around in a non-production environment, absolutely! Always be learning. In fact, at Pass Summit 2018 Bob Ward was emphatically enthusiastic about running SQL Server in Kubernetes. He claimed this was the direction. So, should you jump in the production? Well, let’s pause for a minute to take a few things into consideration.

How familiar are you with Linux, containers and SQL Server?

SQL Server in Linux is still very much a new thing. If you’ve been working with SQL Server for a while, it’s a fair assumption that Windows is your bread and butter. Do you have a full understanding of the differences between Linux SQL Server vs Windows? The code base and functionality are almost identical, but management is very different. In addition to Linux, containers are also very new. Do you know how to troubleshoot a container vs a virtual machine?

How familiar are you with Kubernetes?

Ok, so Linux, containers, and SQL Server are new. So is running them in Kubernetes—and Kubernetes is a very complex system. You can spin-up a cluster on a few Raspberry Pi’s in an hour, but that’s not going to run your production load. There are a lot of components in Kubernetes. Are you going to separate etcd on separate servers, do you have high availability for your master nodes, etc. Cloud-based clusters, like Amazon’s EKS, Azure’s AKS and Google’s GKE, certainly take a lot of work out of the equation. But we’re still back to manageability. You must ensure you have an appropriate load-balancing solution in place because, by default, there is no external connectivity to your pod’s network.

Stateless vs stateful

One important concept to understand is stateless vs stateful. A stateless application does not save any data or client information. A stateful application does save this data. In a classic two-stack web app with a front end and database backend, the web app’s front end is usually stateless while the database is stateful. The front end will query the database for any information it needs. In this manner, the stateless component is ephemeral. It can be disposed and recreated easily. It can be scaled up and scaled down as required. The stateful backend is very different. You can’t simply create a new database because you usually require the existing data.

Containers work amazingly well for stateless components. If a front-end instance isn’t working properly, a new instance can be spun-up. Connections, then, are routed to the new instance and the old instance is destroyed.

Special care must be taken when running a stateful component as a container. This is true using Kubernetes (or another container management system). Data must be preserved and attached to a new instance if the old instance fails. This adds even more complexity to the environment.

Maintaining SLAs

At the end of the day, it comes down to not just managing the system, but being comfortable with it and your ability to maintain application SLAs. SLAs are important. They’re how we define the criticality and success of an application.

Migrating to Kubernetes

Start slow

Containers and Kubernetes are incredibly powerful systems that simply automate HA in your environment, but proper evaluation should be considered. If your organization is interested in container-based SQL Server and Kubernetes—depending on your level of experience—start slow. Spin up a cluster and run Dev and QA workloads and testing extensively. Learn Kubernetes. Break your test databases. Rebuild them. Consider running a pilot system for a few users if possible. One of the best things you can do is run a full production workload as a test.

Bring in experts

If your organization is interested in testing and running SQL Server in Kubernetes, Anexinet can assist in all stages of deployment. We have expertise deploying SQL Server across all environments and operating systems, along with a long history of successful evaluations, migrations and modernization of mission critical systems. Please reach out to us with any questions. We’d love to help you get started.