Qu’est-ce que la gestion de réseau Kubernetes ?

Qu’est-ce qu’un réseau de pods Kubernetes ?

Un réseau de pods Kubernetes connecte plusieurs composants en corrélation :

• Pods : les pods Kubernetes sont inspirés des cosses (pods) ou gousses existant dans la nature (cosses de pois, par exemple). Les pods sont des groupes de conteneurs qui partagent des ressources de réseau et stockage fournies par un même nœud. Ils sont créés avec un serveur d’API et placés par un contrôleur. Une adresse IP est affectée à chaque pod, et tous les conteneurs du pod partagent le même stockage, la même adresse IP et le même espace de port (espace de nommage réseau). 
• Conteneurs : un conteneur Kubernetes est identique à une machine virtuelle qui partage son système d’exploitation entre plusieurs applications. Il comporte ses propres système de fichier, CPU, mémoire et espace de traitement. Les conteneurs sont déjà créés dans les pods, et plusieurs conteneurs peuvent être créés dans un seul pod. Les conteneurs d’un pod se déplacent tous ensemble, sont planifiés ensemble et prennent fin ensemble. Le pod peut se déplacer entre plusieurs Clouds. Les conteneurs peuvent se connecter via des communications réseau à d’autres conteneurs, à un hôte et à des réseaux externes.
• Nœuds : les pods sont toujours exécutés au sein d’un nœud de travail. Les nœuds sont des machines qui exécutent des applications conteneurisées. Kubernetes regroupe ces nœuds en clusters.
• Nœud maître : chaque cluster de nœuds contient au moins un nœud maître qui gère les nœuds de travail. Le maître peut communiquer avec chacun des nœuds d’un cluster ou peut communiquer directement avec n’importe quel pod individuel.

Comment la gestion réseau fonctionne-t-elle dans Kubernetes ?

Les différents composants de la plate-forme Kubernetes (pods, conteneurs, nœuds, applications) utilisent différentes méthodes de gestion du réseau pour communiquer. Il existe une communication de conteneur à conteneur, une communication de pod à pod, une communication de pod à service, et une communication de l’extérieur au service.

La communication de pod à pod constitue le socle de Kubernetes. Les pods communiquent entre eux selon des règles réseau définies par le plug-in réseau, et communiquent avec d’autres pods sans créer explicitement de liens entre eux, ni mettre en correspondance les ports du conteneur au ports de l’hôte. Comme les pods partagent le même espace de nommage réseau et possèdent leurs propres adresses IP, ils peuvent trouver tous les autres pods sur tous les nœuds et communiquer avec eux au moyen de l’hôte local, sans avoir à utiliser la traduction d’adresse réseau (NAT). 

L’une des difficultés de la gestion de réseau Kubernetes consiste à résoudre l’interaction entre le trafic interne (est-ouest) et le trafic externe (nord-sud), puisque le réseau interne est isolé du réseau externe. Toutefois, le trafic qui transite entre les nœuds peut également passer vers et depuis les nœuds et une machine physique ou virtuelle externe. Il existe différentes manières de faire parvenir le trafic externe dans un cluster Kubernetes :

• LoadBalancer : LoadBalancer constitue la manière standard de connecter un service en externe à Internet. Avec ce scénario, un équilibreur de charge réseau transfère tout le trafic externe à un service. Chaque service reçoit sa propre adresse IP.
• ClusterIP : ClusterIP est le service Kubernetes par défaut pour les communications internes. Toutefois, le trafic externe peut accéder au service Kubernetes ClusterIP par défaut par l’intermédiaire d’un proxy. Cela peut s’avérer utile pour déboguer les services ou afficher des tableaux de bord internes. 
• NodePort : NodePort ouvre des ports sur les nœuds ou les machines virtuelles, et le trafic est transféré des ports au service. Principalement utilisé pour les services qui n’ont pas à toujours être disponibles, tels que les applications de démo.
• Ingress : Ingress sert de routeur ou de contrôleur pour acheminer le trafic au services via un équilibreur de charge. Il s’avère utile si vous voulez utiliser une même adresse IP pour présenter plusieurs services.

Un aspect important de la gestion de réseau Kubernetes est l’interface CNI (Container Networking Interface). L’interface CNI connecte les pods dans l’ensemble des nœuds et sert d’interface entre un espace de nommage réseau et un plug-in réseau, ou un fournisseur réseau et un réseau Kubernetes. Vous avez le choix entre de nombreux fournisseurs CNI et de nombreux plug-ins, chacun offrant différentes fonctionnalités. Les plug-in CNI ont la capacité de configurer dynamiquement un réseau et des ressources à mesure de la création et de la suppression des pods. Ils provisionnent et gèrent des adresses IP à mesure de la création et de la suppression des conteneurs. Kubernetes est le fournisseur réseau par défaut pour Kubernetes, mais des plug-in CNI tels que Flannel, Calico, Canal et Weave Net offrent d’autres fonctionnalités.

Mise en œuvre de la gestion de réseau Kubernetes

Les administrateurs réseau disposent d’une vaste palette de méthodes de mise en œuvre du modèle réseau Kubernetes. Gartner a reconnu les exemples de réseau Kubernetes suivants comme « visionnaires » dans son rapport Magic Quadrant for Data Center Networking de 2019 :

• Big Switch Network Big Cloud Fabric : architecture réseau native Cloud qui exécute Kubernetes dans les environnements de Cloud privé.
• Cumulus NetQ : système de validation de fabric par télémétrie qui offre une visibilité sur les déploiements de conteneurs.
• Dell EMC : plate-forme Cloud qui prend en charge les applications traditionnelles et les environnements Cloud avec une prise en charge intégrée de Kubernetes et des conteneurs.
• VMware NSX-T : plate-forme de virtualisation de réseau et de sécurité qui virtualise les réseaux pour les environnements multicloud ou multi-hyperviseur, et notamment les réseaux de conteneurs natifs.