×

在将 Windows 工作负载添加到集群之前,必须安装 Windows 机器配置操作符 (WMCO),它在 OpenShift Container Platform OperatorHub 中可用。WMCO 可协调在集群上部署和管理 Windows 工作负载的过程。

WMCO 管理的 Windows 实例不支持双网卡。

先决条件

  • 您可以使用具有 `cluster-admin` 权限的帐户访问 OpenShift Container Platform 集群。

  • 您已安装 OpenShift CLI (`oc`)。

  • 您已使用安装程序预配的基础架构安装了集群,或者使用用户预配的基础架构并在 `install-config.yaml` 文件中设置了 `platform: none` 字段。

  • 您已为集群配置了带有 OVN-Kubernetes 的混合网络。有关更多信息,请参见 配置混合网络

  • 您正在运行 OpenShift Container Platform 集群版本 4.6.8 或更高版本。

WMCO 部署的 Windows 实例配置了 containerd 容器运行时。由于 WMCO 安装和管理运行时,因此建议您不要手动在节点上安装 containerd。

其他资源

安装 Windows 机器配置操作符

您可以使用 Web 控制台或 OpenShift CLI (`oc`) 安装 Windows 机器配置操作符。

由于 Windows 操作系统中的限制,E 类别的 `clusterNetwork` CIDR 地址(例如 `240.0.0.0`)与 Windows 节点不兼容。

使用 Web 控制台安装 Windows 机器配置操作符

您可以使用 OpenShift Container Platform Web 控制台安装 Windows 机器配置操作符 (WMCO)。

WMCO 管理的 Windows 实例不支持双网卡。

步骤
  1. 在 OpenShift Container Platform Web 控制台中,以**管理员**身份导航到**操作符 → OperatorHub** 页面。

  2. 使用**按关键字筛选**框在目录中搜索 `Windows Machine Config Operator`。单击**Windows Machine Config Operator** 磁贴。

  3. 查看有关操作符的信息,然后单击**安装**。

  4. 在**安装操作符**页面上

    1. 选择**稳定**通道作为**更新通道**。**稳定**通道允许安装 WMCO 的最新稳定版本。

    2. **安装模式**已预配置,因为 WMCO 必须仅在一个命名空间中可用。

    3. 为 WMCO 选择**已安装的命名空间**。推荐的操作符默认命名空间为 `openshift-windows-machine-config-operator`。

    4. 单击**启用命名空间上的操作符推荐集群监控**复选框以启用 WMCO 的集群监控。

    5. 选择**批准策略**。

      • **自动**策略允许操作符生命周期管理器 (OLM) 在有新版本可用时自动更新操作符。

      • **手动**策略需要具有相应凭据的用户批准操作符更新。

  1. 单击**安装**。WMCO 现在列在**已安装的操作符**页面上。

    WMCO 将自动安装到您定义的命名空间中,例如 `openshift-windows-machine-config-operator`。

  2. 验证**状态**是否显示**成功**以确认 WMCO 已成功安装。

使用 CLI 安装 Windows 机器配置操作符

您可以使用 OpenShift CLI (`oc`) 安装 Windows 机器配置操作符 (WMCO)。

WMCO 管理的 Windows 实例不支持双网卡。

步骤
  1. 为 WMCO 创建一个命名空间。

    1. 为 WMCO 创建一个 `Namespace` 对象 YAML 文件。例如,`wmco-namespace.yaml`

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-windows-machine-config-operator (1)
        labels:
          openshift.io/cluster-monitoring: "true" (2)
      1 建议在 `openshift-windows-machine-config-operator` 命名空间中部署 WMCO。
      2 此标签对于启用 WMCO 的集群监控是必需的。
    2. 创建命名空间

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

      例如

      $ oc create -f wmco-namespace.yaml
  2. 为 WMCO 创建操作符组。

    1. 创建一个 `OperatorGroup` 对象 YAML 文件。例如,`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
    2. 创建操作符组

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

      例如

      $ oc create -f wmco-og.yaml
  3. 将命名空间订阅到 WMCO。

    1. 创建一个 `Subscription` 对象 YAML 文件。例如,`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)
      1 指定 `stable` 作为通道。
      2 设置批准策略。您可以设置 `Automatic` 或 `Manual`。
      3 指定包含windows-machine-config-operator包清单的redhat-operators目录源。如果您的OpenShift Container Platform安装在受限网络(也称为断开连接的集群)上,请指定在配置Operator LifeCycle Manager (OLM)时创建的CatalogSource对象的名称。
      4 目录源的命名空间。对于默认的OperatorHub目录源,请使用openshift-marketplace
    2. 创建订阅

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

      例如

      $ oc create -f wmco-sub.yaml

      现在已将WMCO安装到openshift-windows-machine-config-operator

  4. 验证WMCO安装

    $ oc get csv -n openshift-windows-machine-config-operator
    示例输出
    NAME                                    DISPLAY                           VERSION   REPLACES   PHASE
    windows-machine-config-operator.2.0.0   Windows Machine Config Operator   2.0.0                Succeeded

