For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/en/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/en/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/using-vrack.md.
Skip to content
Appearance
Console(the OVHcloud Console, opens in a new tab)

Using vRack Private Network

View as Markdown

Find out how to integrate an OVHcloud Managed Kubernetes cluster into a vRack private network

Objective

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

By default, the nodes of your Free plan clusters have public IPs. For some use 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.

This guide will cover the integration of OVHcloud Managed Kubernetes clusters into vRack private networks.

Requirements

  • A Public Cloud project in your OVHcloud account

OVHcloud Console Access

  • Direct link:
  • Navigation path: Public Cloud > Select your project > Containers > Managed Kubernetes Service

Instructions

First of all, you will need to set up vRack private network for your Public Cloud. To do it, please follow the Configuring vRack for Public Cloud guide. Once you have created a vRack and added it into a private network, you can continue.

Integrating a cluster into a vRack private network must be done when creating the cluster, in the Network settings section of the Create a Kubernetes cluster page, where you can choose an existing private network and subnet for the cluster.

Your new cluster will be created inside the vRack private network you have chosen.

Once the cluster is created, click its name in the Managed Kubernetes Service list and open its Network tab: it shows the chosen private network.

Custom router and disabled public exposure of nodes and workloads (Standard plan)

On the Standard plan, nodes have no public IP by default: they reach the Internet through an OVHcloud managed gateway, or through Floating IPs set at the node pool level. On Standard clusters created since 13 October 2026, you can go further when creating the cluster, from the OVHcloud API or Terraform (provider 2.23.0 or later; OVHcloud Console and CLI support in progress):

  • disable the public exposure of the nodes and workloads (disablePublicNetworking): no Floating IPs on nodes or load balancers, no public Load Balancers. It works as a guardrail (nothing can be exposed on the Internet by mistake) and can be used alone, with the OVHcloud managed gateway for outbound traffic;
  • use your own router or firewall as the default gateway of the nodes (useUserGateway, which requires disablePublicNetworking), without an OVHcloud managed gateway: your router is the gateway of the nodes subnet.

On every new Standard cluster, the traffic between the nodes and the Kubernetes control plane uses a private path operated by OVHcloud.

The configuration and its limits are described in the guide Using a custom gateway on an OVHcloud Managed Kubernetes cluster.

Known limits

  • All nodes within a Kubernetes cluster with a vRack private network activated are available within that single private network. (No public/private mix, single private network available.)
  • To expose some workloads on the Internet, you can use the External Load Balancers that are now compatible with nodes in vRack. This is not possible on a cluster created with disablePublicNetworking: no public Load Balancer can be created on it.
  • The OVHcloud Public Cloud does not support security groups on vRack.
  • On Free plan clusters, you still see a public IPv4 address on your worker nodes. This IP is not reachable from the Internet and is used exclusively for the administration of your nodes and their link to the Kubernetes control plane. On Standard plan clusters, nodes have no public IP by default (see above).
  • As explained in the Known limits guide, the following subnets are not compliant with the vRack feature and can generate some incoherent behaviours with our overlay networks:
10.2.0.0/16 # Subnet used by pods
10.3.0.0/16 # Subnet used by services
172.17.0.0/16 # Subnet used by the Docker daemon

Go further

  • For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analysed by our experts.

  • Join our community of users.

Was this page helpful?