apiVersion: v1
kind: Namespace
metadata:
name: openshift-windows-machine-config-operator (1)
labels:
openshift.io/cluster-monitoring: "true" (2)
在将 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 机器配置操作符的全面先决条件,请参见 Windows 机器配置操作符先决条件。
您可以使用 Web 控制台或 OpenShift CLI (`oc`) 安装 Windows 机器配置操作符。
由于 Windows 操作系统中的限制,E 类别的 `clusterNetwork` CIDR 地址(例如 `240.0.0.0`)与 Windows 节点不兼容。 |
您可以使用 OpenShift Container Platform Web 控制台安装 Windows 机器配置操作符 (WMCO)。
WMCO 管理的 Windows 实例不支持双网卡。 |
在 OpenShift Container Platform Web 控制台中,以**管理员**身份导航到**操作符 → OperatorHub** 页面。
使用**按关键字筛选**框在目录中搜索 `Windows Machine Config Operator`。单击**Windows Machine Config Operator** 磁贴。
查看有关操作符的信息,然后单击**安装**。
在**安装操作符**页面上
选择**稳定**通道作为**更新通道**。**稳定**通道允许安装 WMCO 的最新稳定版本。
**安装模式**已预配置,因为 WMCO 必须仅在一个命名空间中可用。
为 WMCO 选择**已安装的命名空间**。推荐的操作符默认命名空间为 `openshift-windows-machine-config-operator`。
单击**启用命名空间上的操作符推荐集群监控**复选框以启用 WMCO 的集群监控。
选择**批准策略**。
**自动**策略允许操作符生命周期管理器 (OLM) 在有新版本可用时自动更新操作符。
**手动**策略需要具有相应凭据的用户批准操作符更新。
单击**安装**。WMCO 现在列在**已安装的操作符**页面上。
WMCO 将自动安装到您定义的命名空间中,例如 `openshift-windows-machine-config-operator`。 |
验证**状态**是否显示**成功**以确认 WMCO 已成功安装。
您可以使用 OpenShift CLI (`oc`) 安装 Windows 机器配置操作符 (WMCO)。
WMCO 管理的 Windows 实例不支持双网卡。 |
为 WMCO 创建一个命名空间。
为 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 的集群监控是必需的。 |
创建命名空间
$ oc create -f <file-name>.yaml
例如
$ oc create -f wmco-namespace.yaml
为 WMCO 创建操作符组。
创建一个 `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
创建操作符组
$ oc create -f <file-name>.yaml
例如
$ oc create -f wmco-og.yaml
将命名空间订阅到 WMCO。
创建一个 `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 。 |
创建订阅
$ oc create -f <file-name>.yaml
例如
$ oc create -f wmco-sub.yaml
现在已将WMCO安装到openshift-windows-machine-config-operator
。
验证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 (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 Machine Config Operator (WMCO)可以使用并使用集群范围的出站代理配置。
这允许您添加Windows节点并在启用代理的集群中运行工作负载,从而允许您的Windows节点从位于代理服务器后面的注册表中提取镜像,或向集群外部的服务和使用自定义公钥基础设施的服务发出请求。
集群范围的代理仅影响系统组件,而不影响用户工作负载。 |
在启用代理的集群中,WMCO了解为集群设置的NO_PROXY
、HTTP_PROXY
和HTTPS_PROXY
值。WMCO定期检查代理环境变量是否已更改。如果存在差异,WMCO将协调并更新Windows实例上的代理环境变量。
在启用代理的集群中,在Windows节点上创建的Windows工作负载默认情况下不会继承节点的代理设置,与Linux节点相同。此外,默认情况下,在启用代理的集群中,Windows节点上的PowerShell会话不会继承代理设置。
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) 以将镜像拉取请求从源镜像注册表重定向到镜像镜像注册表。
通过 |
具有cluster-admin
角色的用户对集群的访问权限。
通过以下任一方式配置镜像仓库:
设置使用 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 集群以将对源仓库的请求重定向到镜像仓库。
您必须镜像
|
登录到您的 OpenShift Container Platform 集群。
根据需要创建ImageDigestMirrorSet
或ImageTagMirrorSet
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 | 根据拉取类型指示对象的类型
|
3 | 指示镜像拉取方法的类型,任一为:
|
4 | 指示镜像镜像注册表和仓库的名称。 |
5 | 可选:为每个目标仓库指示辅助镜像仓库。如果一个镜像关闭,目标仓库可以使用另一个镜像。 |
6 | 指示注册表和仓库源,这是镜像拉取规范中引用的仓库。 |
7 | 可选:指示如果镜像拉取失败的回退策略
|
创建新对象
$ oc create -f registryrepomirror.yaml
要检查是否应用了镜像配置设置,请在其中一个节点上执行以下操作。
列出您的节点
$ 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
启动调试过程以访问节点
$ 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`
将您的根目录更改为/host
sh-4.2# chroot /host
检查 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 配置文件。
$ 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
从源将镜像拉取到节点,并检查镜像是否已解析。
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 数据以避免节点上的任何数据丢失。
对于需要用户执行 在单节点 OpenShift 集群中,隔离和排出时无法重新安排 pod。但是,这样做可以让 pod(尤其是您的工作负载 pod)有时间正确停止并释放关联的资源。 |
要执行节点的优雅重启,请执行以下操作:
将节点标记为不可调度
$ oc adm cordon <node1>
排出节点以删除所有正在运行的 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
SSH 登录到 Windows 节点并通过运行以下命令进入 PowerShell
C:\> powershell
通过运行以下命令重新启动节点
C:\> Restart-Computer -Force
由于 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"
重启完成后,运行以下命令将节点标记为可调度。
$ oc adm uncordon <node1>
验证节点是否已准备好。
$ oc get node <node1>
NAME STATUS ROLES AGE VERSION
<node1> Ready worker 6d22h v1.18.3+b0068a8