如何打通虚拟化-容器环境并保障流量安全？SmartX VCCI 方案升级！

为了提升资源利用率、交付效率和业务灵活性，不少企业用户都在推进从传统架构向云原生架构的演进，并采用虚拟机与容器共存的混合模式支持多种业务系统。由于两个环境在业务交互层面形成高度耦合，企业需要具备简单、高效方案，实现虚拟机与容器的安全互联互通。不过，常见的虚拟机容器互通方案（网关、控制应用注册地址、扁平网络等）各有利弊，即使是相对更出色的扁平网络方案，也存在网络边界模糊等安全挑战。

为了帮助用户打造安全的虚拟机-容器互联互通环境，SmartX 虚拟化容器融合基础设施（VCCI）方案更新了针对虚拟机与容器的统一安全配置管理能力，确保企业业务互联互通的同时，构建一套高效、可视、可控的安全体系

下载《基于 SmartX 超融合运行 Kubernetes》，了解更多 SmartX VCCI 方案特点、用户实践与场景评测！

虚拟机与容器互通的常见方案及其挑战

我们部署了一个应用，模拟用户真实的业务场景，其中 frontend、gateway、nacos 和 backend 组件运行在 Kubernetes 集群中，并使用 Calico（Overlay 模式）网络插件；rating 服务则运行在虚拟机中，并通过 Nacos 获取地址与 backend 进行业务交互。由于 Kubernetes 采用 Overlay 网络，虚拟机中的 rating（192.168.28.213）服务无法直接与集群内的容器通信（172.16.232.208），导致跨环境互通受限。

为此，企业需要采用合适的技术方案，打通虚拟机与容器的通信壁垒，确保业务稳定运行。目前的主流解决方案包括网关、控制应用注册地址和扁平网络三种。

1. 网关

Kubernetes 集群中的 gateway 服务基于 Spring Cloud Gateway 构建，作为统一网关，通过与 Nacos 交互获取 backend 和 rating 服务的地址，并完成业务逻辑的路由和转发。运行在虚拟机中的 rating 服务则可通过网关作为代理，与 backend 服务进行交互，实现跨环境通信：

对外通过 NodePort、Ingress 等方式暴露 gateway 服务。
将 rating 服务调用 backend 服务的地址调整为 gateway 对外地址 + 对应 path，确保流量经由网关转发。

2. 控制应用注册地址

rating 服务从 Nacos 获取 backend 地址以进行业务交互，但由于 backend 注册的是 Pod 地址（例如 172.16.232.208，Pod CIDR: 172.16.0.0/16），而 rating 运行在 192.168.28.213/20 网段，默认情况下两者网络互通受限，无法直接访问。

此时可通过 NodePort、Ingress 等方式对外暴露 backend 服务，并将暴露的地址注册至 Nacos，替换原先的 Pod 地址。这样，rating 服务便可直接从 Nacos 获取 backend 的外部可访问地址，从而实现业务交互。

3. 扁平网络

通过打通虚拟机与容器网络，构建统一的二层网络，使 backend 和 rating 服务注册的地址互相可达，从而实现业务的无缝互联互通。

三种方案对比如下：

总结

扁平网络方案是目前业界解决虚拟机-容器互联互通的最佳选择：

简单，易落地，维护管理复杂度低，无需业务改造。
由于服务间可直接通信，调用路径最短，排障快，性能最优。
可以实现 VM 与容器的统一安全策略管理，提升整体安全可控性。

然而，扁平网络也带来了安全挑战：容器中的 Pod 可以直接通过 Pod IP 访问，缺乏天然的隔离机制，导致网络边界模糊，增加了潜在的攻击面。如何在实现虚拟机-容器互联互通的同时，构建虚拟机和容器工作负载级别的零信任安全模型呢？

SmartX VCCI 方案新增虚拟机容器统一安全配置管理能力

SmartX VCCI 方案结合零信任安全和微分段策略，有效应对扁平网络带来的安全挑战，实现虚拟机与容器的统一安全管理：

SMTX Kubernetes 服务（SKS）：提供基于扁平网络（EIC 网络插件）的 Kubernetes 集群，确保虚拟机与容器的无缝互通。
软件定义的网络与安全组件 Everoute：

