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

作者: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中国云原生问卷

Image

Image

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


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

你可能感兴趣的:(cncf,kubernetes,虚拟机,容器)