为Windows Machine Config Operator配置密钥

要运行Windows Machine Config Operator (WMCO),必须在包含私钥的WMCO命名空间中创建一个密钥。这是允许WMCO与Windows虚拟机(VM)通信所必需的。

先决条件
  • 您已使用Operator Lifecycle Manager (OLM)安装了Windows Machine Config Operator (WMCO)。

  • 您创建了一个包含RSA密钥的PEM编码文件。

步骤
  • 定义访问Windows VM所需的密钥

    $ oc create secret generic cloud-private-key --from-file=private-key.pem=${HOME}/.ssh/<key> \
        -n openshift-windows-machine-config-operator (1)
1 必须在WMCO命名空间(例如openshift-windows-machine-config-operator)中创建私钥。

建议使用与安装集群时使用的私钥不同的私钥。

在启用代理的集群中使用Windows容器

在进行集群内部网络外部的外部请求时,Windows Machine Config Operator (WMCO)可以使用并使用集群范围的出站代理配置。

这允许您添加Windows节点并在启用代理的集群中运行工作负载,从而允许您的Windows节点从位于代理服务器后面的注册表中提取镜像,或向集群外部的服务和使用自定义公钥基础设施的服务发出请求。

集群范围的代理仅影响系统组件,而不影响用户工作负载。

在启用代理的集群中,WMCO了解为集群设置的NO_PROXYHTTP_PROXYHTTPS_PROXY值。WMCO定期检查代理环境变量是否已更改。如果存在差异,WMCO将协调并更新Windows实例上的代理环境变量。

在启用代理的集群中,在Windows节点上创建的Windows工作负载默认情况下不会继承节点的代理设置,与Linux节点相同。此外,默认情况下,在启用代理的集群中,Windows节点上的PowerShell会话不会继承代理设置。

其他资源

使用镜像注册表使用Windows容器

Windows Machine Config Operator (WMCO)可以通过使用ImageDigestMirrorSet (IDMS)或ImageTagMirrorSet (ITMS)对象将集群配置为从镜像注册表中提取镜像,而不是从公共注册表中提取镜像。

镜像注册表具有以下优点:

  • 避免公共注册表中断

  • 加快节点和Pod创建速度

  • 从组织防火墙后面提取镜像

镜像注册表也可以与断开连接或隔离的网络中的OpenShift Container Platform集群一起使用。“断开连接的网络”是无直接互联网连接的受限网络。由于集群无法访问互联网,因此无法引用任何外部容器镜像。

使用镜像注册表需要以下一般步骤:

  • 使用Red Hat Quay等工具创建镜像注册表。

  • 创建容器镜像注册表凭据文件。

  • 将镜像从您的在线镜像存储库复制到您的镜像注册表。

有关这些步骤的信息,请参阅“关于断开连接的安装镜像”。

创建镜像注册表并镜像镜像后,您可以使用ImageDigestMirrorSet (IDMS)或ImageTagMirrorSet (ITMS)对象将集群配置为从镜像注册表中提取镜像,而无需更新每个Pod规范。IDMS和ITMS对象将请求重定向到从源镜像注册表上的存储库中提取镜像,并改为由镜像存储库解析。

如果对IDMS或ITMS对象进行了更改,WMCO将自动使用新信息更新Windows节点上的相应hosts.toml文件。请注意,当镜像设置更改时,WMCO会顺序更新每个Windows节点。因此,这些更新所需的时间会随着集群中Windows节点数量的增加而增加。

此外,由于由WMCO配置的Windows节点依赖于containerd容器运行时,因此WMCO确保containerd配置文件与注册表设置保持最新。对于新节点,这些文件将在创建时复制到实例。对于现有节点,在激活镜像注册表后,注册表控制器将使用SSH访问每个节点并复制生成的配置文件,替换任何现有文件。

您可以将镜像注册表与机器集或自带主机(BYOH)Windows节点一起使用。

了解镜像注册表存储库镜像

设置容器注册表存储库镜像使您可以执行以下任务:

  • 将OpenShift Container Platform集群配置为重定向请求以从源镜像注册表上的存储库中提取镜像,并将其由镜像镜像注册表上的存储库解析。

  • 为每个目标存储库识别多个镜像存储库,以确保如果一个镜像关闭,可以使用另一个镜像。

