Windows & Kubernetes - Wie passt das zusammen?

Kubernetes ist der de-facto Standard für Container-Orchestration. Im Edge, im Core und in der Cloud. Soviel ist klar. Wir als FullStackS sehen in Kubernetes eine Art „Betriebssystem für die Cloud“. Aber woraus besteht die Cloud?

Motivation und Hintergrund

Eine Cloud besteht aus Linux Servern. Aber was hat das mit Windows & Kubernetes zu tun?

Container haben Ihren Ursprung in der Unix/Linux Welt – wie auch Kubernetes. Die Vorteile dieser Technologie – nennen wir sie einmal „Docker“ – auch wenn das nicht mehr stimmt und Docker längst „Legacy“ ist – gelten nicht nur in Linux-Umgebungen.

Und noch viel wichtiger: Container sind – und müssen – nicht immer gleich Microservices sein. Auch „containerisierte“ Applikationen oder gar Monolithen können von den durchaus immensen Vorteilen dieser Technologie (und vor allem von Kubernetes) profitieren. Und genau das ist die Motivation.

Denken wir einmal an (bestehende) .NET Applikationen – wäre es nicht toll, diese in einem Kubernetes Cluster, im Rahmen einer Modernisierung dieser, betreiben zu können? –> Das ist der Use-Case.

Mit unserem Partner SUSE / Rancher verfügen wir über das leistungsfähigste Kubernetes Ökosystem am Markt. Die überaus stabile (und sicher noch bis Ende 2022 vollkommen durch den brillianten SUSE Support abgedeckte) Kubernetes Distribution RKE1 bietet Unterstützung für Windows Worker Nodes. Ja, richtig gelesen : Windows Worker Nodes.

Komm, wir bauen einen Windows Kubernetes Cluster

Für einen Windows Kubernetes Cluster benötigen wir folgende Zutaten:

SUSE Rancher (zentrales Multi Kubernetes Cluster Management System)
RKE1 (Rancher Kubernetes Engine)
mindestens 2 Linux Worker Nodes
mindestens 1 Windows Worker Nodes

Hier machen wir das Setup „von Hand“ – für unsere Kunden automatisieren wir derartige Rollouts natürlich mit Infrastructure as Code mittels HashiCorp Terraform

Grundsätzliches Layout

Folgende Tabelle zeigt ein „Minimal Szenario“ für einen Windows Kubernetes Cluster

fullstacks Minimal Szenario 1 - FULLSTACKS

In unserem Beispiel kommt für die Linux Nodes Ubuntu 20.04 LTS und Windows Server 2019 (10.0.17763) mit Docker CE 19.03x zum Einsatz. Das Setup ist natürlich 100% konform mit der aktuellen SUSE Support Matrix .

Erstellen des Windows Kubernetes Cluster in Rancher

Click auf ☰ > Cluster Management im Rancher UI
Click auf “Create”
Click auf “Custom”
Name für den Cluster vergeben
Kubernetes Version >= 1.19 auswählen
Network Provider “Flannel” und “Windows Support Enable” auswählen
Klick auf Next

fullstacks SUSE Rancher Erstellen eines Windows Kubernetes Cluster - FULLSTACKS

Anschliessend präsentiert Rancher das für den jeweiligen Node Typ passenden „Registration Command (welches übrigens auch über die API und über den Terraform Provider zur Verfügung steht).

Der Ablauf ist wie folgt:

Linux Node(s) mit Controlplane und etcd Rolle hinzufügen
Linux Node(s) mit Worker Rolle hinzufügen
Windows Node(s) hinzufügen

Bei Windows sieht das wie folgt aus:

PowerShell -NoLogo -NonInteractive -Command „& "

Copy & Paste des Kommandos in die Windows CMD:

fullstacks Windows Server PowerShell Rancher Registration Command - FULLSTACKS

Nach wenigen Minuten ist der Windows Kubernetes Cluster komplett:

fullstacks SUSE Rancher Windows Kubernetes Cluster 1 - FULLSTACKS

Folgende Container Instanzen laufen auf den Windows Node(s):

fullstacks kontainer instanzen 1 - FULLSTACKS

Funktionstest

Nun ist es an der Zeit, den frisch erstellten Windows Kubernetes Cluster zu testen. Mindestens folgende Dinge sollen geprüft werden:

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

Dazu haben wir ein simples Deployment erstellt:

Eine einfache, in .NET geschriebene „whoami“ Applikation, welche über HTTP Informationen ausgibt. Das ganze als Kubernetes Deployment mit Service und Ingress.

Als Basis nutzen wir das coole Container Image von

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

Hier das 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