It took a while to recover from all the VMworld goodness, but now its time to start working on the next thing, which is MS Ignite. Ignite is just 4 weeks away at this point, so I decided to start tinkering my way through a Windows Server-based Kubernetes Cluster. If you missed the announcement back during the Kubernetes 1.14 launch, you can read more about it on this link. If I had to describe it in one sentence, it means that now I can run Windows Server VM/Hosts as worker nodes in my Kubernetes Clusters. “Worker Node” is the operative word here. This means that I still need to run control plane components like API-Server, Kube-Scheduler, etc on one or more Linux VMs/Hosts. Based on blogs I have read and podcasts that I listen to, Microsoft prioritized the ability to run Windows-based Worker nodes over Master nodes, because they want people to start adopting or using Windows Containers. The control plane components are written in Go, and can easily be migrated to Windows Server in future releases.
Although I wanted this blog to do a deep dive and provide step-by-step instructions on how you can set up a Kubernetes cluster using Windows worker nodes, I feel that it would be better if we took some time to talk about what Windows Containers are.
There are two main types or runtimes of Windows Containers:
- Process Isolation – Windows Containers: These provide process and namespace level isolation between containers running on the same host. But, this also means that these containers share the same underlying kernel with the Windows Server Host that is running these containers. Since they share the same kernel, containers that need different kernel version cannot run on the same container host. Based on Microsoft’s recommendation, you shouldn’t be running untrusted containers on the same host, as these containers don’t provide strong security boundaries.
- Hyper-V Isolation – Windows Containers: These provide strong security boundaries between containers as they run in dedicated, highly-optimized virtual machines. Also, since they are running in different virtual machines, they don’t share the same kernel, which means each container (virtual machine) can have a different kernel version running. This also means that you can run untrusted code/containers on the same host with the same security assurances as virtual machines. If you want to run Hyper-V Isolation containers, you need to enable the Hyper-V feature on the container host. One caveat here, Hyper-V Isolation containers are still in alpha for Kubernetes.
Now that you understand that different types of Windows Containers, we can talk about how these are actually delivered. Microsoft publishes base container images on docker hub which you can use as the Base Image for running your applications. Come “Patch Tuesday”, all you have to do is change the base image to the latest one published by Microsoft and you are good to go. There are basically three main types of Windows Container images:
- Nano Server: This is the smallest windows container image available. It has support for .NET Core, so perfect for your new cloud-native app development. It’s around 94 MB in size.
- Windows Server Core: This is a bigger image as compared to the Nano Server. It’s around 1.4 GBs in size, but with that increased size also comes support for the entire .NET Framework support.
- Windows Server: Instead of looking at this as a big container image, think about this as a really small Windows Server VM. It’s around 3.4GB is size, but it carries most of the Windows OS components. So, if the Windows Server Core image doesn’t work for you because it’s missing a few libraries, you can use Windows Server. This still gives you way better performance than running virtual machines. This image can help you migrate your applications from VMs to containers, and then you can work on optimizing your application later on.
You can run all these images in Windows Server Process Isolation mode or Hyper-V Isolation mode. That’s a runtime decision that you can make. This is great, but how do you decide which applications are ready to be migrated from VMs to containers. My recommendation would be to start by experimenting and deploying stateless workloads like your Web Applications, IIS Apps and .NET Applications, and as you get accustomed to using containers, you can start experimenting with more stateful applications.
Hopefully, this post gave you a good introduction on what Windows Containers are. In the next one, we will look at how you can deploy a Kubernetes cluster with Windows Worker nodes and deploy some windows containers.