作者：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 微信公众号。