- 分布式防火墙：提供统一的安全策略管理，增强虚拟机与容器的安全隔离与访问控制。

- LB：自动感知 Kubernetes 集群内容器的创建、更新和销毁，并与负载均衡服务联动，为应用的多个副本提供负载均衡能力。

网络流量可视化功能：提供全面的流量监测和行为分析，增强安全可见性，助力异常检测与合规审计

通过以上能力，VCCI 方案在确保虚拟化与容器业务互联互通的同时，构建了一套高效、可视、可控的安全体系。

典型场景

场景一：东西向安全防护（Pod/VM to Pod）

用户可以在 Everoute 中设置，仅允许特定的 VM/Pod 访问目标容器，而拒绝来自其他容器或虚拟机的所有流量。如下图中，仅允许 apigateway 和 rating 服务访问 backend。

场景二：东西向安全防护（Pod/VM to VM）

用户可以在 Everoute 中设置，仅允许特定的 Pod 访问目标虚拟机，而拒绝来自其他容器或虚拟机的所有流量。如下图中，仅允许 apigateway 服务访问 rating 虚拟机。

场景三：南北向安全防护（Pod to IP）

用户可以在 Everoute 中设置，仅允许特定的 Pod 访问信任的目标端，并阻止它对其他网络（如互联网）的访问。如下图中，仅允许 frontend 服务访问 apigateway 和 coredns。

三个场景的操作演示

用户可以在 Everoute 中设置三种策略，实现 Pod/VM to Pod、Pod/VM to VM、Pod to IP 的限定访问。观看视频《Everoute 操作演示：实现虚拟机—容器统一安全策略管理》，了解三种策略设置的操作演示！

用户实践

背景

某头部证券机构基于业务发展与证券行业信创建设的技术演进方向，积极探索自主研发系统的信创实践，以云原生架构构建线上业务中台，支撑网上开户、网上营业厅等核心业务。当前主要面临两大挑战：

在统一技术栈与云原生架构的背景下，一些系统需逐步完成架构升级。然而，部分核心组件无法云原生化，如何在虚拟化与容器混合部署下确保组件间的兼容性与两个环境的统一治理，成为亟待解决的问题。
随着用户增长与业务量激增，一些系统面临响应能力不足、扩展性受限等问题，难以应对高并发与大规模数据处理。为解决性能瓶颈，需升级为更具弹性与扩展性的云原生架构。

基于此，用户希望在尽量降低改造难度与成本投入的情况下，实现虚拟化与容器环境的统一管理与安全互通：

容器与虚拟化应用长期共存，业务紧密关联，需频繁互通，但网络架构复杂，目前亟需可靠的互联互通方案，并实现安全策略的统一配置与管理。
希望在现有硬件资源上同时支持虚拟化和容器，避免额外硬件投入。
期望统一管理容器与虚拟化应用，降低新技术栈的学习成本。

基于 SmartX VCCI 方案，打通虚拟化与容器环境，实现安全互联互通

采用 SmartX VCCI 方案，用户基于一个超融合集群创建虚拟机和 Kubernetes 集群，分别部署虚拟化应用（交易系统）和容器应用（线上业务等）。两个环境通过扁平网络实现互联互通，并通过 Everoute 实现虚拟机与容器安全策略的统一管理。具体方案特点如下：

降低硬件投入：无需购入新的硬件设备，在统一的资源池上同时满足虚拟化和容器化应用的需求，实现硬件资源（如 CPU、GPU、内存、存储和网络）的共享和最大化利用。
利用虚拟化优势：Kubernetes 集群的节点为虚拟机。SmartX 原生虚拟化 ELF 提供的资源动态分配、高可用等机制，可保证节点的可用性和可靠性。同时可以提供集群的快速扩缩容、故障节点自动替换、升级/回滚等特性。
网络安全互通：通过同时支持容器和虚拟机的网络与安全产品及其配套的 EIC 插件，实现容器与外部的扁平化网络连接，也支持在容器和虚拟机级别设置工作负载之间的网络访问策略。
简化运维管理：可以通过一个管理界面对虚拟机、Kubernetes 集群和应用系统进行统一管理与运维。网络流量可视化界面可提供清晰的访问关系与流量信息，便于运维人员查看和操作。