Using vRack - Communicating between different private networks

Last updated July 31thth, 2021.

Objective

OVHcloud Managed Kubernetes service provides you Kubernetes clusters without the hassle of installing or operating them.

By default, your Kubernetes clusters will have public IPs. For some uses cases, or for security reasons, you might prefer having your Kubernetes cluster inside a private network.

OVHcloud vRack is a private networking solution that enables our customers to route traffic between OVHcloud dedicated servers as well as other OVHcloud services.

When your Managed Kubernetes and your other services are both in vRack, but in different private networks, some extra configuration is needed. In this document, you will find an explanation of why this extra configuration is needed and how to do it.

The need of extra manual configuration described in this guide is temporary. Our Managed Kubernetes team is working on a more streamlined solution, as explained in this issue in our Public Cloud roadmap.

In this document we suppose that you have some understanding of how to use OVHcloud Managed Kubernetes in the vRack. To get more information on this topic you can look at the Using vRack Private Network guide and Working with vRack example - Managed Kubernetes and Public Cloud instances tutorial.

Networking in Managed Kubernetes inside the vRack

In order to better see why some extra configuration is needed, let's begin by explaining how the OVHcloud Managed Kubernetes integration with vRack private networks is done.

OVHcloud Managed Kubernetes without vRack

Let's have a look at our Managed Kubernetes without vRack. Both the master and the nodes have IP addresses in a network exposed on the internet:

OVHcloud Managed Kubernetes without vRack

All the traffic between the master and the nodes is done using this IP addresses, as are administration traffic and traffic to/from resources external to the cluster.

OVHcloud Managed Kubernetes without vRack

OVHcloud Managed Kubernetes inside vRack

When you put an OVHcloud Managed Kubernetes cluster in a private network in the vRack, a new network interface connected to this private network is added to every node.

OVHcloud Managed Kubernetes inside vRack

Using the addresses and names in the schema, each node has a eth0 network interface to the external network, and a eth1 to the private network. eth0 is dedicated to the communication between nodes and master, to your managed service administration traffic and to communication with external services. Pod to pod traffic, and traffic to the private network is routed through eth1.

In order allow this routing, the default gateway for each node is in the external network, via their eth0 interface, and only the traffic towards the private network is routed through eth1.

OVHcloud Managed Kubernetes inside vRack

For this use case, no additional configuration is needed, you simply have to choose the private network at the creation of your Managed Kubernetes cluster, as explained in the Using vRack Private Network guide and Working with vRack example - Managed Kubernetes and Public Cloud instances tutorial.

Communication between different private networks

In some use cases you don't want to have a single private network, but several ones, while keeping the capacity to communicate between them (one of the strong points of vRack is to allow a transparent communication between your private networks).

This use case currently asks for additional configuration on the OVHcloud Managed Kubernetes cluster side.

The need of extra manual configuration described in this guide is temporary. Our Managed Kubernetes team is working on a more streamlined solution, as explained in this issue in our Public Cloud roadmap.

The problem

The reason is the networking model we have detailed in the precedent point. Let's adapt the precedent schema to make the PCI virtual machine to be in a different private network than the Managed Kubernetes cluster:

Communication between different private networks

As explained before, in order to allow pod to master communication, the default gateway for Managed Kubernetes nodes is in the external network, by eth0, and only the traffic to the private network to which the cluster is attached is routed to eth1.

That means that if in our schema Pod 3 wants to communicate with the PCI vm1, that is in a different private network, the traffic won't get routed to eth1 but to eth0 towards the default gateway, that has no access to vm1, thus the connection fails.

Communication between different private networks

The solution

The solution to this problem is to push the routes to the additional private networks via the DHCP of the private networks. This informs the nodes that traffic to the private networks is to be sent via eth1 instead of eth0:

Communication between different private networks

With this setup, if in our schema Pod 3 wants to communicate with the PCI vm1, that is in a different private network, the traffic is routed to eth1, and thus to vm1:

Communication between different private networks

Go further

Join our community of users.


Did you find this guide useful?

Please feel free to give any suggestions in order to improve this documentation.

Whether your feedback is about images, content, or structure, please share it, so that we can improve it together.

Your support requests will not be processed via this form. To do this, please use the "Create a ticket" form.

Thank you. Your feedback has been received.


These guides might also interest you...

OVHcloud Community

Access your community space. Ask questions, search for information, post content, and interact with other OVHcloud Community members.

Discuss with the OVHcloud community

In accordance with the 2006/112/CE Directive, modified on 01/01/2015, prices incl. VAT may vary according to the customer's country of residence
(by default, the prices displayed are inclusive of the UK VAT in force).