Windows & Kubernetes - how Do They Fit Together?

Kubernetes is the de-facto standard for container orchestration. At the edge, in the core, and in the cloud. That much is clear. We at FullStackS see Kubernetes as a kind of “operating system for the cloud.” But what does the cloud consist of?

Motivation and Background

A cloud consists of Linux servers. But what does that have to do with Windows & Kubernetes?

Containers originated in the Unix/Linux world – as did Kubernetes. The advantages of this technology – let’s call it “Docker” for now – even if that’s no longer true and Docker is long “legacy” – apply not only in Linux environments.

And even more importantly: containers are not – and do not have to be – always microservices. Even “containerized” applications or even monoliths can benefit from the immense advantages of this technology (and especially from Kubernetes). And that is precisely the motivation.

Let’s think about (existing) .NET applications – wouldn’t it be great to be able to operate these in a Kubernetes cluster as part of a modernization effort? –> That’s the use case.

With our partner SUSE / Rancher, we have the most powerful Kubernetes ecosystem on the market. The extremely stable (and certainly still fully covered by the brilliant SUSE support until the end of 2022) Kubernetes distribution RKE1 offers support for Windows Worker Nodes. Yes, you read that right: Windows Worker Nodes.

Come on, Let’s Build a Windows Kubernetes Cluster

For a Windows Kubernetes cluster, we need the following ingredients:

SUSE Rancher (central multi Kubernetes cluster management system)
RKE1 (Rancher Kubernetes Engine)
at least 2 Linux Worker Nodes
at least 1 Windows Worker Nodes

Here we do the setup “by hand” – for our customers, we naturally automate such rollouts with Infrastructure as Code using HashiCorp Terraform

Basic Layout

The following table shows a “minimal scenario” for a Windows Kubernetes cluster

fullstacks Minimal Szenario 1 - FULLSTACKS

In our example, Ubuntu 20.04 LTS and Windows Server 2019 (10.0.17763) with Docker CE 19.03x are used for the Linux nodes. The setup is of course 100% compliant with the current SUSE Support Matrix .

Creating the Windows Kubernetes Cluster in Rancher

Click on ☰ > Cluster Management in the Rancher UI
Click on “Create”
Click on “Custom”
Assign a name for the cluster
Select Kubernetes Version >= 1.19
Select Network Provider “Flannel” and “Windows Support Enable”
Click on Next

fullstacks SUSE Rancher Erstellen eines Windows Kubernetes Cluster - FULLSTACKS

Rancher then presents the appropriate “Registration Command” for each node type (which is also available via the API and via the Terraform Provider).

The process is as follows:

Add Linux Node(s) with Controlplane and etcd role
Add Linux Node(s) with Worker role
Add Windows Node(s)

With Windows, it looks like this:

PowerShell -NoLogo -NonInteractive -Command "& "

Copy & Paste the command into the Windows CMD:

fullstacks Windows Server PowerShell Rancher Registration Command - FULLSTACKS

After a few minutes, the Windows Kubernetes Cluster is complete:

fullstacks SUSE Rancher Windows Kubernetes Cluster 1 - FULLSTACKS

The following container instances are running on the Windows Node(s):

fullstacks kontainer instanzen 1 - FULLSTACKS

Function Test

Now it is time to test the newly created Windows Kubernetes Cluster. At least the following things should be checked:

Kubernetes Cluster (Control Plane, API, etcd)
Deployment Windows Workload
CNI / Network Provider
Ingress (via Linux Worker Node)

For this we have created a simple deployment:

A simple “whoami” application written in .NET, which outputs information via HTTP. The whole thing as a Kubernetes deployment with service and ingress.

As a basis we use the cool container image from

https://hub.docker.com/r/sixeyed/whoami-dotnet

Here is the deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
name: whoami-dotnet
spec:
selector:
matchLabels:
app: whoami-dotnet
template:
metadata:
labels:
app: whoami-dotnet
spec:
containers:
– name: whoami-dotnet
image: sixeyed/whoami-dotnet:3.0
resources:
limits:
memory: “128Mi”
cpu: “500m”
requests:
memory: “64Mi”
cpu: “250m”
ports:
– containerPort: 80
—

apiVersion: v1
kind: Service
metadata:
name: whoami-dotnet
spec:
selector:
app: whoami-dotnet
ports:
– port: 80
targetPort: 80
—

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: whoami-dotnet
annotations:
labels:
name: whoami-dotnet
spec:
rules:
– host: 192.168.4.106.nip.io
http:
paths:
– pathType: Prefix
path: “/”
backend:
service:
name: whoami-dotnet
port:
number: 80

apiVersion: apps/v1
kind: Deployment
metadata:
name: whoami-dotnet
spec:
selector:
matchLabels:
app: whoami-dotnet
template:
metadata:
labels:
app: whoami-dotnet
spec:
containers:
– name: whoami-dotnet
image: sixeyed/whoami-dotnet:3.0
resources:
limits:
memory: “128Mi”
cpu: “500m”
requests:
memory: “64Mi”
cpu: “250m”
ports:
– containerPort: 80
—

apiVersion: v1
kind: Service
metadata:
name: whoami-dotnet
spec:
selector:
app: whoami-dotnet
ports:
– port: 80
targetPort: 80
—

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: whoami-dotnet
annotations:
labels:
name: whoami-dotnet
spec:
rules:
– host: 192.168.4.106.nip.io
http:
paths:
– pathType: Prefix
path: “/”
backend:
service:
name: whoami-dotnet
port:
number: 80