你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
在 Azure Red Hat OpenShift (ARO) 群集中使用 Azure 现成虚拟机
本文提供了配置 Azure Red Hat OpenShift 群集 (ARO) 以使用 Azure 现成虚拟机的必要详细信息。
使用 Azure 现成虚拟机,可以利用未使用的容量,大幅降低成本。 每当 Azure 需要回收容量时,Azure 基础结构就会逐出 Azure 现成虚拟机。 有关现成实例的详细信息,请参阅现成虚拟机。
在开始之前,请确保已部署一个 Azure Red Hat Openshift 群集。 如果需要 ARO 群集,请参阅适用于公用群集的 ARO 快速入门,或适用于专用群集的专用群集教程。 配置群集以使用现成 VM 的步骤对于专用和公共群集都是相同的。
ARO 群集应始终至少具有三个是非现成 VM 的工作器节点和三个控制节点。 ARO 群集不能有任何基于现成 VM 的控制节点。
Azure Red Hat Openshift 中的计算机管理是使用 MachineSet 实现的。 MachineSet 资源是计算机组。 MachineSet 之于计算机就如同 ReplicaSet 之于 Pod。 如果需要更多计算机或必须缩减计算机,可以更改计算机集上的“副本”字段以满足计算需求。 有关详细信息,请查看 OpenShift MachineSet 文档
通过在 MachineSet 的模板规范中添加 spotVMOptions
字段来指定使用现成 VM。
为了创建此 MachineSet,我们将:
- 获取在群集上运行的 MachineSet 的副本。
- 创建修改后的 MachineSet 配置。
- 将此 MachineSet 部署到群集
oc login $apiServer -u kubeadmin -p <kubeadmin password>
接下来,列出群集上的 MachineSet。 默认群集上会部署 3 个MachineSet:
oc get machinesets -n openshift-machine-api
下面显示了此命令的示例输出:
NAME DESIRED CURRENT READY AVAILABLE AGE
aro-cluster-5t2dj-worker-eastus1 1 1 1 1 2d22h
aro-cluster-5t2dj-worker-eastus2 1 1 1 1 2d22h
aro-cluster-5t2dj-worker-eastus3 1 1 1 1 2d22h
接下来,描述已部署的 MachineSet。 将 <machineset> 替换为上面列出的 MachineSet 之一,并将其输出到文件中。
oc get machineset <machineset> -n openshift-machine-api -o yaml > spotmachineset.yaml
需要更改 MachineSet 中的以下参数:
metadata.name
spec.selector.matchLabels.machine.openshift.io/cluster-api-machineset
spec.template.metadata.labels.machine.openshift.io/cluster-api-machineset
spec.template.spec.providerSpec.value.spotVMOptions
(添加此字段并将其设置为{}
。)
以下是现成 MachineSet YAML 的简略示例,其中突出显示了在现有工作器 MachineSet 基础上建立新的现成 MachineSet 时需要做出的关键更改,包括一些附加的上下文信息。 (示例不代表完整的可正常运行的 MachineSet;下面省略了许多字段。)
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
name: aro-cluster-abcd1-spot-eastus
spec:
replicas: 2
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: aro-cluster-abcd1
machine.openshift.io/cluster-api-machineset: aro-cluster-abcd1-spot-eastus
template:
metadata:
machine.openshift.io/cluster-api-machineset: aro-cluster-abcd1-spot-eastus
spec:
providerSpec:
value:
spotVMOptions: {}
taints:
- effect: NoExecute
key: spot
value: 'true'
更新文件后,应用该文件。
oc create -f spotmachineset.yaml
若要验证是否已成功创建 MachineSet,请运行以下命令:
oc get machinesets -n openshift-machine-api
下面是示例输出。 计算机进入“就绪”状态后,Machineset 便已准备就绪。
NAME DESIRED CURRENT READY AVAILABLE AGE
aro-cluster-5t2dj-worker-eastus1 1 1 1 1 3d1h
aro-cluster-5t2dj-worker-eastus2 1 1 1 1 3d1h
aro-cluster-5t2dj-worker-eastus3 1 1 1 1 3d1h
spot 1 1 1 1 2m47s
建议向现成节点添加一个排斥 (taint),以防止在其上调度不可中断的节点,并将此排斥的容许添加到你要在其上调度的任何 pod。 可以通过 MachineSet 规范来排斥节点。
例如,可将以下 YAML 添加到 spec.template.spec
:
taints:
- effect: NoExecute
key: spot
value: 'true'
这可以防止在结果节点上调度 pod(除非这些 pod 对于 spot='true'
排斥具有容许),并且会逐出任何缺少该容许的 pod。
若要详细了解如何应用排斥和容许,请阅读使用节点排斥控制 pod 定位。
如果所用计算机类型的配额虽然最终应该足够,但在短时间内太低(例如,在创建一个节点时,另一个节点仍在删除过程中),计算机可能会由于配额问题而进入故障状态。 因此,建议将用于现成实例的计算机类型的配额设置为略高于所需值(也许可以提高 2*n,其中 n 是计算机使用的核心数)。 此项开销可以避免修正有故障的计算机,虽然相对简单,但仍属于人工干预。
如上面链接的现成 VM 文档中所述,当 VM 不再可用或在指定的最高价格亦不再可用时,它们将进入“已解除分配”预配状态。
在 OpenShift 中,这些 VM 本身将显示为“未就绪”节点。 在“预配为节点”阶段,这些计算机将保持正常状态。
VM 再次可用后,它们将恢复“就绪”状态
如果在解除分配某个节点的 VM 后该节点长时间停滞在“未就绪”状态,你可以尝试删除该节点,或删除其对应的 OpenShift 计算机对象。
如果使用现成 VM 的计算机(OpenShift 对象)停滞在“故障”状态,请尝试手动删除该计算机。 如果因 VM 不再存在而出现的 403 错误导致无法删除该计算机,请编辑该计算机并移除终结器。