- 实现方式
1.1 添加crd 比如 vmi，用于操作虚拟机实例
1.2 添加controller（控制器） 用于处理非pod以及虚拟机相关的某些流程
1.3 daemon 比如virt-handler 用于保证虚拟机的状态
image.png
为什么不把 libvirtd 和 qumu 独立出来，作为一个通用pod来维护，而是为每一个vmi 单独弄一套？
将虚拟机镜像（qcow2|raw）制作为 docker镜像（基于docker镜像的维护方式来打包），然后在VMI定义中引用该镜像。
在创建虚拟机之前，virt-handler 将镜像从容器中拷贝为本地文件。
在v1版本的基础上官方 意图采用一种新的方式来基于容器的机制对vmi 镜像进行封装。
-
支持虚拟机 probe 以及基本的监控metric
-
关于向后兼容
只有bugfix支持向后兼容: bug fix 首先会合入master分支，如果其他stable分支也存在该问题，需要进行向后兼容（相关代码合并）
发布说明： 必须包括提交的backport
详情描述: backport 的详情描述中必须包含更详细的bug 描述以及bug链接。
CI必须保证可以通过: 包括单元测试以及功能测试。
- 基于replica set 做虚拟机的伸缩
甚至更精细的控制缩掉某台虚拟机。自定义缩容的虚拟机顺序。
甚至支持自动实时的热迁移。
甚至支持优雅删除。
-
支持快照以及基于快照恢复虚拟机。
-
从v0.17版本之后 KubeVirt operator 支持零宕机更新。
实现方式:
在升级过程中，KubeVirt 控制面组件会保证一直可用，保证vm|vmi的创建，删除，更新过程不会被打断。
现有的VMI 负载会被打算。
但是:
迁移动作会失败，VMI仍然可用。 migration失败的原因是virt-handler 升级的过程中，tls 连接中断。
virt-console 以及virt vnc也会中断，因为virt-api作为代理，升级过程中会重启。
关于CRD的多版本支持，目前暂时不会支持。
网友评论