At this point, you probably already heard about vSphere Integrated Containers and how it solves many of the challenges with traditional containers management at scale.
One of its key pillars is the implementation of Container-VMs, meaning that for each container you have a corresponding VM, this approach allows us to use vSphere distributed Port groups or NSX Logical Switches to secure and segregate network communication as has never seen before.
Let’s examine what network options are available for VIC.
Public Network
Mandatory: YES
Syntax: --public-network “port_group”
Its main use is to pull container images from registries, like Docker Hub, and enable access to containers services through port mapping.
If not another optional network is specified during VCH creation it will also handle communication from VCH to vCenter and ESXi hosts and Docker API calls from clients creating and managing containers.
Bridged Network
Mandatory: YES
Syntax: --bridge-network “port_group”
It’s the segment where the containers communicate with each other.
If Management network is not specified it will also handle communication between VCH and containers.
If Management network is not specified it will also handle communication between VCH and containers.
Best practice is to use a dedicated segment for each VCH
Management Network
Mandatory: NO
Syntax: --management-network “port_group”
When specified, It will be used by VCH to communicate with vCenter and ESXi and
communication between VCH and containers.
Client Network
Mandatory: No
Syntax: --client-network “port_group”
When specified, it will be used to expose the Docker API service to clients in order to create and manage containers by the clients.
Containers Network
Mandatory: No
Syntax: --container-network “port_group:friendly_name”
When specified, it will expose containers services directly on the network, bypassing the VCH altogether.
That’s a great option which only VIC can provide, avoiding the single point of failure VCH can be, also providing dedicated network bandwidth per container.
Let’s see all the communication possible within this solution.
1 – Developers create containers through the Client network leveraging Docker API calls
2 – VCH pulls image from Docker Hub through the Public network
3 – VCH, through the management network, calls vCenter and ESXi hosts to created Container-VMs
4 – Through the Public network, users access container services by port mapping
5 – Frontend container app access data from the backend database through the use of Bridge network.
6 – Users connect directly to the container's servicesIf you want to learn more about the networking and advanced examples, please, check VIC documentation here.