如何轻松统管虚拟化和容器环境？一文了解 SmartX 虚拟化容器融合基础设施

随着越来越多的企业完成应用容器化改造，应用负载的运行环境也变得越来越复杂——近 60% 的企业正在或计划同时采用虚拟化环境和容器环境运行应用系统*，以满足不同业务在性能和敏捷性等方面的不同需求。不过，虚拟化和容器平台通常由不同的厂商提供，对运维人员的能力要求也不尽相同，如何高效地实现两个环境的统一资源编排与管理，同时确保稳态应用所需的性能和高可用性，以及敏态应用所需的灵活性和扩展性？

* 数据参考自《Kubernetes and cloud native operations report 2022》, Juju。

为了更好地支持企业 IT 生产环境中的混合工作负载，SmartX HCI 6.0 基于全栈超融合产品能力，推出了虚拟化容器融合基础设施（VCCI）解决方案，以一套融合架构提供服务器虚拟化、分布式存储、网络与安全、容器管理等组件，帮助用户实现基础设施统一管理、虚拟机容器网络互联互通、应用资源高效统一交付。

欲深入了解基于超融合运行容器的场景和优势，请下载阅读白皮书《基于 SmartX 超融合运行 Kubernetes：场景、功能和优势》。

虚拟化与容器混合工作负载带来的各种挑战

目前，企业内部虽然越来越倾向于以容器化的方式部署新的业务应用（占比约有 75%），但仍有不少应用系统需要运行在虚拟机上。IDC 2024 年《软件定义计算软件市场半年跟踪报告》也表示，到 2028 年，容器基础设施软件市场规模将扩大至 13 亿美元，而虚拟化软件也依旧存在 10 亿市场规模的需求。可以说，企业用户将在未来 3-5 年面对容器与虚拟化环境的共存使用。这一共存需求主要是出于以下三点原因。

由于技术栈和架构问题，用户老旧的业务系统很多时候没有办法完全推倒重来，保持在虚拟化环境中运行是最好的选择。
并非所有的应用都适合运行在容器环境中，比如：
a. 对性能和延迟要求比较高的应用。
b. 业务变更不是很频繁的应用。
c. 容器化后会大大增加运维复杂度的一些有状态应用。
d. 对隔离安全性比较敏感的应用。
e. “先天”适合虚拟机的应用，比如 Gitlab、Harbor 等。
新兴生成式 AI 模型在部分微调和推理场景中，还没有提供比较完善的容器化部署方式。

因此，用户依旧会把部分应用放在虚拟化环境中运行，与容器环境并存。而在对两个环境同时进行管理时，不少运维人员都会感受到“割裂感”：

运维管理的割裂：虚拟化和容器平台通常由不同厂商提供，用户需要使用不同的管理平台，难以对两个环境开展高效、统一的运维管理。同时，虚拟化和容器环境的运维方式也存在差异，要求运维人员同时掌握两个环境的运维知识和技能。
应用交互的割裂：同一应用系统的不同组件可能会分别部署在虚拟化和容器两个环境中，而通常虚拟化与容器环境网络难以互联互通，导致应用组件间无法正常交互，无法满足应用架构需求，用户也难以对虚拟化和容器环境中的网络流量进行更细致的管控（无法像管理虚拟机一样地管理容器）。
资源供给的割裂：传统模式下，虚拟机和容器各自调度需要的计算和存储资源，资源使用率低，交付速度慢。尤其是在 AI 应用场景下，资源需求变化频繁，一些应用也需要使用不同的存储技术来满足多种数据存储需求。这就要求 IT 基础设施能够在两个环境中灵活实现 CPU & GPU 计算资源和存储资源的调度，提升整体资源利用率，同时满足不同数据类型的存储需求。

容器虚拟机融合部署方案及其优劣势

对于这些挑战，主流的解决方案即将容器和虚拟机进行融合部署，由底层基础设施统一提供资源。结合 Gartner《服务器虚拟化市场指南》，目前主流的容器-虚拟机融合技术方案主要有以下几种：

