 Hi, my name is Christian Hernandez from the Cloud Platforms Business Unit over Red Hat. In this video, I'm going to be going over installation and configuration of Windows container support for Red Hat OpenShift on vSphere. Before you start the installation, you have to make sure you have the OpenShift-Install CLI binary version 4.7. The OC binary version 4.7 is also helpful. We need to do the installation in phases. The reason we need to do the installation in phases is because we'll be making some network customizations for OVN. To get started, create a working directory that we'll be using as a workspace for the install. CD into this working directory once you have created it. Next, we'll create our install config file by running OpenShift-Install create install-config. This will start the installation wizard. First pick an SSH key that you'll use for the installer. Next pick vSphere as your platform. Then enter the vCenter web address. Next enter a username. Either use the administrator username or a user that has enough permissions to run the necessary components to install OpenShift. For a complete list of components necessary, please visit docs.openshift.com. Next enter a password for this user. Then select the default data store. Enter an IP address for the API. This IP address must be a free IP address on your network. It also must have the proper DNS records pointed to it. For more information about these prerequisites, go to docs.openshift.com. Like the API, enter a virtual IP address for the ingress. Again, this needs to be an IP address that is free on your network. Next enter your base domain. Then enter your cluster name. And finally, provide your pull secret. This pull secret is for the installer and can be obtained by visiting cloud.redhat.com. Once you hit enter, this will create an install-config.yaml file in the working directory. By default, OpenShift 4.7 uses OpenShift SDN for the default SDN. You can view this by gripping OpenShift SDN from the install-config file, or by visiting the complete install-config file via VI. We need to change the network type to OVN Kubernetes. Now that the change has been made, check it by running grep of OVN Kubernetes in that install-config.yaml file. Now that that's in place, we can create the manifest for the installer. You can do this by running OpenShift install create manifest. This will create two directories in the working directory. One called manifest and one called OpenShift. We'll be creating a new file in the manifest directory. Go ahead and touch this file, creating cluster-network-03-config.yaml. We'll edit this file and enter the customizations we'll need to enable hybrid networking overlay. The hybrid networking overlay customizations are generally the same. The only two things that you need to keep in mind is that the cluster network CIDR, on line 8, needs to be different than the hybrid cluster network on line 20, meaning they mustn't overlap. Checking the networking configuration files, run an LS to make sure you have three configuration files. Once that's in place, you can go ahead and begin the installation. You can begin the installation by running OpenShift-install create cluster. This will begin the installation of OpenShift 4.7 on your vSphere cluster. Once the installation is finished, go ahead and log into your cluster by running the exportCubeConfig command you see in the log. Once you export this CubeConfig environment variable, verify that you have access to the API by running OC get nodes. Once you've verified that you have access to the API, let's make sure that OVN was installed with hybrid overlay networking. You can do this by running OC get network.operator space cluster. Displaying the configuration as YAML, go ahead and scroll up till you see the configuration. As you can see, we have OVN Kubernetes installed with the hybrid cluster networking overlay configured. Once you've verified this, you're ready to install the Windows Machine Config operator. The Windows Machine Config operator can be installed by using the operator hub. To do this, navigate to operators on the left-hand side and click on operator hub. Filter out the operator by typing in Windows Machine Config operator. Verify that you're installing version 2.0. Version 2.0 is needed in order to configure a Windows Machine running on vSphere. Go ahead and click install. And in the install operator overview page, go ahead and look at the default. The default config should be good enough for any installation, so go ahead and click install. This will launch the installer. The install can take some time, so you can go ahead and keep track of what's going on by running a watch of OC get pods in the OpenShift Windows Machine Config operator namespace. This may take some time, but after a while, the operator will be running a pod in the OpenShift Windows Machine Config operator namespace. Once you go back to the web UI, you can verify that the installer has finished by looking at the green check mark and go ahead and clicking on view operator. In the operator view overview page, it'll give you information on how to continue the installation. For the Windows Machine Config operator, you'll need an SSH key. An SSH key is used to interact with the Windows node for setup and configuration. Before we upload this key as a secret into OpenShift, we need to create it. To create an SSH key, go ahead and run SSH key gen. Enter a path where to save the key. By default, this is saved under your home directory under the .ssh directory. We're gonna name this key windows underscore node. Go ahead and keep the passphrase empty. Now you can copy and paste the example command from the operator hub overview page, changing the example key to the key you just created. Verify the key was successfully uploaded into OpenShift by running an OC get secret of cloud-private-key, which is the name of the secret. In the OpenShift Windows Machine Config operator namespace. Now that you have the key uploaded and the operator running, you're now ready to install a Windows node. Before we get to that, take a look at the web UI for your vSphere cluster. Note that the installer installs OpenShift in a folder called your cluster ID dash UUID with all your VMs. This is where we're gonna install the Windows VM. To install the Windows VM, you first must create a Windows node golden image. Creating a Windows Server 2019 golden image is beyond the scope of this video, but I'm gonna go over some of the prerequisites that must be in place in order for the Windows Machine Config operator to run properly. First, you need a version of Windows Server 2019 that the Windows Machine Config operator supports. Security patches is up to date, but at a minimum, you need KB456-5351 installed. On the Windows firewall, you need to open TCP port 10250 in order for the container logs to pass through. SSH needs to be installed and configured properly. SSH needs to be installed and needs to start on boot. Also, keybase authentication needs to be in place for the Windows administrator user. This means that I should be able to SSH into the Windows node as administrator using keybase SSH authentication without a password. Docker runtime needs to be installed. Take note that in future versions, container D will be used as a runtime, but for now, install Docker. Container images pre-pulled onto the node. Windows container images could be quite large and therefore could cause timeouts when trying to deploy applications. Therefore, it's recommended that you pre-pull any images onto the node before you run sysprep. You need to install VMware tools as well. And lastly, before you shut down the VM, you need to run sysprep. The server must be sysprep in such a way that it preserves all the changes you made to the VM, including SSH authentication, SSH starting on boot, and all security patches. Remember that the OpenShift installer creates a directory inside of vSphere where it keeps all the OpenShift VMs for your cluster together. I created my Windows golden image VM in the same directory. You don't have to do it that way, but I like to keep my things together. Note for consistency purposes, I named my Windows VM similarly to how REL CoreOS named its VM. Also, I'm keeping this as a VM, but you can convert it to a VM template if you choose to do so. Going back to the Windows Machine Config Operator overview page, you can see that there's important documentation on how to work with this operator. Part of this documentation is a sample machine set that you can use in order to create your Windows machine. You can use this as sort of a template in order to formulate your own. You'll need information about your cluster and storage information. For more info on how to formulate a proper machine set for your installation, please visit docs.openshift.com. Using this template, I created my own Windows machine set. Before I apply it to the cluster, I'd like to point out a few things. First, note that I'm using the name WindWorker, which is about nine characters. Nine characters is a max because of the way the OpenShift creates names out of the machine set and the character limitation of Windows. Also note that I'm labeling my Windows worker as a worker. For the template section, note that I'm providing a full path to my template. You don't have to do it this way, but I like to be specific as possible. Lastly, note the workspace section. You'll need information like the data center you're in, the data store, the folder you'll be installing, the resource pool, and the server. Again, for more information about what's available to you, please visit docs.openshift.com. Now that we created this Windows machine set, I can apply it to the cluster by running oc create dash f and specifying the file manifest. Once this is loaded in OpenShift, this will create a machine set for you. To list the machine sets, run oc get machine sets in the OpenShift machine API namespace. You should see that you have a new machine set named WindWorker. This should create a machine for you. To see your machines run oc get machines in the same OpenShift machine API namespace. This has a status of provisioning. To see what's going on, go ahead and switch over to your vSphere UI. In the UI, you can see that there's a new VM being created. This is being cloned from your Windows golden image VM. If you look down at your events in your vSphere UI, you can see that the clone process is taking place. You can follow the entire process by looking at the Windows Machine Config Operator Pod. In order to do this, go ahead and first get the pod name by running oc get pods in the OpenShift Windows Machine Config Operator namespace. Now that you have the name of the pod, you can inspect this logs by running oc logs specifying the Windows Machine Config Operator namespace and then the name of the actual pod. To follow the logs, you can pass the same command with the dash F. After a while, the process should be done. Once the process is done, you'll get a message of a successfully reconciled. Once you see this message, you should have a new Windows VM joined to the cluster. Run oc get nodes and you should see there's a new worker joined to the cluster. To specifically list Windows nodes, run oc get nodes with a dash L for label selector and specify the label kubernetes.io slash os equals Windows. You can get even more information about your Windows VM by running the oc describe nodes command. Once you run the oc describe nodes command, go ahead and scroll up to see information about your VM. Specifically, I wanna call out the system info section. System info section has things like the machine ID, the version of the OS you're running and the container runtime that it's using. I wanna call out something else specific to the Windows nodes. If you run oc describe and look at the taint, you'll see that this is tainted with the os windows equals no schedule. This is to prevent for Linux containers to be run on this node. To deploy a sample application, you will need this tainted information. This sample application deploys a namespace, a deployment and a service. This sample app has the tolerations of os windows no schedule. I also want you to note that the image I'm using is specific to the version of Windows that I'm running. Please visit docs.microsoft.com for more information. The security context says that run as username is container administrator. Note that this user is the user inside the container. And finally, there's a node selector choosing specifically the Windows node. To deploy this application, run an ocapply-f specifying the manifest. If you do an oc get pods in the Windows workloads namespace, you should see the pod is starting to create. Also note that I did create a service pointing to this deployment. Deployment can take some time. So go ahead and run a watch and the oc get pods in this Windows workload namespace. And after a while, the application should be up and running. If you do an oc get svc and pods in this Windows workloads namespace, you should see all the manifests that were created. Looking at oc get pods with dash o wide, you can see that this pod is running on the Windows worker. Let's explore a bit. If I do an oc describe node of my Windows worker and grep for the external IP, I can actually SSH into this Windows VM using the IP by specifying the SSH key I created in the beginning along with the administrator username. This should drop you to a CMD prompt. Go ahead and run the PowerShell command in order to get to an interactive PowerShell prompt. Running Docker PS should show the containers that are running inside this Windows VM. Then running Docker images should show you any pre-pulled images that you have on this VM plus any images that were pulled as part of this application deployment. Running the get process command and looking for cube overlay and Docker, you should see the processes needed in order to run Windows VM in an OpenShift cluster. Things like DockerD, hybrid overlay node, the kubelet and the kube proxy. Go ahead and exit out of this SSH session. Not only can you see the containers that are running on the Windows VM itself, but you can also remote shell into the pods. First, do an oc get pods in the Windows workloads namespace. This will get you the name of the pod. Next, running the oc command by specifying the Windows workloads namespace, you can pass in the exec command. We're gonna run an interactive TTY session on this Windows pod and we're gonna run the PowerShell command. Now you're inside the actual container itself. Looking at your environment variable and seeing which user you are, you can see that container administrator, what we passed in the deployment configuration is the name of the user that is running this pod. For more information, visit docs.openshift.com. Just like any other application, you can expose the service in order to create a route by running oc expose svc and the name of the service inside the Windows workloads namespace. You can get your route by running an oc get routes in this Windows workloads namespace. Copying this URL, you can go to your web browser and visit this application. I hope you enjoyed this demonstration of Windows container support for Red Hat OpenShift and invite you to try it out yourself. Thank you.