Comprendre comment fonctionne le réseau sous Kubernetes

Les composants de base

Kubernetes réunit les containers dans des ressources logiques que l’on appelle des pods. Ces pods sont exécutés par des serveurs (physiques ou virtuels), que l’on appelle des nœuds. Une application peut être incarnée par un seul Pod comme par la combinaison de plusieurs pods, lesquels sont exécutés sur différents nœuds. Dans tous les cas, une application est appelée un service. Les nœuds sont regroupés dans un cluster, mais Kubernetes peut gérer plusieurs clusters à la fois. Le propos du réseau sous Kubernetes et de faire coopérer tous ces éléments.

Précisons que Kubernetes n’est pas la seule technologie capable de mettre des containers en réseau. Docker, qui figure le modèle original du format en containers, proposait déjà une couche réseau. Dans celui-ci, chaque application avait son propre réseau privé et chacun de ses pods avait une adresse IP privée sur ce réseau. Lorsque le pod d’une application devait communiquer avec le pod d’une autre application, Docker devait faire office de passerelle, pour translater les adresses IP entre les deux réseaux. Sur Kubernetes, il n’y a plus de translation d’adresses entre applications, car le réseau privé s’étend à l’échelle du cluster. Cela dit, les pods d’une même application sont éventuellement regroupés en sous-réseaux.

Kubernetes supporte deux modes de fonctionnement : « Unified » et « Overlay ». Le mode Unified utilise les pratiques et les protocoles classiques des réseaux Ethernet et IP. Il s’agit de l’approche par défaut, dans laquelle les pods d’une même application sont organisés en sous-réseau, avec des parties similaires entre leurs adresses IP afin d’optimiser les communications au niveau des switches physiques.

L’approche Unified fonctionne bien sur un site. Mais elle complique l’adressage dès lors que les nœuds d’un même cluster sont situés sur des sites différents, a fortiori dans un environnement de type cloud hybride. Pour résoudre ce problème, le mode Overlay fonctionne avec un réseau virtuel privé à cheval entre plusieurs sites.

Le réseau au sein d’un pod 

Tout dans Kubernetes démarre avec un pod. Un pod contient un ou plusieurs containers, voire juste des composants d’une application. Physiquement, un pod est nécessairement hébergé en entier sur un nœud, ce qui signifie que tous les composants logiciels qu’il contient communiquent entre eux, comme ils le feraient sur un serveur classique, en passant par l’adresse logique « localhost ». Cela dit, il n’est pas question pour les composants d’un pod de communiquer ainsi avec les composants d’un autre pod qui se trouverait hébergé sur le même nœud. De fait, Kubernetes aménage dans chacun des pods un container « bridge » qui fournit aux autres composants du même pod un localhost dédié.

Le réseau entre pods

Le container bridge mentionné précédemment est la pile réseau du pod, c’est donc lui qui maintient une adresse IP propre qui va permettre au pod de communiquer avec l’extérieur. L’adresse IP en question est attribuée au moment du déploiement d’une application. Cela signifie que si une application est redéployée, ou dupliquée, ses pods auront chacun une nouvelle adresse IP.

Comme nous l’avons vu plus haut, une application est considérée comme un service. À ce titre, elle possède elle aussi une adresse IP, qui, elle, est fixe. Cette adresse IP est translatée par Kubernetes vers les adresses IP des pods qui composent ce service. Kubernetes assure éventuellement la répartition de charge entre les différentes instances d’une même application.

Le réseau vers les utilisateurs

La dernière pièce du puzzle est la passerelle entre, d’une part, les adresses IP des services et, d’autre part, Internet, ou encore l’adressage IP du reste de l’entreprise. Cette passerelle a deux composants : Ingress, qui gère les accès entrants vers les services, et Egress qui gère les communications en partance des services vers le reste du monde. Tout ce qui a trait à la répartition de charge et à la découverte des services est géré par la partie Ingress.

La fonction de passerelle dans Kubernetes est basique. Elle revient à ce que propose Docker : une translation d’adresses entre le reste du monde et le réseau privé où se situent les services. On pourra la compléter soit avec des « Services Mesh » tiers, en l’occurrence des proxys comme les logiciels Maesh (de Containous), Istio ou Linkerd, soit avec une carte réseau virtuelle tierce qui se greffe à Kubernetes et que l’on appelle une CNI. Cette carte permet de constituer un réseau virtuel pour un cluster.

Il existe différentes façons de configurer le réseau virtuel d’un cluster sous Kubernetes. Il peut s’agir d’un sous réseau intégré au réseau de l’entreprise, ce qui constitue le choix par défaut lorsque tout le réseau, celui de Kubernetes compris, est installé avec les technologies d’un seul fournisseur. Dans ce cas, les pods, potentiellement éparpillés sur différents réseaux physiques, communiquent tous sur le même réseau virtuel que le datacenter avec des protocoles comme VXLAN, qui est universel, ou Flannel, son équivalent expressément conçu pour Kubernetes.

Il peut aussi s’agir d’un réseau privé autonome, qui communique avec le réseau de l’entreprise via une passerelle VPN au niveau de la CNI. L’intérêt de cette option est de séparer un réseau plus ou moins fixe au niveau du datacenter d’un autre très élastique, adapté à un cluster Kubernetes capable d’éponger de forts pics d’activité en démultipliant rapidement les pods et, donc, les répliques d’un service. Dans ce cas, les CNI les plus adaptées sont des solutions comme celles d’Apstra, Big Switch ou Nuage, qui restent suffisamment robustes même lorsque l’on démultiplie à grande échelle le nombre de pods.

Dans ce second cas, si l’ensemble des pods du cluster Kubernetes se trouve hébergé sur un cloud public en particulier, la bonne pratique consiste alors à plutôt opter pour la pile de réseau virtuel du fournisseur de ce cloud public : AWS, Microsoft Azure, Google GCP et IBM proposent des services de réseau virtuel Kubernetes compatibles avec des déploiements en mode hybride, c’est-à-dire avec un accès sécurisé entre le cluster Kubernetes qu’ils hébergent et le datacenter de l’entreprise.

Si l’ensemble des pods réside plutôt sur plusieurs clouds, publics ou privés, dans ce cas, il faudra aller au-delà de la simple pile réseau et opter pour des environnements d’administration globaux, comme on en trouve chez VMware (PKS dans un premier temps, puis ceux du projet Tanzu quand il sera disponible) ou Google, avec Anthos.