Container-centric（新兴容器虚拟化）：
a. 容器虚拟化（VM in Container）：在 Kubernetes 集群中创建、运行、管理虚拟机，以 KubeVirt 为代表。这种方案下，Kubernetes 部署在裸金属上，用户使用 Kubernetes API 对 Kubernetes 集群上的容器和虚拟机进行统一管理，降低学习成本。
b. 轻量虚拟机容器运行时（Container in Lightweight VM）：符合 OCI 规范的容器运行时，在虚拟机中启动容器，结合了虚拟化技术的优势，使得容器在提供轻量级、快速启动特性的同时，具备更强的安全隔离能力。以 Kata、gVisor、Firecracker 为代表，比较适合 Serverless 场景，并不适合在虚拟机中运行传统应用的场景。
Coexist（传统虚拟化容器）：支持在虚拟化环境中部署、运行、管理容器和虚拟机，以 VMware Tanzu 和 SmartX SKS 为代表。这种方案下，用户部署虚拟化/超融合平台运行虚拟机，Kubernetes 集群构建在其中一部分虚拟机之上，用户通过管理平台对 Kubernetes 集群和虚拟机进行统一管理。

这些方案的具体区别如表格所示：

根据 Gartner《容器技术成熟度曲线报告》，Container-centric 的两种方案仍处于技术起步期，距离成熟的市场应用还有很长（5-10 年）的时间，目前比较适合具备专业技术能力的用户在测试环境使用。而 Coexist 方案不仅基于更成熟的虚拟化/超融合技术，而且具备更高的基础设施融合度、更广泛的高级虚拟化特性和设备支持，以及更稳定可靠的存储能力，因此更适合用户在现阶段采用，以支持生产环境中的虚拟化容器融合部署。

目前，不少容器云厂商、虚拟化/超融合厂商和公有云厂商，都可以提供基于 Coexist 的容器与虚拟机融合部署方案，各方案的特点和对比如下图所示。总体而言，建议用户仔细甄别各个产品的功能特性，选择一款技术成熟、容器-虚拟化环境深度融合、生态开放、简单易用的端到端解决方案。

SmartX 虚拟化容器融合基础设施解决方案

基于 Coexist 技术路线，SmartX 虚拟化容器融合基础设施解决方案（VCCI）帮助企业用户以一套融合架构为虚拟机和容器环境提供统一的支持。VCCI 解决方案由 SmartX 超融合软件 SMTX OS（内置原生虚拟化 ELF 和分布式存储 ZBS）、SMTX Kubernetes 服务、软件定义的网络与安全软件 Everoute，和多集群管理平台 CloudTower 组成，提供完整、可靠、轻量、开放的基础设施能力，帮助用户实现基础设施资源整合与统一管理、虚拟化容器网络互联互通、应用资源高效统一交付。

基础设施统一管理

基于 SmartX 全栈超融合软件所提供的服务器虚拟化、分布式存储、容器管理与网络相关组件，用户可构建完整的虚拟化容器融合基础设施，并通过统一的管理平台进行运维管理，大幅降低运维压力。

虚拟机特性提升容器集群交付速度、弹性与可靠性

虚拟化容器融合基础设施可提升集群交付速度，以分钟级别创建 Kubernetes 集群，无需要提前准备资源、安装操作系统等手工操作。Kubernetes 集群也可弹性扩展，当现有集群资源无法满足应用部署需求时，集群可以自动感知并触发横向节点自动/手动扩缩容。

除了 Kubernetes 自身提供的能力，结合虚拟机特性，整套架构的可靠性也得到进一步增强：

Kubernetes 集群 Control Plane 节点放置在不同超融合物理主机，确保物理机主机故障不会导致同一个 Kubernetes 集群多个 Control Plane 故障而导致集群不可用。
物理机主机故障时 Kubernetes 虚拟机节点支持自动迁移或者在其他健康节点重启。
Kubernetes 虚拟机节点故障时可以手动或者自动替换。
集群滚动升级，升级失败时支持回滚。