Le modèle réseau de Kubernetes repose sur plusieurs éléments :
Chaque pod d'un cluster reçoit sa propre adresse IP, unique dans tout le cluster.
localhost.Le réseau des pods (aussi appelé réseau du cluster) gère la communication entre les pods. Il garantit que (sauf segmentation réseau volontaire) :
Tous les pods peuvent communiquer avec tous les autres pods, qu'ils soient sur le même nœud ou sur des nœuds différents. Les pods peuvent communiquer entre eux directement, sans proxy ni traduction d'adresses (NAT).
Sous Windows, cette règle ne s'applique pas aux pods qui utilisent le réseau de l'hôte.
Les agents d'un nœud (comme les démons système ou le kubelet) peuvent communiquer avec tous les pods de ce nœud.
L'API Service vous permet de fournir une adresse IP ou un nom d'hôte stable (durable) pour un service mis en œuvre par un ou plusieurs pods backend, alors que les pods qui composent ce service peuvent changer au fil du temps.
Kubernetes gère automatiquement des objets EndpointSlice qui donnent des informations sur les pods qui servent actuellement de backends à un Service.
Une implémentation de proxy de service surveille l'ensemble des objets Service et EndpointSlice, et programme le plan de données pour acheminer le trafic des services vers leurs backends, en utilisant les API du système d'exploitation ou du fournisseur cloud pour intercepter ou réécrire les paquets.
L'API Gateway (ou son prédécesseur, Ingress) vous permet de rendre des Services accessibles à des clients extérieurs au cluster.
type: LoadBalancer de l'API Service,
si vous utilisez un fournisseur de cloud compatible.NetworkPolicy est une API intégrée à Kubernetes qui vous permet de contrôler le trafic entre les pods, ou entre les pods et le monde extérieur.
Dans les anciens systèmes de conteneurs, il n'existait pas de connectivité automatique entre les conteneurs de différents hôtes. Il fallait donc souvent créer explicitement des liens entre les conteneurs, ou faire correspondre les ports des conteneurs à des ports de l'hôte pour que les conteneurs d'autres hôtes puissent les joindre. Ce n'est pas nécessaire dans Kubernetes : dans son modèle, les pods peuvent être traités presque comme des VM ou des hôtes physiques du point de vue de l'allocation des ports, du nommage, de la découverte de services, de l'équilibrage de charge, de la configuration des applications et de la migration.
Seules quelques parties de ce modèle sont mises en œuvre par Kubernetes lui-même. Pour les autres, Kubernetes définit les API, mais la fonctionnalité correspondante est fournie par des composants externes, dont certains sont facultatifs :
La mise en place du namespace réseau des pods est assurée par un logiciel système qui implémente la Container Runtime Interface.
Le réseau des pods lui-même est géré par une implémentation du réseau des pods. Sous Linux, la plupart des environnements d'exécution de conteneurs utilisent la Container Networking Interface (CNI) pour dialoguer avec l'implémentation du réseau des pods. C'est pourquoi ces implémentations sont souvent appelées plugins CNI.
Kubernetes fournit une implémentation par défaut du proxy de service, appelée kube-proxy, mais certaines implémentations du réseau des pods utilisent plutôt leur propre proxy de service, plus étroitement intégré au reste de leur implémentation.
Les NetworkPolicies sont en général aussi mises en œuvre par l'implémentation du réseau des pods. (Certaines implémentations plus simples du réseau des pods ne prennent pas en charge les NetworkPolicies, ou un administrateur peut choisir de configurer le réseau des pods sans elles. Dans ces cas, l'API reste présente, mais elle n'a aucun effet.)
Il existe de nombreuses implémentations de Gateway API, certaines propres à des environnements cloud particuliers, d'autres plutôt orientées vers les environnements « bare metal », et d'autres plus génériques.
Le tutoriel Connecter des applications avec des Services vous permet de découvrir les Services et le réseau de Kubernetes avec un exemple pratique.
Réseau du cluster explique comment mettre en place le réseau de votre cluster, et donne aussi une vue d'ensemble des technologies utilisées.
Pour découvrir des concepts réseau précis, consultez :