OpenShift Container Platform中的存储库镜像包括以下属性:

  • 镜像提取能够承受注册表停机。

  • 断开连接的环境中的集群可以从关键位置(例如quay.io)提取镜像,并让公司防火墙后面的注册表提供请求的镜像。

  • 发出镜像提取请求时,将尝试特定顺序的注册表,永久注册表通常是最后尝试的一个。

  • 您输入的镜像信息将添加到OpenShift Container Platform集群中每个Windows节点上的相应hosts.toml containerd配置文件中。

  • 当节点向源存储库发出镜像请求时,它将依次尝试每个镜像存储库,直到找到请求的内容。如果所有镜像都失败,集群将尝试源存储库。如果成功,则将镜像拉取到节点。

设置存储库镜像可以通过以下方式完成:

  • 在OpenShift Container Platform安装时

    通过提取OpenShift Container Platform所需的容器镜像,然后将这些镜像置于公司防火墙之后,您可以将OpenShift Container Platform安装到断开连接的环境中的数据中心。

  • OpenShift Container Platform安装后

    如果您在OpenShift Container Platform安装期间未配置镜像,则可以在安装后使用以下任何自定义资源(CR)对象来进行配置:

    • ImageDigestMirrorSet (IDMS)。此对象允许您通过使用摘要规范从镜像注册表中提取镜像。IDMS CR允许您设置回退策略,如果镜像提取失败,则允许或停止继续尝试从源注册表中提取。

    • ImageTagMirrorSet (ITMS)。此对象允许您通过使用镜像标签从镜像注册表中提取镜像。ITMS CR允许您设置回退策略,如果镜像提取失败,则允许或停止继续尝试从源注册表中提取。

每个自定义资源对象都标识以下信息:

  • 您要镜像的容器镜像仓库的来源。

  • 您要为从源仓库请求的内容提供的每个镜像仓库的单独条目。

Windows 机器配置操作员 (WMCO) 会监视 IDMS 和 ITMS 资源的变化,并生成一组hosts.toml containerd 配置文件,每个源注册表一个文件,其中包含这些更改。然后,WMCO 会更新任何现有的 Windows 节点以使用新的注册表配置。

必须在使用镜像注册表添加 Windows 节点之前创建 IDMS 和 ITMS 对象。

配置镜像注册表仓库镜像

您可以创建安装后镜像配置自定义资源 (CR) 以将镜像拉取请求从源镜像注册表重定向到镜像镜像注册表。

通过ImageDigestMirrorSetImageTagMirrorSet对象镜像的 Windows 镜像具有特定的命名要求。镜像镜像的命名空间和镜像名称的最后部分必须与正在镜像的镜像匹配。例如,镜像mcr.microsoft.com/oss/kubernetes/pause:3.9镜像时,镜像镜像必须具有<mirror_registry>/<optional_namespaces>/oss/kubernetes/pause:3.9格式。optional_namespaces可以是任意数量的前导仓库命名空间。

先决条件
  • 具有cluster-admin角色的用户对集群的访问权限。

