Qu’est-ce que la gestion réseau Kubernetes ?
La mise en réseau Kubernetes fournit l’infrastructure réseau nécessaire pour faciliter la communication, l’évolutivité, la sécurité et l’accès externe des applications conteneurisées.
Le réseau est complexe et implique une communication entre tous les composants majeurs présents à l’intérieur, tels que les pods, les nœuds, les conteneurs et les services, et à l’extérieur, comme le trafic externe d’un cluster Kubernetes.
Ces composants s’appuient sur quatre méthodes de gestion réseau distinctes pour communiquer :
1. Mise en réseau conteneur à conteneur.
2. Mise en réseau pod à pod.
3. Mise en réseau de pod à service.
4. Mise en réseau de l’extérieur au service
Gardez la tête dans le cloud
Recevez la newsletter hebdomadaire Think pour obtenir des conseils d’experts sur l’optimisation des paramètres multicloud à l’ère de l’IA.
Le nom Kubernetes vient du grec et il signifie timonier ou pilote. Basé sur Borg, la plateforme interne d’orchestration de conteneurs de Google, Kubernetes a été introduit au public comme un outil open source en 2014.
Cette même année, Google a fait don de Kubernetes à la Cloud Native Computing Foundation, le hub open source et indépendant des fournisseurs de l’informatique du cloud natif. Depuis, Kubernetes est devenu l’outil d’orchestration de conteneurs le plus utilisé pour l’exécution des workloads basés sur les conteneurs dans le monde entier.
Kubernetes, également appelé « k8s » ou « kube », a été spécialement conçu pour automatiser la gestion des conteneurs (l’unité logicielle standard qui regroupe le code et toutes ses dépendances). Cet outil d’orchestration est très apprécié pour son fonctionnement rapide et fiable dans n’importe quel environnement d’infrastructure, que ce soit sur site, dans un cloud privé, dans un cloud public ou dans un cloud hybride.
Contrairement aux machines virtuelles (VM), qui virtualisent le matériel physique, les conteneurs virtualisent le système d’exploitation, tel que Linux® ou Windows. Chaque conteneur contient uniquement les bibliothèques et les dépendances de l’application. Comme les conteneurs partagent le même noyau de système d’exploitation que l’hôte, ils sont considérés comme légers, rapides et portables.
Kubernetes et son écosystème de services, de support et d’outils sont devenus la base de l’infrastructure cloud moderne et de la modernisation des applications. Les principaux fournisseurs de cloud, notamment Amazon Web Services (AWS), Google, Microsoft, IBM et Red Hat®, intègrent Kubernetes dans leurs plateformes cloud pour améliorer les capacités de plateforme à la demande (PaaS) et d’infrastructure à la demande (IaaS).
L’architecture Kubernetes comprend les composants fondamentaux suivants :
Un cluster Kubernetes est un ensemble de machines physiques ou virtuelles (nœuds) qui fonctionnent ensemble pour exécuter des applications conteneurisées. Les clusters constituent la base de l’architecture Kubernetes.
Les nœuds maîtres représentent un seul hôte de calcul, à savoir une machine virtuelle ou physique. Ils hébergent les composants du plan de contrôle Kubernetes et sont responsables de la planification et du dimensionnement des applications.
En gérant toutes les ressources de calcul, de réseau et de stockage dans un cluster Kubernetes, le nœud maître garantit que les applications et services conteneurisés sont déployés de manière équilibrée sur les nœuds worker du cluster.
Les nœuds worker sont responsables de l’exécution des conteneurs et de la réalisation de toute tâche affectée par le nœud maître. Ils hébergent également des conteneurs d’applications, regroupés dans des pods.
Les pods sont des groupes d’un ou plusieurs conteneurs, tels que Linux et Docker, qui partagent les mêmes ressources de calcul et de réseau. Ce sont des unités de déploiement de cluster qui fonctionnent également comme des unités d’évolutivité.
Par exemple, si le conteneur d’un pod connaît un trafic élevé, Kubernetes peut répliquer ce pod sur d’autres nœuds du cluster. Kubernetes peut également arrêter les pods en cas de baisse du trafic.
Autres composants Kubernetes :
Déploiement : dans Kubernetes, la fonction de déploiement gère un ensemble de pods pour exécuter une workload d’application. Le déploiement identifie le nombre de répliques d’un pod à exécuter sur le cluster. En cas de défaillance d’un pod, le déploiement en crée un nouveau.
Cette fonctionnalité critique permet d’augmenter le nombre de pods répliqués, de déployer les mises à jour du code et de garantir la disponibilité. Les déploiements sont réalisés avec kubectl, l’outil de ligne de commande de Kubernetes.
Service : un service Kubernetes est une couche d’abstraction qui définit un ensemble logique de pods et l’accès à ces derniers. Un service expose une application réseau s’exécutant sur un ou plusieurs pods d’un cluster. Il fournit un moyen abstrait d’équilibrer la charge des pods.
Serveur d’interface de programmation d’application (API) : le serveur API dans Kubernetes expose l’API Kubernetes (l’interface utilisée pour gérer, créer et configurer les clusters Kubernetes) et sert de point d’entrée pour toutes les commandes et requêtes.
Un réseau informatique de base implique la connexion de deux ou plusieurs appareils informatiques pour partager des données et échanger des ressources, soit par câble (réseau filaire), soit par Wi-Fi.
Dans les réseaux physiques, les serveurs physiques sont reliés à des équipements de réseau physiques tels que les commutateurs, les routeurs et les câbles Ethernet pour se connecter à Internet.
Dans les réseaux virtuels, réseaux définis par logiciel (SDN), des composants tels que les appareils Ethernet virtuels et les interfaces virtuelles sont installés sur des bare metal servers ou des machines virtuelles pour se connecter à Internet. Le déploiement Kubernetes s’appuie sur le SDN pour configurer et gérer la communication réseau entre les clusters.
Avant d'approfondir le fonctionnement du réseau Kubernetes, il est utile de revoir les termes de base du réseau :
Hôte réseau : Un hôte réseau est un ordinateur connecté à un réseau qui fournit des informations, des applications ou des services à d'autres hôtes ou nœuds du réseau.
Adresse de protocole Internet (IP) : Une adresse IP Il s'agit d'un numéro unique attribué à chaque appareil connecté à un réseau utilisant le protocole Internet pour communiquer. Elle identifie le réseau hôte de l’appareil et l’emplacement de l’appareil sur le réseau hôte.
Localhost : Localhost est un nom d’hôte par défaut qui agit comme une adresse IP privée, pointant directement vers l’ordinateur ou l’appareil utilisé.
Port : un port identifie une connexion spécifique entre les périphériques réseau. Chaque port est identifié par un numéro. Les ordinateurs utilisent des numéros de port pour déterminer la application, le service ou le processus qui doit recevoir des messages particuliers.
Traduction d’adresses réseau (NAT) : la NAT transforme les adresses internes ou privées en adresses IP publiques ou pouvant être acheminées globalement, ce qui permet un accès sécurisé à Internet. La NAT permet à une seule adresse IP de représenter un groupe entier de périphériques informatiques.
Agents de nœud : les agents de nœud sont des agents administratifs qui surveillent les serveurs d’application sur un système hôte et acheminent les requêtes administratives vers d’autres serveurs.
Espace de noms réseau : un espace de noms réseau est un ensemble d’interfaces réseau et d’instructions de table de routage qui assure l’isolation entre les périphériques réseau.
Proxy ou serveur proxy : un proxy sert de passerelle entre les utilisateurs et Internet.
Kubernetes a été créé pour exécuter des systèmes distribués avec un plan réseau réparti sur un cluster de machines. En plus de fournir une interconnectivité entre les composants, la gestion réseau des clusters Kubernetes crée un environnement fluide où les données peuvent se déplacer librement et efficacement via un réseau défini par logiciel.
Une autre caractéristique distincte de la gestion réseau Kubernetes, c’est sa structure de réseau plat : tous les composants peuvent se connecter sans dépendre d’aucun autre matériel. Dans Kubernetes, chaque pod d’un cluster peut communiquer avec tous les autres pods, quel que soit le nœud sur lequel il s’exécute. Le réseau plat offre un moyen efficace de partager les ressources et élimine la nécessité d’une allocation dynamique des ports.
Globalement, la gestion réseau Kubernetes élimine la complexité, permettant aux développeurs et aux opérateurs de se concentrer sur la création et la maintenance des applications plutôt que sur la gestion de configurations réseau complexes.
Kubernetes fournit un modèle de mise en réseau qui permet de relever les défis liés à l’orchestration des applications conteneurisées dans un environnement distribué. L’exécution du conteneur sur chaque nœud implémente le modèle réseau et respecte les règles suivantes :
Chaque pod possède sa propre adresse IP, qui peut être routée à l’intérieur du cluster. Cette fonctionnalité élimine la nécessité de créer des liens entre les pods et les ports de mappage.
Étant donné que chaque pod a sa propre adresse IP, la NAT n’est pas requise. Tous les pods peuvent communiquer entre eux au sein du cluster sans la NAT.
Les agents d’un nœud, tels que le kubelet, l’agent de nœud maître qui s’exécute sur chaque nœud, peuvent communiquer avec tous les pods de ce nœud spécifique.
Le modèle de mise en réseau Kubernetes s’applique à 4 types de communication Kubernetes de base :
1. Mise en réseau de conteneur à conteneur
Le conteneur est la plus petite unité d’un réseau Kubernetes. Dans les configurations réseau de base, les conteneurs communiquent au sein d’un seul pod par le biais du localhost.
Cette communication est possible parce que les conteneurs du même pod partagent le même espace de noms réseau, qui comprend des ressources réseau telles que le stockage, l’adresse IP et l’espace de port.
2. Mise en réseau de pod à pod
La communication pod à pod comprend la communication entre les pods du même nœud et celle entre les pods de différents nœuds. Chaque pod d’un cluster Kubernetes possède sa propre adresse IP, ce qui permet une communication directe entre les pods, quel que soit le nœud sur lequel ils sont situés.
Chaque cluster Kubernetes fournit automatiquement un service DNS (Domain Name System), en plus de l’adresse IP du pod. Le service DNS, où les noms sont attribués aux pods et aux services, crée des noms faciles à lire pour les administrateurs et fournit un mécanisme léger pour la découverte des services.
3. Mise en réseau de pod à service
Dans Kubernetes, un service est une abstraction qui définit un ensemble logique de pods et permet l’exposition au trafic externe, l’équilibrage de la charge et la découverte de services sur ces pods. Les services facilitent la communication de pod à service, ainsi que la communication de l’extérieur au service.
Selon le modèle réseau Kubernetes, les adresses IP des pod sont éphémères. Par conséquent, si un pod tombe en panne ou s’il est supprimé et qu’un nouveau pod est créé à sa place, le nouveau pod se verra très probablement attribuer une nouvelle adresse IP.
Dans la communication de pod à service, un ClusterIP est un type de service qui fournit une adresse IP virtuelle stable à un ensemble de pods. Cette adresse IP interne n’est accessible qu’au sein du cluster et peut être utilisée pour les communications internes entre les pods et les services.
Le kube-proxy, installé sur chaque nœud d’un cluster, gère les règles réseau sur l’hôte et surveille les changements dans les services et les pods. Lorsque des pods sont créés ou détruits, le kube-proxy met à jour iptables (un programme utilitaire utilisé pour créer des règles sur le pare-feu du noyau Linux pour le routage du trafic), afin que le trafic envoyé à l’adresse IP du service soit correctement acheminé.
4. Mise en réseau de l’extérieur au service
La mise en relation de l’extérieur au service consiste à exposer des services tels que les services externes et les bases de données, et à y accéder de l’extérieur du cluster Kubernetes.
Kubernetes propose plusieurs services pour faciliter le trafic externe vers un cluster :
ClusterIP : bien que ClusterIP soit le Kubernetes service par défaut pour les communications internes, le trafic externe peut y accéder via le kube-proxy. ClusterIP est utile pour accéder à un service sur un ordinateur portable ou pour déboguer un service.
NodePort : le NodePort expose le service sur un port statique à l’adresse IP de chaque nœud, ce qui rend le service accessible en dehors du cluster. Le NodePort est la méthode la plus simple pour réaliser une mise en réseau externe à service, souvent utilisée à des fins de test (par exemple, pour tester l’accès public à une application).
LoadBalancer : la norme pour la mise en réseau des services externes, exposant le service en externe grâce à l’équilibreur de charge d’un fournisseur de cloud et attribuant au service une adresse IP publique. Le trafic provenant de l’équilibreur de charge externe est ensuite dirigé vers les pods back-end.
ExternalName : un service de noms externe permet d’accéder à un service externe par le nom DNS sans l’exposer dans le cluster DNS. Ce type de service permet de fournir un nom DNS stable aux services externes tels que les services de messagerie non hébergés dans le cluster.
Ingress : Kubernetes ingress est un ensemble de règles de routage relatives à l’accès externe aux services au sein du cluster. L’Ingress Controller est un équilibreur de charge qui sert de pont réseau entre les services Kubernetes et les services externes.
Les politiques réseau Kubernetes constituent une structure d’application qui joue un rôle vital dans le réseau Kubernetes. Ces politiques permettent aux administrateurs et aux développeurs de définir des règles spécifiant la manière dont les pods peuvent communiquer entre eux et avec les autres terminaux du réseau.
Les politiques réseau sont appliquées à l’aide de l’API Kubernetes Network Policies et incluent les composant de base suivants :
Sélecteur de pod : le sélecteur de pod spécifie les pods auxquels la politique s’applique en fonction des étiquettes et des sélecteurs.
Ingress : Ingress définit les règles relatives au trafic entrant vers les pods.
Egress : Egress définit les règles relatives au trafic sortant des pods.
Les stratégies réseau Kubernetes permettent de définir et de gérer des politiques de sécurité via la définition de règles qui contrôlent les pods pouvant communiquer entre eux, empêchant ainsi tout accès non autorisé et toute attaque malveillante.
Les stratégies réseau garantissent également l’isolation entre les pods et les services afin que seuls ces pods ou services puissent communiquer avec un ensemble autorisé de pairs. Par exemple, l’isolation est cruciale dans les situations de multilocataire lorsque les équipes DevOps ou d'autres partagent le même cluster Kubernetes tout en travaillant sur différents projets.
Les politiques réseau permettent aux entreprises ayant des exigences spécifiques en matière de conformité de spécifier et d’appliquer des contrôles d’accès réseau. Cela permet de respecter les normes réglementaires et de s’assurer que le cluster respecte les politiques de l’entreprise.
L’interface CNI (Container Network Interface) est une autre fonctionnalité essentielle liée à la mise en réseau Kubernetes. Créée et gérée par la Cloud Native Computing Foundation et utilisée par Kubernetes et d’autres environnements d’exécution de conteneurs, notamment RedHat OpenShift et Apache Mesos, la CNI est une spécification standardisée et un ensemble d’API qui définissent la façon dont les plug-in réseau doivent gérer la mise en réseau des conteneurs.
Les plug-in CNI peuvent attribuer des adresses IP, créer des espaces de noms réseau, configurer des itinéraires réseau et ainsi de suite, pour permettre la communication de pod à pod, tant au sein du même nœud qu’entre les nœuds.
Bien que Kubernetes fournisse une interface CNI par défaut, de nombreux plug-in CNI tiers, notamment Calico, Flannel et Weave, sont conçus pour gérer la configuration et la sécurité dans les environnements réseau basés sur des conteneurs.
Bien que chacun d’entre eux ait ses propres fonctionnalités et approches en matière de gestion réseau, tels que les réseaux superposés ou le routage direct, ils adhèrent tous aux spécifications CNI compatibles avec Kubernetes.
Si vous souhaitez commencer à utiliser Kubernetes ou développer vos compétences existantes avec Kubernetes et les outils de l’écosystème Kubernetes, essayez l’un de ces tutoriels.
Ressources
IBM Cloud Pak for Network Automation est un Cloud Pak qui automatise et orchestre les opérations d’infrastructure réseau.
Les solutions de mise en réseau cloud d’IBM assurent une connectivité haute performance pour alimenter vos applications et vos activités.
Consolidez le support du centre de données avec IBM Technology Lifecycle Services pour la mise en réseau cloud et plus encore.