基于Kubevirt优化虚拟机交付流程，统一资源调度 - 邹能人

个人简介 邹 能 人 资 深 云 原 生 工 程 师 专注于云原生生态系统，特别是在维护Kubernetes、CoreDNS、Istio和Containerd等社区方面积累了丰富的经验。当前工作主要重点是Cloud OS、Kubvirt研发及Runtime等 基于Kubevirt构建VM交付平台的项目背景 虚拟机与容器混合管理方案选型 目录 Kubevirt构建交付虚拟机交付平台的痛点与难点 Kubevirt构建虚拟机交付平台的最佳实践 基于Kubevirt构建二代交付平台的项目背景 基于Kubevirt构建二代交付平台的项目背景 2020年12月，CentOS社区和Red Hat宣布了CentOS停用，集团内部需要切换发行版，目前选择使用AlmaLinux9.1，集团内部VM体系基于2014年社区版OpenStack二次开发而来，近五年主要以维护为主，投入较少，目前主流技术栈基于k8s容器体系，K8s统一管理容器和VM是社区的一个方向 技术趋势 现存VM架构 VM现状 VM存量仍在万级规模，且虚拟机需求长期存在，其中虚拟机镜像基于比较旧的Ubuntu/CentOS，存在安全隐患 目前集团主流技术栈基于k8s容器体系，K8s统一管理容器和VM也是社区的一个重要方向 当前VM架构基于2014年社区版OpenStack二次开发而来，近五年主要以维护为主，投入较少 G O P S全 球 运 维 大 会 暨 研 运 数 智 化 技 术 峰 会2 0 2 4·上 海 站 基于Kubevirt构建二代交付平台的项目背景 Google trends 基于Kubevirt构建二代交付平台的项目背景 AlmaLinux9.1 AlmaLinux是由AlmaLinuxOS Foundation维护的，定位为一个企业级操作系统，具有长时间的支持周期，专门为那些需要稳定性、安全性和高性能的用户设计。AlmaLinux9基于Red Hat Enterprise Linux (RHEL) 9的源代码构建，因此它与RHEL 9完全兼容 优势 1.企业级稳定性：AlmaLinux9延续了CentOS和RHEL的传统，提供企业级的稳定性和性能。 2.开源可控：AlmaLinux是完全开源的，没有任何使用费用。它由社区驱动开发和维护，旨在保持对RHEL的兼容性。3.虚拟化与云原生支持：AlmaLinux9提供了增强的容器化支持，提供对虚拟化平台（如KVM、Xen）的全面支持，以及改进的云原生计算支持 G O P S全 球 运 维 大 会 暨 研 运 数 智 化 技 术 峰 会2 0 2 4·上 海 站 基于Kubevirt构建二代交付平台的项目背景 Cgroup：V2 iptables: 1.8.8(nft) 基于Kubevirt构建二代交付平台的项目背景 虚 拟 机 与 容 器 混 合 管 理 方 案 选 型 虚拟机与容器混合管理方案选型 •服务是虚拟机+ non-k8s•无法容器化的业务、交付效率、技术栈不统一、非云原生等等 虚拟机与容器混合管理方案选型 云原生生态 VM全生命周期 Runtime化VM能够以Runtime方式去管理 技术方案在云原生生态需要生产就绪且具备一定的成熟度 技术方案能够同时支持linux及windows，并能提供完整的生命周期管理 虚拟机与容器混合管理方案选型 虚拟机与容器混合管理方案选型 K u b e v i r t构 建 交 付 虚 拟 机 交 付 平台 的 痛 点 与 难 点 K u b e v i r t构 建 交 付 虚 拟 机 交 付 平 台 的 痛 点 与 难 点 Kubernetes 1. K8s 1.28的适配与问题修复等2. Docker配置兼容与优化问题3. VM固定宿主机调度等 Almalinux Kubevirt 1.Kubevirt部署工艺改造2.Kubevirt镜像管理3.Kubevirt存储管理4.KubevirtIO隔离 1.Systemd版本变动2.cgroupv1与v2的切换3. Linux内核的选择等 K u b e v i r t构 建 交 付 虚 拟 机 交 付 平 台 的 痛 点 与 难 点 K u b e v i r t构 建 交 付 虚 拟 机 交 付 平 台 的 痛 点 与 难 点 K u b e v i r t构 建 交 付 虚 拟 机 交 付 平 台 的 痛 点 与 难 点 01.工艺优化 02.镜像管理 1.vm的镜像以何种方式交付？2.vm的镜像存储的模式？3. window这种大镜像又该如何处理？ 1.社区提供operator模式进行部署，但灵活性与稳定性难以保障，同时与内部发布系统存在差异2.vm的调度是否能够与Pod一样漂移，IP如何管理？3.vm的交付模式？ 03.存储管理 04.IO隔离 1.vm系统数据如何存储？2.vm数据盘如何选型？3.vm数据盘扩展如何实现？4.vm数据如何迁移？ Kubevirt构建虚拟机交付平台的最佳实践 Kubevirt构建虚拟机交付平台的最佳实践 Kubevirt构建虚拟机交付平台的最佳实践 工艺优化 社区提供operator模式进行部署，但灵活性与稳定性难以保障，同时与内部发布系统存在差异，通过kustomize编排各组件 01 内部期望vm的调度后可以与node绑定，且IP提供预留能力，我们内部基于scheduler-plugins实现固定宿主机调度 02 在当前vm的交付延用mario工作流平台，vm的交付中间流程正在迁移至airflow，以便提升交付效率03 Kubevirt构建虚拟机交付平台的最佳实践 Kubevirt构建虚拟机交付平台的最佳实践 系统数据存储 数据盘扩展 数据盘选型 原生HostDisk支持扩展，但只限于PV等模式，本地存储模式扩展，需要调整扩展中计算及存储逻辑，实现在线及离线扩盘，另外1.0与1.1版本一行代码之差 数据盘选择HostDisk模式，将Img格式调整为Qemu增量，通过HostPath模式挂载到协议目录，达到数据留存 需要vm关机，可以在同步完协议目标的系统增量盘及HostDisk之后，调整vm对象，修改目标节点，启动即可 Kubevirt构建虚拟机交付平台的最佳实践 Kubevirt构建虚拟机交付平台的最佳实践 IO隔离限制 优点：NRI插件机制，在containerd中发生pod/container事件时，通过plugin方式执行到NRI注册的hook，进行自定义处理 01 containerd会将pod/container labels/annotations/...等等信息传给NRI plugin，一般场景下这些信息足够了，因此NRI就不需要与k8s有任何交互 02 缺点：NRI插件只能接受增量需求，因为Pod update事件无法传递 01 T h a n k s 荣誉出品