Scheduling Windows container workloads

    • You installed the Windows Machine Config Operator (WMCO) using Operator Lifecycle Manager (OLM).

    • You are using a Windows container as the OS image with the Docker-formatted container runtime add-on enabled.

    • You have created a Windows machine set.

    Before deploying your Windows workloads to the cluster, you must configure your Windows node scheduling so pods are assigned correctly. Since you have a machine hosting your Windows node, it is managed the same as a Linux-based node. Likewise, scheduling a Windows pod to the appropriate Windows node is completed similarly, using mechanisms like taints, tolerations, and node selectors.

    With multiple operating systems, and the ability to run multiple Windows OS variants, in the same cluster, you must map your Windows pods to a base Windows OS variant by using a . For example, if you have multiple Windows nodes running on different Windows Server container versions, the cluster could schedule your Windows pods to an incompatible Windows OS variant. You must have RuntimeClass objects configured for each Windows OS variant on your cluster. Using a RuntimeClass object is also recommended if you have only one Windows OS variant available in your cluster.

    For more information, see Microsoft’s documentation on Host and container version compatibility.

    Procedure

    1. Create a RuntimeClass object YAML file. For example, runtime-class.yaml:

    2. Create the RuntimeClass object:

      1. $ oc create -f <file-name>.yaml

      For example:

      1. $ oc create -f runtime-class.yaml

    3. Apply the RuntimeClass object to your pod to ensure it is scheduled to the appropriate operating system variant:

    You can deploy Windows container workloads to your cluster once you have a Windows compute node available.

    Example Service object

    1. apiVersion: v1
    2. kind: Service
    3. metadata:
    4.   name: win-webserver
    5.   labels:
    6.     app: win-webserver
    7.   ports:
    8.     # the port that this service should serve on
    9.   - port: 80
    10.     targetPort: 80
    12.     app: win-webserver
    13.   type: LoadBalancer

    Example Deployment object

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   labels:
    5.     app: win-webserver
    6.   name: win-webserver
    7. spec:
    8.   selector:
    9.     matchLabels:
    10.       app: win-webserver
    11.   replicas: 1
    12.   template:
    13.     metadata:
    14.       labels:
    15.         app: win-webserver
    16.       name: win-webserver
    17.       tolerations:
    18.       - key: "os"
    20.         Effect: "NoSchedule"
    21.       containers:
    22.       - name: windowswebserver
    23.         image: mcr.microsoft.com/windows/servercore:ltsc2019
    24.         imagePullPolicy: IfNotPresent
    25.         command:
    26.         - powershell.exe
    27.         - -command
    28.         - $listener = New-Object System.Net.HttpListener; $listener.Prefixes.Add('http://*:80/'); $listener.Start();Write-Host('Listening at http://*:80/'); while ($listener.IsListening) { $context = $listener.GetContext(); $response = $context.Response; $content='<html><body><H1>Red Hat OpenShift + Windows Container Workloads</H1></body></html>'; $buffer = [System.Text.Encoding]::UTF8.GetBytes($content); $response.ContentLength64 = $buffer.Length; $response.OutputStream.Write($buffer, 0, $buffer.Length); $response.Close(); };
    29.         securityContext:
    30.           windowsOptions:
    31.             runAsUserName: "ContainerAdministrator"
    32.       nodeSelector:
    33.         beta.kubernetes.io/os: windows

    This guidance is relevant to fully automated, installer-provisioned infrastructure installations. Customized, user-provisioned infrastructure installations do not have machine sets.

    Prerequisites

    • Install an OKD cluster and the oc command line.

    • Log in to oc as a user with cluster-admin permission.

    Procedure

    1. View the machine sets that are in the cluster:

      The machine sets are listed in the form of <clusterid>-worker-<aws-region-az>.

    2. Scale the machine set:

      Or:

      1. $ oc edit machineset <machineset> -n openshift-machine-api

      You can scale the machine set up or down. It takes several minutes for the new machines to be available.