步骤
  1. 通过以下任一方式配置镜像仓库:

    • 设置使用 Red Hat Quay 的镜像仓库,如Red Hat Quay 仓库镜像中所述。使用 Red Hat Quay 允许您将镜像从一个仓库复制到另一个仓库,并随着时间的推移自动重复同步这些仓库。

    • 使用skopeo之类的工具手动将镜像从源仓库复制到镜像仓库。

      例如,在 Red Hat Enterprise Linux (RHEL) 7 或 RHEL 8 系统上安装 skopeo RPM 包后,可以使用此示例中所示的skopeo命令

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

      在此示例中,您有一个名为example.io的容器镜像注册表,以及一个名为example的镜像仓库,您要将ubi9/ubi-minimal镜像从registry.access.redhat.com复制到该仓库。创建镜像注册表后,您可以配置 OpenShift Container Platform 集群以将对源仓库的请求重定向到镜像仓库。

    您必须镜像mcr.microsoft.com/oss/kubernetes/pause:3.9镜像。例如,您可以使用以下skopeo命令来镜像镜像

    $ skopeo copy \
    docker://mcr.microsoft.com/oss/kubernetes/pause:3.9\
    docker://example.io/oss/kubernetes/pause:3.9
  2. 登录到您的 OpenShift Container Platform 集群。

  3. 根据需要创建ImageDigestMirrorSetImageTagMirrorSet CR,将源和镜像替换为您自己的注册表和仓库对以及镜像

    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
    1 指示要与此 CR 一起使用的 API。这必须是config.openshift.io/v1
    2 根据拉取类型指示对象的类型
    • ImageDigestMirrorSet:拉取摘要引用镜像。

    • ImageTagMirrorSet:拉取标签引用镜像。

    3 指示镜像拉取方法的类型,任一为:
    • imageDigestMirrors:用于ImageDigestMirrorSet CR。

    • imageTagMirrors:用于ImageTagMirrorSet CR。

    4 指示镜像镜像注册表和仓库的名称。
    5 可选:为每个目标仓库指示辅助镜像仓库。如果一个镜像关闭,目标仓库可以使用另一个镜像。
    6 指示注册表和仓库源,这是镜像拉取规范中引用的仓库。
    7 可选:指示如果镜像拉取失败的回退策略
    • AllowContactingSource:允许继续尝试从源仓库拉取镜像。这是默认值。

    • NeverContactSource:阻止继续尝试从源仓库拉取镜像。

  4. 创建新对象

    $ oc create -f registryrepomirror.yaml
  5. 要检查是否应用了镜像配置设置,请在其中一个节点上执行以下操作。

    1. 列出您的节点

      $ oc get node
      示例输出
      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
    2. 启动调试过程以访问节点

      $ oc debug node/ip-10-0-147-35.ec2.internal
      示例输出
      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`
    3. 将您的根目录更改为/host

      sh-4.2# chroot /host
    4. 检查 WMCO 是否为每个 Windows 实例上的每个注册表生成了一个hosts.toml文件。对于之前的示例 IDMS 对象,应该在以下文件结构中存在三个文件

      $ tree $config_path
      示例输出
      C:/k/containerd/registries/
      |── registry.access.redhat.com
      |   └── hosts.toml
      |── mirror.example.com
      |   └── hosts.toml
      └── docker.io
          └── hosts.toml:

      以下输出表示应用了先前示例 IDMS 对象的hosts.toml containerd 配置文件。

      hosts.toml 文件示例
      $ 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
    5. 从源将镜像拉取到节点,并检查镜像是否已解析。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...
仓库镜像故障排除

如果仓库镜像过程未按描述工作,请使用以下关于仓库镜像工作方式的信息来帮助解决问题。

  • 第一个可用的镜像用于提供拉取的镜像。

  • 只有在没有其他镜像可用时才使用主注册表。

  • 从系统上下文来看,Insecure标志用作回退。

优雅地重新启动节点

Windows 机器配置操作员 (WMCO) 会尽可能减少节点重启。但是,某些操作和更新需要重新启动才能确保正确且安全地应用更改。要安全地重新启动 Windows 节点,请使用优雅重启过程。有关优雅地重新启动标准 OpenShift Container Platform 节点的更多信息,请参阅节点文档中的“优雅地重新启动节点”。

重新启动节点之前,建议备份 etcd 数据以避免节点上的任何数据丢失。

对于需要用户执行oc login命令而不是在kubeconfig文件中具有证书来管理集群的单节点 OpenShift 集群,在隔离和排出节点后,oc adm命令可能不可用。这是因为由于隔离,openshift-oauth-apiserver pod 未运行。您可以使用 SSH 访问节点,如下所示。

在单节点 OpenShift 集群中,隔离和排出时无法重新安排 pod。但是,这样做可以让 pod(尤其是您的工作负载 pod)有时间正确停止并释放关联的资源。

步骤

要执行节点的优雅重启,请执行以下操作:

  1. 将节点标记为不可调度

    $ oc adm cordon <node1>
  2. 排出节点以删除所有正在运行的 pod

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force

    您可能会收到错误消息,指出与自定义 pod 中断预算 (PDB) 关联的 pod 无法被驱逐。

    错误示例
    error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

    在这种情况下,请再次运行 drain 命令,并添加disable-eviction标志,该标志将绕过 PDB 检查

    $ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction
  3. SSH 登录到 Windows 节点并通过运行以下命令进入 PowerShell

    C:\> powershell
  4. 通过运行以下命令重新启动节点

    C:\>  Restart-Computer -Force
  5. 由于 EC2 实例元数据路由和主机网络服务 (HNS) 网络之间存在不一致,Amazon Web Services (AWS) 上的 Windows 节点在优雅重启后不会返回READY状态。

    重启后,SSH 登录到 AWS 上的任何 Windows 节点,并通过在 shell 提示符下运行以下命令添加路由

    C:\> route add 169.254.169.254 mask 255.255.255.0 <gateway_ip>

    其中

    169.254.169.254

    指定 EC2 实例元数据端点的地址。

    255.255.255.255

    指定 EC2 实例元数据端点的网络掩码。

    <gateway_ip>

    指定 Windows 实例中网关的相应 IP 地址,您可以通过运行以下命令找到它

    C:\> ipconfig | findstr /C:"Default Gateway"
  6. 重启完成后,运行以下命令将节点标记为可调度。

    $ oc adm uncordon <node1>
  7. 验证节点是否已准备好。

    $ oc get node <node1>
    示例输出
    NAME    STATUS  ROLES    AGE     VERSION
    <node1> Ready   worker   6d22h   v1.18.3+b0068a8