OpenShift Container platform allows you to run Windows workloads
Regardless of the underlying operating systems that your apps use, OpenShift enables you to give them the power of cloud-native development and containerization. Red Hat OpenShift Container Platform (OCP) allows you to deploy Windows workloads running on Windows servers for use cases that call for both Linux and Windows workloads, in addition to supporting conventional Linux workloads hosted on Red Hat Enterprise Linux CoreOS (RHCOS) or Red Hat Enterprise Linux (RHEL).
Getting started
The configuration of a Windows workload on an OCP cluster on Azure employing both Linux and Windows worker nodes is detailed in this post. For its pod and service networks, the OCP cluster makes use of a virtualized network. The default cluster network is a network provider for the OVN-Kubernetes Container Network Interface (CNI) plug-in. Based on an Open Virtual Network (OVN), OVN-Kubernetes offers an implementation of overlay-based networking. A VXLAN tunnel is used for communication between Windows nodes and Windows/Linux combinations, while only the Geneve tunnel is used for communication between Linux nodes. We’ll describe how to create, publish, and deploy a Windows workload on the OCP cluster that is housed on Azure in this post.
A network-intensive tool was specifically chosen for the task to benchmark the systems’ networks. Although it is primarily used for *NIX platforms, the Unified Performance (uperf) http://uperf.org/manual.html was not easily accessible for Windows. Here is a similar compatible codebase that was created especially for Windows.
We can launch the uperf service in “server” mode thanks to Uperf’s usual client-server architecture. The client can be started with a workload definition supplied via an XML file once the server has entered the listening mode.
Exploring the environment
Our OpenShift setup was initially made up of 6 compute nodes (three Windows and three Linux nodes), three control plane nodes, three infrastructure nodes, and six nodes hosted on the Azure cloud. The Red Hat Windows Machine Config Operator (WMCO), which enables the installation and control of Windows worker nodes, is required to handle Windows workloads on OCP. We were able to add Windows Worker Nodes with instance size Standard D8s v3 to the cluster using the following sample machine set:
Node Name | VM Sizes | Number of instances |
Master Nodes | Standard_D8s_v3 | 3 |
Infrastructure Nodes | Standard_D48s_v3 | 3 |
Linux Worker Nodes | Standard_D8s_v3 | 3 |
Windows Worker Nodes | Standard_D8s_v3 | 3 |
Docker Image build and deploy
Every time an uperf container was deployed on OCP or Kubernetes, an uperf process was started. Depending on the parameter(s) given, this process can be regarded as either a client or a server. Here is a sneak preview of the Dockerfile that was used to generate the uperf container image:
Install the relevant runtime on the Windows VM in order to create a container image compatible with Windows:
cd 'C:\Users\vkommadi\Desktop` git clone https://github.com/krishvoor/uperf-windows/ cd uperf-windows git submodule --init --recursive update cd .\uperf-windows docker build -t windows:uperf-simply
Deploying those images in Windows is identical. Uperf will initially be launched in server mode and made reachable on port 30000:
PS C:\Users\vkommadi\Desktop> docker run -d -p 30000:30000 quay.io/krvoora_ocm/windows:uperf-simply uperf -s -v -P 30000 023963ce1cd81c0629c18d5590b4da51275e325f76e644ad56d087713c0a77e9 PS C:\Users\vkommadi\Desktop>
To check if the container is running, do the following:
PS C:\Users\vkommadi\Desktop> docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 023963ce1cd8 quay.io/krvoora_ocm/windows:uperf-simply "uperf -s -v -P 30000" 6 minutes ago Up 6 minutes 0.0.0.0:30000->30000/tcp nifty_satoshi PS C:\Users\vkommadi\Desktop>
Let’s create a parameter file that can be modified to control threads, duration, and packet size so that we can run uperf in client mode and temporarily stress the uperf-server:
PS C:\Users\vkommadi\Desktop>docker run -v "c:\Users\vkommadi\Desktop\uperf":"c:\uperf" quay.io/krvoora_ocm/windows:uperf-simply python c:\uperf\uperf.py
Upon execution, Uperf.exe outputs a large amount of data. Using the Python script simply-uperf, we can easily consume the uperf standard output as follows:
$ docker logs -f fc96d55055dd { "norm_byte_avg": "1.19 GB", "norm_ltcy_avg": 6.830062853840754, "norm_ltcy_p95": 9.448229074093321, "norm_ltcy_p99": 12.689357141501684 } $ pwd vkommadi@ovnhybrid MINGW64 ~/Desktop/uperf (master) $
Deploying Windows workloads on OCP
Utilizing the Kubernetes Deployment service and ConfigMaps objects, we were able to supply declarative updates to Pods, expose the application running on a set of Pods, and supply non-confidential data to Pods in order to deploy this custom Uperf Image to Windows worker nodes.
$ $ git clone https://github.com/krishvoor/uperf-windows/ $ cd uperf-windows $ oc login <API_SERVER> $ oc new-project perf-scale-org $ oc create -f openshift/windows_uperf_server.yml $ IP_ADDRESS=`oc get po <uperf-server-POD_NAME> -o json | jq -r [.status.podIP][]` $ sed -i "s/UPDATEME/${IP_ADDRESS}/g" openshift/windows_uperf_client.yml $ oc create -f openshift/windows_uperf_client.yml $
Bringing it all together
No matter what underlying operating system the cloud-native application depends on, this exercise shows how easily we can implement it on OCP.