As enterprises modernize their IT infrastructure, many are turning to cloud-native architectures to optimize resource usage, speed up service delivery, and stay agile. This shift often results in hybrid environments where virtual machines (VMs) and containers coexist — each serving distinct application needs.

However, applications deployed across these two environments are increasingly interconnected, creating new challenges for secure and efficient communication between VMs and containers. Traditional methods like gateways, custom service address registration, and flat network designs offer partial solutions — but each comes with trade-offs. Even flat networks, while simpler, often blur network boundaries and introduce security risks.

To solve this, Arcfra VM-Container Converged Infrastructure (VCCI) solution upgrades its capability and now supports the unified network security policy management of both VMs and containers. This enhanced feature ensures the efficient interoperability between virtualized and containerized applications while boosting the data security, visualization, and O&M simplicity of the entire Arcfra Enterprise Cloud Platform (AECP).

How VMs and Containers Connect: What Works — and What Doesn’t

To simulate real-world business scenarios, we deployed an application consisting of multiple components: the frontend, gateway, Nacos, and backend all run within a Kubernetes cluster utilizing the Calico network plugin in overlay mode. The rating service runs on a VM and interacts with the backend by retrieving its address through Nacos. However, due to the overlay network configuration, the rating service on the VM (IP: 192.168.28.213) cannot directly communicate with the containerized backend service inside the cluster (IP: 172.16.232.208), resulting in limited cross-environment connectivity.

In this case, enterprises need an effective solution to bridge the communication gap between VMs and containers. Common approaches include gateways, static address mapping, and flat networks.

Gateway

The gateway service in the Kubernetes cluster built on Spring Cloud Gateway serves as a unified entry point. It retrieves the addresses of the backend and rating services from Nacos and performs routing and forwarding of business I/O. The rating service, running on a VM, accesses the backend through the gateway as a proxy, enabling cross-environment communication:

• Exposing the gateway service externally through NodePort and Ingress
• Adjusting the address used by the rating service to call the backend service to the gateway’s external address plus the corresponding path, ensuring that traffic is forwarded through the gateway

Custom Service Address Registration

The rating service obtains backend addresses via Nacos for data transmission. However, since the backend registers with its Pod IP (e.g., 172.16.232.208, Pod CIDR: 172.16.0.0/16) and rating resides in the 192.168.28.213/20 subnet, cross-network communication is blocked by default, preventing direct access.

In this case, users can expose the backend service via NodePort or Ingress and register its external endpoint to Nacos to replace the Pod IP. The rating service can then retrieve the accessible address of backend from Nacos, enabling service interactions.

Flat Network

By establishing a unified Layer 2 network between VMs and containers, ​the flat network can achieve seamless communication between the backend and rating services by making the addresses registered by both services mutually reachable, facilitating seamless business interactions.

Comparisons

As can be seen, the flat network is the most effective solution for VM-container interconnectivity:

• Simplified architecture with easy deployment, minimal maintenance, and no need for business transformation.
• Direct service-to-service communication ensures the shortest call path, enabling rapid troubleshooting and optimal performance.
• Unified security management across VMs and containers enhances overall security governance.

However, the flat network approach still has shortcomings. As the Pod in containers can be directly accessed through Pod IP and lacks proper network isolation, this blurs security boundaries and expands attack surfaces. The key challenge lies in enabling seamless VM-container integration while enforcing granular zero-trust security policies at the workload level.

Arcfra VCCI Enhancements: Unified Management of VM and Container Security Policies

Combining Zero Trust principles and micro-segmentation, Arcfra VCCI enhances flat network security and enables unified security management for VMs and containers:

1. Arcfra Kubernetes Engine (AKE): Provide Kubernetes clusters based on flat networking (using CNI plugin), ensuring seamless VM-container communication.

2. Software-defined networking & security — Arcfra Network Service (ANS):

• Distributed Firewall: Allow centralized management of security policies for VMs and containers to enhance isolation and access control across instances.
• Load Balancing (LB): Auto-detect container creation, update, and termination within the Kubernetes cluster, and provide dynamic load balancing services for application’s multiple replicas.

3. Network Visualization: Provide all-around data flow monitoring and behavior analysis with enhanced data visualization, supporting threat detection and compliance auditing.

With these capabilities, Arcfra VCCI solution enables seamless VM-container interconnection while providing an efficient, visible, and manageable network security mechanism.

Use Cases

#1 “East-West Traffic” Security (Pod/VM to Pod)

With ANS, users can allow only specific VMs/Pods to access target containers while blocking data flows from other VMs or containers. Take the chart below as an example, users can restrict backend access to only apigateway and rating service.

#2 “East-West Traffic” Security (Pod/VM to VM)

With ANS, users can allow only specific VMs/Pods to access target VMs while blocking data flows from other VMs or containers. Take the chart below as an example, only apigateway is allowed to access rating VM.

#3 “North-South“ Security

With ANS, users can only allow Pod to access trusted endpoints and restrict it from accessing other networks, like the internet. Take the chart below as an example, frontend service is only allowed to access apigateway and coredns.

Learn more about Arcfra VCCI solution and key features:

Introducing Arcfra VCCI Solution, One Platform for Your VM and Container Workloads

Enhancing Networking Security for Cloud Era: Meet Arcfra Network Service

Effortless Kubernetes Journey: Meet Arcfra Kubernetes Engine