Creating a Windows Template for use with OpenShift Windows Machine Config Operator
By Mark DeNeve
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.
In order to allow the WMCO to handle Windows machine creation we need to have a OS template for the platform we are deploying on. In this case, we will be deploying our OpenShift cluster on a vSphere cluster and will need to create a vSphere template for the WMCO to leverage. The steps detailed in this blog post will help you create a Windows Server 2022 template. We will create a “core” server template (minimal UI) since these will be for running containers only.
Download the install ISO for Windows Server 2022
Since we will be creating a Windows Server 2022 vSphere template, you will need Windows Server 2022 install media from Microsoft. You can use an evaluation ISO from Evaluate Windows Server 2022 or whatever other source you might have.
Create the VM shell
When creating the virtual machine in vSphere, be sure to use VMWare Paravirtual SCSI hardware as well as VMXNet hardware for network. Windows Server 2022 has drivers available as part of the ISO install which makes using these optimized hardware devices much simpler than in the past.
Installing Windows Server 2022
Boot from the Windows Install ISO and be sure to select the “no desktop experience” version.
- Windows 2022 Core (no desktop experience)
This will install the minimal Windows OS, with no GUI. This helps to cut down on the overall size of the VM Template and will make the creation of new machines from this template faster to start up.
After OS is installed, be sure to install vMware tools from the vCenter virtual machine menu options. These tools must be installed for the Windows Machine Config Operator to work.
Customizing the template
With your Windows 2022 Server installed, we need to go through and customize the OS before turning it into a template. We will also make sure that the template is patched. Log into the server and run the following commands to get the system to our base configuration:
# Start by Renaming the Server
Rename-Computer -NewName "win2022-tmpl" -Force
#Install PS Windows Update Module
Get-PackageProvider -name nuget -force
Install-Module PSWindowsUpdate -confirm:$false -force
Get-WindowsUpdate -Install -acceptall -IgnoreReboot
Restart-Computer -Force
You may find that you need to run the patch process, multiple times. “Lather, Rinse, Repeat” the patch command until you are told no more patches are available.
# Rinse and repeat until your host is patched
Get-WindowsUpdate -Install -acceptall -IgnoreReboot
Restart-Computer -Force
The Windows Machine Config Operator makes use of SSH to remotely manage and install the required components to join your OpenShift cluster. Install SSH on the machine and ensure that it is set to start automatically:
# Install openssh server
# Install the OpenSSH Server
Add-WindowsCapability -Online -Name OpenSSH.Server
# Start the sshd service
Start-Service sshd
# OPTIONAL but recommended:
Set-Service -Name sshd -StartupType 'Automatic'
With SSH installed, from another machine, attempt to connect to the machine using the username “Administrator” and the password that you set during install.
ssh administrator@<ip address of vm machine>
With SSH tested, we need to configure the Windows Firewall to allow for container logs to be available to the OpenShift Platform.
# add firewall rule
New-NetFirewallRule -DisplayName "ContainerLogsPort" -LocalPort 10250 -Enabled True -Direction Inbound -Protocol TCP -Action Allow -EdgeTraversalPolicy Allow
Install Chocolatey
We are going to need to edit the VMware tools config file to ensure that it properly identifies the IP address of the host. The easiest way to do this remotely is using the nano editor. The easiest way to install nano is using Chocolatey. We will install Chocolatey and then install nano.
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
# install nano editor
choco install nano
Update VMware config file
With nano installed, make a copy of the example file, and then edit the file.
cp C:\ProgramData\VMware\VMware Tools\tools.conf.example C:\ProgramData\VMware\VMware Tools\tools.conf
nano "C:\ProgramData\VMware\VMware Tools\tools.conf"
Ensure that there is a configuration line that says:
exclude-nics=
This will ensure that all of the network cards (including the virtual ones that are created by the Windows Machine Config Operator) are identified and available in the vSphere APIs.
Configuring Windows for Remote SSH Access
Our Windows server now has all the prerequisites installed but we still need to enable remote access to the Windows box using an SSH key. It is suggested that you generate an ssh key specifically for use with your Windows host(s). The following steps are based on the official Microsoft documentation for OpenSSH Key Management
Start by creating a new ssh key pair for administrator use. We will create this new key as ~/.ssh/winserver
and use this key pair for the remainder of the blog post. If you are creating the key pair from a Windows host you will need to slightly modify your commands below:
# Generate a new SSH key file
ssh-keygen -t ed25519 -N '' -f ~/.ssh/winserver
# Copy the public key over to your windows box
scp ~/.ssh/winserver administrator@<BYOH IP address>
Now SSH to your BYOH server and run the following commands to set up the ssh key to have administrator rights:
ssh administrator@<BYOH IP address>
# by default, Windows will put you in the command shell, switch to powershell
powershell
New-Item -Type File -Path C:\ProgramData\ssh\administrators_authorized_keys
get-acl C:\ProgramData\ssh\ssh_host_dsa_key | set-acl C:\ProgramData\ssh\administrators_authorized_keys
Get-Content winserver.pub | Out-File C:\ProgramData\ssh\administrators_authorized_keys -Encoding UTF8 -Append
As the last step, let’s check to ensure that the ssh key pair is working and you can remotely access the BYOH Windows server without the use of a password. The following command will use your ~/.ssh/winserver
private key to authenticate to the Windows host and will connect you to the Windows server without the use of a password:
ssh -i ~/.ssh/winserver administrator@<>
Microsoft Windows [Version 10.0.17763.2300]
(c) 2018 Microsoft Corporation. All rights reserved.
administrator@WIN2019-PET1 C:\Users\Administrator>
You should get connected without the use of a password. If you are still prompted for a password revisit the steps in this section to ensure you didn’t miss any steps, or review the Microsoft documentation on OpenSSH Key Management for additional assistance.
Sysprep the template
The final step is to sysprep the image to generalize the image. This will keep your ssh key in place, so that when a clone is made, the machine will not run into issues with additional copies of itself on the network. You will need a “unattend.xml” file to run the sysprep command. Download a copy from here unattend.xml. Edit the file and be sure to update the MyPassword placeholder in the file, before copying it to your template image.
With the unattend.xml file copied to your machine, its time to run the sysprep command. This will shut down the virtual machine as part of the process:
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown /unattend:<path/to/unattend.xml>
Create the VM Template
Once the VM has shut down right click on the VM and select “Convert to Template”.
Conclusion
Your template is now ready to be used with the OpenShift Windows Machine Config Operator. Review the documentation Sample YAML for a Windows MachineSet object on vSphere for your next steps in creating new Windows worker nodes.