A few weeks ago I talked about vSphere Integrated Containers Networking, what they are used for, syntaxes and how the traffic flows to and from the containers, but they were all from the point of view of vSphere Administrators provisioning virtual container host, VCH.
Developers, on the other hand, are used to create their own networks; for several reasons, like; isolating containers from each other, creating a backend network for some application or just for service discovery outside of the default bridge network, they are called User-Defined Networks.
Another handy feature of user defined network is that it provides an embedded DNS service, which means, containers on this network will be able resolve themselves by name automatically.
Another handy feature of user defined network is that it provides an embedded DNS service, which means, containers on this network will be able resolve themselves by name automatically.
Let’s see how it works:
The standard deployment of VCH comes with a default bridge network;
When we create containers without any specification, it’s connected to the port group backing up the bridge network, which was specified during VCH provisioning, in this case, "backend" and got and IP address from 172.16.0.0/24 address space.
Now, let’s create a user-defined network;
Obs: I’m using --subnet option because I don’t have a DHCP listening on that segment.
This time I will create another container connected to this new user-defined network I just created.
As expected the container is connected to the same port group backing up the bridge network but received an IP address from the range specified during the user-defined network creation (10.10.10.0/24).
My point here is, although they are connected to the same segment (port group) the different address space provides enough segregation between containers.
That’s one of the reasons we recommend a dedicated segment for each VCH bridge network, otherwise diferent users could create additional user-defined networks with the same address space of each other, which might inadvertently allow access to each other containers or cause and IP conflict.
See you next
