关于cncf:高可用性虚拟机的运行策略

44次阅读

共计 1554 个字符,预计需要花费 4 分钟才能阅读完成。

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

正文完
 0