Chapter 5. Enabling Windows container workloads

Procedure

1. From the Administrator perspective in the OpenShift Container Platform web console, navigate to the Operators OperatorHub page.
2. Use the Filter by keyword box to search for Windows Machine Config Operator in the catalog. Click the Windows Machine Config Operator tile.
3. Review the information about the Operator and click Install.

4. On the Install Operator page:

   1. Select the stable channel as the Update Channel. The stable channel enables the latest stable release of the WMCO to be installed.
   2. The Installation Mode is preconfigured because the WMCO must be available in a single namespace only.
   3. Choose the Installed Namespace for the WMCO. The default Operator recommended namespace is openshift-windows-machine-config-operator.
   4. Click the Enable Operator recommended cluster monitoring on the Namespace checkbox to enable cluster monitoring for the WMCO.

   5. Select an Approval Strategy.

      • The Automatic strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
      • The Manual strategy requires a user with appropriate credentials to approve the Operator update.

5. Click Install. The WMCO is now listed on the Installed Operators page.

   Note

   The WMCO is installed automatically into the namespace you defined, like openshift-windows-machine-config-operator.

6. Verify that the Status shows Succeeded to confirm successful installation of the WMCO.

Procedure

1. Create a namespace for the WMCO.

   1. Create a Namespace object YAML file for the WMCO. For example, wmco-namespace.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-windows-machine-config-operator 

      1

      
        labels:
          openshift.io/cluster-monitoring: "true" 

      2

      Copy to Clipboard Toggle word wrap

      1

      It is recommended to deploy the WMCO in the openshift-windows-machine-config-operator namespace.

      2

      This label is required for enabling cluster monitoring for the WMCO.

   2. Create the namespace:

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

      Copy to Clipboard Toggle word wrap

      For example:

      $ oc create -f wmco-namespace.yaml

      Copy to Clipboard Toggle word wrap

2. Create the Operator group for the WMCO.

   1. Create an OperatorGroup object YAML file. For example, wmco-og.yaml:

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: windows-machine-config-operator
        namespace: openshift-windows-machine-config-operator
      spec:
        targetNamespaces:
        - openshift-windows-machine-config-operator

      Copy to Clipboard Toggle word wrap

   2. Create the Operator group:

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

      Copy to Clipboard Toggle word wrap

      For example:

      $ oc create -f wmco-og.yaml

      Copy to Clipboard Toggle word wrap

3. Subscribe the namespace to the WMCO.

   1. Create a Subscription object YAML file. For example, wmco-sub.yaml:

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: windows-machine-config-operator
        namespace: openshift-windows-machine-config-operator
      spec:
        channel: "stable" 

      1

      
        installPlanApproval: "Automatic" 

      2

      
        name: "windows-machine-config-operator"
        source: "redhat-operators" 

      3

      
        sourceNamespace: "openshift-marketplace" 

      4

      Copy to Clipboard Toggle word wrap

      1

      Specify stable as the channel.

      2

      Set an approval strategy. You can set Automatic or Manual.

      3

      Specify the redhat-operators catalog source, which contains the windows-machine-config-operator package manifests. If your OpenShift Container Platform is installed on a restricted network, also known as a disconnected cluster, specify the name of the CatalogSource object you created when you configured the Operator LifeCycle Manager (OLM).

      4

      Namespace of the catalog source. Use openshift-marketplace for the default OperatorHub catalog sources.

   2. Create the subscription:

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

      Copy to Clipboard Toggle word wrap

      For example:

      $ oc create -f wmco-sub.yaml

      Copy to Clipboard Toggle word wrap

      The WMCO is now installed to the openshift-windows-machine-config-operator.

4. Verify the WMCO installation:

   $ oc get csv -n openshift-windows-machine-config-operator

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                                    DISPLAY                           VERSION   REPLACES   PHASE
   windows-machine-config-operator.2.0.0   Windows Machine Config Operator   2.0.0                Succeeded

   Copy to Clipboard Toggle word wrap

Procedure

1. Configure mirrored repositories, by either:

   • Setting up a mirrored repository with Red Hat Quay, as described in Red Hat Quay Repository Mirroring. Using Red Hat Quay allows you to copy images from one repository to another and also automatically sync those repositories repeatedly over time.

   • Using a tool such as skopeo to copy images manually from the source repository to the mirrored repository.

     For example, after installing the skopeo RPM package on a Red Hat Enterprise Linux (RHEL) 7 or RHEL 8 system, use the skopeo command as shown in this example:

     $ skopeo copy --all \
     docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
     docker://example.io/example/ubi-minimal

     Copy to Clipboard Toggle word wrap

     In this example, you have a container image registry that is named example.io with an image repository named example to which you want to copy the ubi9/ubi-minimal image from registry.access.redhat.com. After you create the mirrored registry, you can configure your OpenShift Container Platform cluster to redirect requests made of the source repository to the mirrored repository.

   Important

   You must mirror the mcr.microsoft.com/oss/kubernetes/pause:3.9 image. For example, you could use the following skopeo command to mirror the image:

   $ skopeo copy \
   docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\
   docker://example.io/oss/kubernetes/pause:3.9

   Copy to Clipboard Toggle word wrap
