Objectif

OVHcloud Managed Kubernetes Service vous fournit des clusters Kubernetes sans que vous ayez à vous soucier de leur installation ou de leur exploitation.

Par défaut, vos clusters Kubernetes disposent d'IP publiques. Pour certains cas d'usage, ou pour des raisons de sécurité, vous pouvez préférer que votre cluster Kubernetes se trouve dans un réseau privé.

Le vRack OVHcloud est une solution de réseau privé qui permet à nos clients d'acheminer le trafic entre des serveurs dédiés OVHcloud, ainsi qu'avec d'autres services OVHcloud.

Lorsque votre Managed Kubernetes et vos autres services sont tous deux dans le vRack, mais dans des réseaux privés différents, une configuration supplémentaire est nécessaire. Ce document explique pourquoi cette configuration supplémentaire est nécessaire et comment la mettre en place.

Dans ce document, nous supposons que vous avez quelques notions sur l'utilisation d'OVHcloud Managed Kubernetes dans le vRack. Pour plus d'informations sur ce sujet, consultez le guide Utiliser un réseau privé vRack et le tutoriel Exemple d'utilisation du vRack - Managed Kubernetes et instances Public Cloud.

Réseau dans Managed Kubernetes au sein du vRack

Pour mieux comprendre pourquoi une configuration supplémentaire est nécessaire, commençons par expliquer comment se fait l'intégration d'OVHcloud Managed Kubernetes avec les réseaux privés vRack.

OVHcloud Managed Kubernetes sans vRack

Examinons notre Managed Kubernetes sans vRack. Le master et les nœuds ont tous deux des adresses IP dans un réseau exposé sur Internet :

Tout le trafic entre le master et les nœuds se fait à l'aide de ces adresses IP, de même que le trafic d'administration et le trafic vers/depuis des ressources situées hors du cluster.

OVHcloud Managed Kubernetes au sein du vRack

Lorsque vous placez un cluster OVHcloud Managed Kubernetes dans un réseau privé au sein du vRack, une nouvelle interface réseau connectée à ce réseau privé est ajoutée à chaque nœud.

En utilisant les adresses et noms du schéma, chaque nœud dispose d'une interface réseau eth0 vers le réseau externe, et d'une interface eth1 vers le réseau privé. eth0 est dédiée à la communication entre les nœuds et le master, au trafic d'administration de votre service managé et à la communication avec les services externes. Le trafic pod à pod, ainsi que le trafic vers le réseau privé, est acheminé via eth1.

Pour permettre ce routage, la passerelle par défaut de chaque nœud se trouve dans le réseau externe, via son interface eth0, et seul le trafic destiné au réseau privé est acheminé via eth1.

Pour ce cas d'usage, aucune configuration supplémentaire n'est nécessaire : il suffit de choisir le réseau privé lors de la création de votre cluster Managed Kubernetes, comme expliqué dans le guide Utiliser un réseau privé vRack et le tutoriel Exemple d'utilisation du vRack - Managed Kubernetes et instances Public Cloud.

Communication entre différents réseaux privés

Dans certains cas d'usage, vous ne souhaitez pas disposer d'un seul réseau privé, mais de plusieurs, tout en conservant la capacité de communiquer entre eux (l'un des points forts du vRack est de permettre une communication transparente entre vos réseaux privés).

Ce cas d'usage nécessite actuellement une configuration supplémentaire côté cluster OVHcloud Managed Kubernetes.

Le problème

La raison en est le modèle réseau que nous avons détaillé au point précédent. Adaptons le schéma précédent pour que la machine virtuelle PCI se trouve dans un réseau privé différent de celui du cluster Managed Kubernetes :

Comme expliqué précédemment, pour permettre la communication entre les pods et le master, la passerelle par défaut des nœuds Managed Kubernetes se trouve dans le réseau externe, via eth0, et seul le trafic vers le réseau privé auquel le cluster est rattaché est acheminé vers eth1.

Cela signifie que si, dans notre schéma, le Pod 3 souhaite communiquer avec la vm1 PCI, qui se trouve dans un réseau privé différent, le trafic ne sera pas acheminé vers eth1 mais vers eth0, en direction de la passerelle par défaut, qui n'a pas accès à vm1 ; la connexion échoue donc.

La solution

La solution à ce problème consiste à transmettre les routes vers les réseaux privés supplémentaires via le DHCP de ces réseaux privés. Cela informe les nœuds que le trafic vers les réseaux privés doit être envoyé via eth1 plutôt que via eth0 :

Avec cette configuration, si dans notre schéma le Pod 3 souhaite communiquer avec la vm1 PCI, qui se trouve dans un réseau privé différent, le trafic est acheminé vers eth1, et donc vers vm1 :

Aller plus loin

• Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

• Échangez avec notre communauté d'utilisateurs.