如何打通虛擬化-容器環境并保障流量安全？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 集群和應用系統進行統一管理與運維。網絡流量可視化界面可提供清晰的訪問關系與流量信息，便于運維人員查看和操作。