gMSA and OpenShift In previous articles, we have shown how you can manage Windows Containers in OpenShift using the Windows Machine Config Operator. By configuring this feature, we are able to deploy and manage Windows Container Images just like any other Container Image with OpenShift. This gives us additional paths to application modernization allowing app developers to move over things like .Net legacy apps to OpenShift without having to re-write large portions of code.

If you are looking to try out Windows Containers managed by Kubernetes, you are going to need at least one Windows Server to host the containers. You can follow the steps from OpenShift Windows Containers - Bring Your Own Host and manually add a Windows server to an OpenShift Cluster. You can also use the Windows Machine Config Operator (WMCO) to automatically scale Windows nodes up and down in your cluster.

When it comes to running Windows Containers, the only straight forward way to run them has been through Docker Desktop. Starting in August of 2021, the license that Docker Desktop was distributed under changed. It became “Free for personal use” only. If you were using it as a part of your day-2-day job, you were going to need a subscription/license. (see Docker Subscriptions for more details.) But what if you don’t need the fancy UI, and you just want to run Windows Containers on your Windows 10 or 11 host?

OpenShift has supported Windows Containers with the Windows Machine Config Operator for the past year, starting with OCP 4.6. Initial Windows Container support required running your platform in Azure or AWS. With the release of 4.7, the WMCO also supported hosting machines in VMWare. However, when deploying in a VMWare environment you had to spend time configuring a base Windows image, using tools such as sysprep and VMware templates. What if you wanted to use a bare metal host(s), or wanted to take advantage of existing Windows servers that you already manage.