Vue d’ensemble d’un réseau Kubernetes

Effectué

Nœuds

Vous entendrez couramment parler de clusters Kubernetes. À un niveau élevé, les clusters représentent un groupe d’ordinateurs qui travaillent ensemble et partagent des ressources pour améliorer les performances et la disponibilité. Si des ordinateurs du cluster échouent, les services en cours d’exécution sur le cluster peuvent continuer à s’exécuter sur les ordinateurs fonctionnels restants.

Dans Microsoft Azure, ces ordinateurs sont appelés des machines virtuelles. Dans Kubernetes, ces machines virtuelles sont appelées des nœuds.

Les nœuds ont besoin d’une connectivité réseau pour pouvoir communiquer entre eux et router efficacement le trafic réseau. Les nœuds doivent également communiquer avec le plan de contrôle Kubernetes, qui fournit les principaux services Kubernetes et l’orchestration des charges de travail d’application, afin qu’ils puissent exécuter vos ressources de charge de travail d’application.

Diagram that shows the Kubernetes cluster nodes and control plane.

Pods

Dans Kubernetes, les ressources de charge de travail d’application incluent des pods, des déploiements et des ensembles. Les pods sont la plus petite unité déployable dans un cluster Kubernetes. Ils distribués sur vos nœuds de manière à utiliser au mieux les ressources de processeur et de mémoire disponibles sur les nœuds. Les pods représentent généralement une seule instance ou un seul sous-composant de votre application. Un pod peut exécuter un composant de panier d’achat qui gère les articles dans le panier d’un client ou un composant d’expédition qui gère le traitement des commandes terminées.

Vous pouvez exécuter plusieurs copies, ou réplicas, du même pod. Les réplicas se répartissent en plusieurs pods sur les nœuds pour fournir une haute disponibilité. Avec plusieurs réplicas des pods, notre application peut continuer à fonctionner en cas de défaillance d’un composant s’exécutant dans un pod.

Diagram that shows multiple pod replicas running across several Kubernetes cluster nodes.

Avec les fonctionnalités de mise à l’échelle dans Kubernetes, vous pouvez ajouter ou supprimer des pods en réponse au niveau de demande sur le cluster. Les capacités de réparation automatique dans Kubernetes peuvent remplacer n’importe quel pod qui échoue et la prise en charge intégrée des mises à jour propagées automatise le déploiement de nouvelles versions d’une application sans temps d’arrêt.

Les pods reçoivent une nouvelle adresse IP pendant leur déploiement initial. Cette adresse IP est utilisée pour toutes les communications réseau avec le pod. Il existe de nombreux scénarios dans lesquels un pod se voit affecter une nouvelle adresse IP. Lorsque la demande de cluster est élevée et que la mise à l’échelle se produit, de nouveaux pods sont déployés. Lorsque vous mettez à jour une application, de nouveaux pods sont déployés pour remplacer les anciens pods. Si un pod échoue, un nouveau pod le remplace automatiquement. Tous ces scénarios entraînent la création d’adresses IP pour les pods.

Si les adresses IP des pods changent fréquemment, comment Kubernetes sait-il où envoyer le trafic réseau pour atteindre notre application ? La réponse est les services.

Services

Un service Kubernetes se trouve devant un groupe de pods et fournit une adresse IP statique. Le trafic arrivant à un service est distribué selon la méthode du tourniquet (round robin) vers un ensemble de pods back-ends. Le service fait le suivi des modifications apportées aux adresses IP des pods pour garantir que le trafic réseau est envoyé aux pods appropriés.

Diagram that shows multiple pod replicas being served network traffic via a Kubernetes service.