Publication : 21 novembre 2023
Contributeurs : Stephanie Susnjara, Ian Smalley
La gestion réseau Kubernetes fournit l’infrastructure réseau pour la communication, l’évolutivité, la sécurité et l’accès externe pour les applications conteneurisées. Le réseau est complexe. Il implique la communication entre tous les composants principaux qui résident à l’intérieur (par exemple, les pods, les nœuds, les conteneurs, les services) et à l’extérieur (par exemple, le trafic externe) d’un cluster Kubernetes.
Ces composants s’appuient sur quatre méthodes de gestion réseau distinctes pour communiquer :
1. Gestion réseau de conteneur à conteneur
2. Gestion réseau de pod à pod
3. Gestion réseau de pod à service
4. Gestion réseau de l’extérieur au service
Pour les ingénieurs de plateforme et les ingénieurs DevOps qui cherchent à opérationnaliser la vitesse de mise sur le marché tout en maintenant les performances des applications.
Abonnez-vous à la newsletter IBM
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é présenté au public comme un outil open source en 2014. La même année, Google a fait don de Kubernetes à la Cloud Native Computing Foundation (lien externe à ibm.com), le hub open source indépendant des fournisseurs de l’informatique cloud native. 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é explicitement 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 (par exemple 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 de cloud moderne et de la modernisation des applications. Tous 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 en tant que service (PaaS) et d’infrastructure en tant que service (IaaS). ).
L’architecture Kubernetes inclut 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 : 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 d’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 ou 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 volume de 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 diminution du volume du trafic.
Voici quelques composants Kubernetes supplémentaires :
- Déploiement : dans Kubernetes, la fonction de déploiement gère un ensemble de pods pour exécuter un workload d’application. Un déploiement identifie le nombre de réplicas 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 de code et de maintenir la disponibilité. Les déploiements sont réalisés avec kubectl, l’outil de ligne de commande spécifique 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 API : le serveur API de Kubernetes expose l’API Kubernetes (l’interface utilisée pour gérer, créer et configurer des 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 appareils informatiques ou plus pour partager des données et échanger des ressources, soit par câbles (réseau filaire), soit par Wi-Fi.
Dans la mise en réseau physique, des serveurs physiques sont branchés à des équipements réseau physiques (commutateurs, routeurs et câbles Ethernet) pour se connecter à Internet.
Dans les réseaux virtuels, les réseaux définis par logiciel (SDN), des composants tels que les appareils Ethernet virtuels et les interfaces virtuelles sont installés sur des serveurs nus métal 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’aller plus loin dans la gestion réseau Kubernetes, il convient de passer en revue les termes de base qui y sont associés :
- Hôte réseau : un hôte réseau, c’est tout 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 IP (Internet Protocol) : une adresse IP est un numéro unique attribué à chaque appareil connecté à un réseau qui utilise le protocole Internet pour communiquer. Elle identifie le réseau hôte de l’appareil et l’emplacement de ce dernier 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 les numéros de port pour déterminer l’application, le service ou le processus qui doit recevoir des messages donnés.
- NAT (Network Address Translation) : le NAT transforme les adresses internes ou privées en adresses IP publiques ou globalement routables, pour un accès sécurisé à Internet. Le NAT permet à une adresse IP unique de représenter un groupe entier d’appareils informatiques.
- Agents de nœud : les agents de nœud sont des agents administratifs qui surveillent les serveurs d’applications sur un système hôte et acheminent les requêtes administratives vers les 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/serveur proxy : un proxy fournit une 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 gestion réseau qui permet de relever les défis liés à l’orchestration d’applications conteneurisées dans un environnement distribué. Le runtime de conteneur sur chaque nœud implémente le modèle de réseau et respecte les règles suivantes :
- Chaque pod possède sa propre adresse IP, qui peut être acheminée au sein 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, le NAT n’est pas requis. Tous les pods peuvent communiquer avec tous les autres pods du cluster sans le 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 réseau Kubernetes s’applique à quatre types de communication Kubernetes de base :
Les conteneurs sont 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 via le localhost. Cette communication est possible car 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.
La communication pod à pod comprend la communication entre les pods du même nœud ainsi que la communication 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 résident. De plus, 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.
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 les 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é.
La communication de l’extérieur au service désigne l’exposition des services et l’accès à ces derniers, comme des services externes ou des bases de données, depuis l’extérieur du cluster Kubernetes.
Kubernetes fournit plusieurs services pour faciliter le trafic externe dans un cluster :
- ClusterIP : bien que ClusterIP soit le service Kubernetes par défaut pour les communications internes, le trafic externe peut y accéder via le kube-proxy. ClusterIP peut être 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 le moyen le plus élémentaire pour mettre en place une communication de l’extérieur au service, et il est souvent utilisé à des fins de test, pour tester l’accès public à une application par exemple.
- LoadBalancer : le standard pour la communication de l’extérieur au service, le LoadBalancer expose le service en externe à l’aide de l’équilibreur de charge d’un fournisseur de cloud et lui attribue une adresse IP publique. Le trafic provenant de l’équilibreur de charge externe est ensuite dirigé vers les pods backend.
- ExternalName : un service de nom externe permet d’accéder à un service externe par 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 : un ingress Kubernetes 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 agit comme un pont réseau entre les services Kubernetes et les services externes.
Les stratégies réseau Kubernetes sont une structure d’application qui joue un rôle essentiel dans la gestion réseau Kubernetes. Ces stratégies 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 stratégies réseau sont appliquées via l’API Kubernetes NetworkPolicy et incluent les composants de base suivants :
- Sélecteur de pod : le sélecteur de pod spécifie les pods auxquels la stratégie s’applique en fonction des labels 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. L’isolation est par exemple critique dans les situations multilocataires, quand les DevOps ou d’autres équipes partagent le même cluster Kubernetes, mais travaillent sur différents projets.
Les stratégies 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. Elles peuvent ainsi respecter les normes réglementaires et avoir la garantie que le cluster respecte les politiques de l’organisation.
L’interface CNI est une autre fonctionnalité essentielle liée à la gestion réseau Kubernetes. Créée et gérée par la Cloud Native Computing Foundation et utilisée par Kubernetes et d’autres runtimes 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-ins réseau doivent gérer la mise en réseau des conteneurs. Les plug-ins CNI peuvent attribuer des adresses IP, créer des espaces de noms réseau, configurer des itinéraires réseau, etc. pour permettre la communication de pod à pod, dans le même nœud et entre les nœuds.
Bien que Kubernetes fournisse une interface CNI par défaut, de nombreux plug-ins 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 puisse avoir des fonctionnalités et des approches différentes en matière de gestion réseau, réseaux superposés ou routage direct par exemple, ces plug-ins 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.
Formation interactive sur navigateur pour déployer et exploiter un cluster sur IBM Cloud Kubernetes Service. Aucun téléchargement ni aucune configuration n’est nécessaire.
Déployez des clusters sécurisés et hautement disponibles dans une expérience Kubernetes native.
Avec Red Hat OpenShift on IBM Cloud, les développeurs OpenShift disposent d’un moyen rapide et sécurisé pour conteneuriser et déployer des workloads d’entreprise au sein de clusters Kubernetes.
Plateforme sans serveur entièrement gérée, IBM Cloud Code Engine vous permet d’exécuter votre conteneur, code d’application ou tâche par lots sur un runtime de conteneur entièrement géré.
Développez vos compétences Kubernetes en suivant les cours contenus dans la certification IBM Cloud Professional Developer.
Des étudiants réalisent une exposition artistique avec Red Hat® OpenShift® on IBM® Cloud.
Les conteneurs font partie d’une stratégie de cloud hybride qui vous permet de créer et de gérer des workloads à partir de n’importe quel endroit.
Kubernetes est une plateforme d’orchestration de conteneurs qui permet de planifier et d’automatiser le déploiement, la gestion et le dimensionnement d’applications conteneurisées.
Les conteneurs sont des unités exécutables de logiciels dans lesquels le code d’application est empaqueté avec ses bibliothèques et ses dépendances, de manière standard, afin que le code puisse être exécuté n’importe où.
L’orchestration de conteneurs automatise et simplifie le provisionnement, le déploiement et la gestion des applications conteneurisées.