2. Log in to your OpenShift Container Platform cluster.

3. Create an ImageDigestMirrorSet or ImageTagMirrorSet CR, as needed, replacing the source and mirrors with your own registry and repository pairs and images:

   apiVersion: config.openshift.io/v1 

   1

   
   kind: ImageDigestMirrorSet 

   2

   
   metadata:
     name: ubi9repo
   spec:
     imageDigestMirrors: 

   3

   
     - mirrors:
       - example.io/example/ubi-minimal 

   4

   
       - example.com/example2/ubi-minimal 

   5

   
       source: registry.access.redhat.com/ubi9/ubi-minimal 

   6

   
       mirrorSourcePolicy: AllowContactingSource 

   7

   
     - mirrors:
       - mirror.example.com
       source: registry.redhat.io
       mirrorSourcePolicy: NeverContactSource
     - mirrors:
       - docker.io
       source: docker-mirror.internal
       mirrorSourcePolicy: AllowContactingSource

   Copy to Clipboard Toggle word wrap

   1

   Indicates the API to use with this CR. This must be config.openshift.io/v1.

   2

   Indicates the kind of object according to the pull type:

   • ImageDigestMirrorSet: Pulls a digest reference image.
   • ImageTagMirrorSet: Pulls a tag reference image.

   3

   Indicates the type of image pull method, either:

   • imageDigestMirrors: Use for an ImageDigestMirrorSet CR.
   • imageTagMirrors: Use for an ImageTagMirrorSet CR.

   4

   Indicates the name of the mirrored image registry and repository.

   5

   Optional: Indicates a secondary mirror repository for each target repository. If one mirror is down, the target repository can use another mirror.

   6

   Indicates the registry and repository source, which is the repository that is referred to in image pull specifications.

   7

   Optional: Indicates the fallback policy if the image pull fails:

   • AllowContactingSource: Allows continued attempts to pull the image from the source repository. This is the default.
   • NeverContactSource: Prevents continued attempts to pull the image from the source repository.

4. Create the new object:

   $ oc create -f registryrepomirror.yaml

   Copy to Clipboard Toggle word wrap

5. To check that the mirrored configuration settings are applied, do the following on one of the nodes.

   1. List your nodes:

      $ oc get node

      Copy to Clipboard Toggle word wrap

      Example output

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.30.3
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.30.3
      ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.30.3

      Copy to Clipboard Toggle word wrap

   2. Start the debugging process to access the node:

      $ oc debug node/ip-10-0-147-35.ec2.internal

      Copy to Clipboard Toggle word wrap

      Example output

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

      Copy to Clipboard Toggle word wrap

   3. Change your root directory to /host:

      sh-4.2# chroot /host

      Copy to Clipboard Toggle word wrap

   4. Check that the WMCO generated a hosts.toml file for each registry on each Windows instance. For the previous example IDMS object, there should be three files in the following file structure:

      $ tree $config_path

      Copy to Clipboard Toggle word wrap

      Example output

      C:/k/containerd/registries/
      |── registry.access.redhat.com
      |   └── hosts.toml
      |── mirror.example.com
      |   └── hosts.toml
      └── docker.io
          └── hosts.toml:

      Copy to Clipboard Toggle word wrap

      The following output represents a hosts.toml containerd configuration file where the previous example IDMS object was applied.

      Example host.toml files

      $ cat "$config_path"/registry.access.redhat.com/host.toml
      server = "https://registry.access.redhat.com" # default fallback server since "AllowContactingSource" mirrorSourcePolicy is set
      
      [host."https://example.io/example/ubi-minimal"]
       capabilities = ["pull"]
      
      [host."https://example.com/example2/ubi-minimal"] # secondary mirror
       capabilities = ["pull"]
      
      
      $ cat "$config_path"/registry.redhat.io/host.toml
      # "server" omitted since "NeverContactSource" mirrorSourcePolicy is set
      
      [host."https://mirror.example.com"]
       capabilities = ["pull"]
      
      
      $ cat "$config_path"/docker.io/host.toml
      server = "https://docker.io"
      
      [host."https://docker-mirror.internal"]
       capabilities = ["pull", "resolve"] # resolve tags

      Copy to Clipboard Toggle word wrap

   5. Pull an image to the node from the source and check if it is resolved by the mirror.

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...

      Copy to Clipboard Toggle word wrap