高可用性--虚拟机的运行策略

作者：Stu Gott

为什么我的虚拟机没有运行？

KubeVirt的API有一个长期存在的困惑。这个问题最近又被提了几次。这种混淆源于VM规范中的“Running”字段，语言是有意义的。从表面上看，“Running”就是“Running”，这很自然，对吧？好吧，没那么快下结论。

规范和状态

KubeVirt对象遵循Kubernetes惯例，因为它们通常有Spec（规范）和Status（状态）节。该规范是用户可配置的，允许用户以声明的方式指示集群所需的状态。同时，状态部分不是用户可配置的，它反映了集群中事物的实际状态。简而言之，用户编辑规范，控制器编辑状态。

回到Running字段上。在这种情况下，Running字段在VM的规范中，换句话说，运行（Running）VM是用户的意图。它不能反映虚拟机的实际运行（Running）状态。

RunStrategy

同样令人困惑的是，上面的内容也有另一方面：“Running”并不总是用户想要的。如果用户登录到一个VM并在客户端关闭它，KubeVirt会尽职地重新生成它！当然，在高可用性用例中，这是完全正确的反应，但在大多数情况下，这只是简单的混淆。关机不是重新启动啊！

我们决定同时解决这两个问题--通过摒弃“Running”字段。如前所述，我们本可以选择一个更好的名字作为开始。通过使用“RunStrategy”这个名称，最终用户应该更清楚地知道他们在请求状态，这当然是完全独立于系统实际提供的状态的。RunStrategy有助于解决命名术语的混淆，但它碰巧也是一个枚举值。因为Running是一个布尔值，它只能为真或假。我们现在能够创建更有意义的状态来适应不同的用例。

目前存在四种运行策略：

• Always：如果一个VM由于任何原因被停止，一个新的实例将被派生。
• RerunOnFailure：如果VM在错误状态下结束执行，将会产生一个新的实例。这就解决了上面所列的第二个问题。如果用户手动停止VM，则不会生成新的实例。
• Manual：这正是它的意思。KubeVirt不会尝试启动或停止VM。为了改变状态，用户必须从API调用start/stop/restart。在virtctl命令行客户端中也有方便的函数。
• Halted：如果VM正在运行，它将被停止，并且将保持关闭状态。

在KubeVirt VM镜像使用模式中给出了一个使用RerunOnFailure运行策略的示例。

高可用性

如果不提到高可用性，对运行策略的讨论就不完整。毕竟，在RerunOnFailure和Always运行策略背后的含义是，VM应该始终可用。在大多数情况下，这是完全正确的，但有一个重要的场景需要注意：如果一个节点完全失败，例如网络或电源丢失。如果没有自动检测节点不再活动的方法，KubeVirt将不知道VM已经失败。在使用启用了MachineHealthCheck（MHC）的IPI（Installer Provisioned Infrastructure）安装的OpenShift集群上，可以检测失败节点并重新安排运行在那里的工作负载。

有关IPI和MHC的模式资料可在此找到：

https://docs.openshift.com/co...

点击阅读网站原文。

---

期待你来填：2020年CNCF中国云原生问卷

问卷链接（https://www.wjx.cn/jq/9714648...）

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。