Mise en réseau Kubernetes - Un guide complet des concepts de mise en réseau dans Kubernetes

Dans le blog précédent sur , vous devez avoir une compréhension sur Kubernetes. Dans ce blog sur la mise en réseau Kubernetes, je me concentrerai principalement sur les concepts de mise en réseau impliqués dans Kubernetes.

Dans ce blog sur la mise en réseau Kubernetes, vous comprendrez les sujets suivants:

• Qu'est-ce que Kubernetes?
• Mise en réseau dans Kubernetes
• Cas d'utilisation de Wealth Wizard
• Pratique

Qu'est-ce que Kubernetes?

Vous pouvez définir Kubernetes comme un outil d'orchestration de conteneurs open source qui fournit une plate-forme portable pour automatiser le déploiement d'applications conteneurisées.

Désormais, toute personne travaillant avec Kubernetes doit avoir une compréhension claire du cluster Kubernetes, car cela vous aidera à comprendre le réseau Kubernetes.

Cluster Kubernetes

La plate-forme Kubernetes offre la gestion de l'état souhaité, qui permet aux services de cluster de s'exécuter, la configuration alimentée dans l'infrastructure. Laissez-moi vous expliquer avec un exemple.

Considérez un fichier YAML contenant toutes les informations de configuration qui doivent être introduites dans les services de cluster. Ainsi, ce fichier est transmis à l'API des services de cluster, puis il appartiendra aux services de cluster de déterminer comment planifier des pods dans l'environnement. Donc, supposons qu'il existe deux images de conteneur pour le pod 1 avec trois réplicas et une image de conteneur pour le pod 2 avec deux réplicas, ce sera aux services du cluster d'allouer ces paires pod-réplica aux nœuds de calcul.

exemple de bloc statique en java

Reportez-vous au schéma ci-dessus. À présent, comme vous pouvez le constater, les services de cluster ont attribué au premier worker deux paires de répliques de pod, le deuxième worker avec une seule paire pod-réplica et le troisième worker avec deux paires de répliques de pod. Désormais, c'est le processus Kubelet qui est responsable de la communication des services de cluster avec les workers.

Donc, toute cette configuration de services de cluster et les travailleurs eux-mêmes constituent ce Cluster Kubernetes !!

Comment pensez-vous que ces pods alloués individuellement communiquent entre eux?

La réponse réside dans la mise en réseau Kubernetes!

Abonnez-vous à notre chaîne YouTube pour obtenir de nouvelles mises à jour ..!

Il y a principalement 4 problèmes à résoudre avec les concepts de mise en réseau.

• Communication de conteneur à conteneur
• Communication de pod à pod
• Communication de pod à service
• Communication externe au service

Maintenant, laissez-moi vous dire comment les problèmes ci-dessus sont résolus avec Kubernetes Networking.

Réseau Kubernetes

La communication entre les pods, les services et les services externes à ceux d'un cluster introduit le concept de mise en réseau Kubernetes.

Donc, pour votre meilleure compréhension, permettez-moi de diviser les concepts comme suit.

• Communication des pods et des conteneurs
• Prestations de service
• Connexion externe aux services via le réseau Ingress

Communication des pods et des conteneurs

Avant de vous dire comment les pods communiquent, laissez-moi vous présenter ce que sont les pods?

Pods

Les pods sont des unités de base des applications Kubernetes, qui consistent en un ou plusieurs conteneurs alloués sur le même hôte pour partager une pile réseau et d'autres ressources. Ainsi, cela implique que tous les conteneurs d'un pod peuvent atteindre d'autres sur un hôte local.

Maintenant, permettez-moi de vous expliquer comment ces pods communiquent?

Il existe 2 types de communication. La communication inter-nœuds et le communication intra-nœud.

Commençons donc par la communication intra-nœud, mais avant cela, permettez-moi de vous présenter les composants du réseau de pod.

Intra-nœud sous réseau

Le réseau de pod intra-nœud est essentiellement la communication entre deux nœuds différents sur le même pod. Laissez-moi vous expliquer avec un exemple.

Supposons qu'un paquet passe du pod1 au pod2.

• Le paquet quitte le réseau du pod 1 à eth0 et entre dans le réseau racine à veth0
• Ensuite, le paquet passe sur le pont Linux (cbr0) qui découvre la destination à l'aide d'une requête ARP
• Ainsi, si veth1 a l'adresse IP, le pont sait maintenant où transmettre le paquet.

Maintenant, permettez-moi de vous parler de la communication entre les pods inter-nœuds.

Inter-nœud sous le réseau

Considérez deux nœuds ayant différents espaces de noms réseau, interfaces réseau et un pont Linux.

Maintenant, supposons qu'un paquet voyage de pod1 à un pod4 qui se trouve sur un nœud différent.

• Le paquet quitte le réseau du pod 1 et entre dans le réseau racine à veth0
• Ensuite, le paquet passe au pont Linux (cbr0) dont la responsabilité est de faire une requête ARP pour trouver la destination.
• Une fois que le pont s'est rendu compte que ce pod n'a pas l'adresse de destination, le paquet revient à l'interface réseau principale eth0.
• Le paquet quitte maintenant le nœud 1 pour trouver sa destination sur l’autre nœud et entre dans la table de routage qui achemine le paquet vers le nœud dont le bloc CIDR contient le pod4.
• Donc, maintenant, le paquet atteint node2, puis le pont prend le paquet qui fait une requête ARP pour découvrir que l'IP appartient à veth0.
• Enfin, le paquet traverse la paire de tubes et atteint pod4.

Voilà donc comment les pods communiquent entre eux. Maintenant, passons à autre chose et voyons comment les services aident à la communication des pods.

Alors, que pensez-vous que sont les services?

Prestations de service

Fondamentalement, les services sont un type de ressource qui configure un proxy pour transmettre les demandes à un ensemble de pods, qui recevra le trafic et est déterminé par le sélecteur. Une fois que le service est créé, il a une adresse IP attribuée qui acceptera les demandes sur le port.

Désormais, il existe différents types de services qui vous donnent la possibilité d'exposer un service en dehors de l'adresse IP de votre cluster.

Types de services

Il existe principalement 4 types de services.

ClusterIP: Il s'agit du type de service par défaut qui expose le service sur une adresse IP interne au cluster en rendant le service uniquement accessible au sein du cluster.

NodePort: Cela expose le service sur l’IP de chaque nœud sur un port statique. Depuis un ClusterIP service, vers lequel le service NodePort sera acheminé, est automatiquement créé. Nous pouvons contacter le service NodePort en dehors du cluster.

LoadBalancer: Il s'agit du type de service qui expose le service en externe à l'aide de l'équilibreur de charge d'un fournisseur de cloud. Ainsi, les services NodePort et ClusterIP, vers lesquels l'équilibreur de charge externe sera acheminé, sont automatiquement créés.

Nom externe : Ce type de service mappe le service sur le contenu du externalName champ en renvoyant un CNAME record avec sa valeur.

Donc, les gars, c'était une question de services. Maintenant, vous vous demandez peut-être comment les services externes se connectent-ils à ces réseaux?

Eh bien, c'est par nul autre que Réseau d'entrée .

Réseau d'entrée

Eh bien, le réseau Ingress est le moyen le plus puissant d'exposer les services car il s'agit d'un ensemble de règles autorisant les connexions entrantes, qui peuvent être configurées pour fournir des services en externe via des URL accessibles. Ainsi, il agit essentiellement comme un point d'entrée vers le cluster Kubernetes qui gère l'accès externe aux services dans un cluster.

Maintenant, laissez-moi vous expliquer le fonctionnement d'Ingress Network avec un exemple.

Nous avons 2 nœuds, ayant les espaces de noms de pod et de réseau racine avec un pont Linux. En plus de cela, nous avons également un nouveau périphérique Ethernet virtuel appelé flannel0 (plugin réseau) ajouté au réseau racine.

Maintenant, nous voulons que le paquet circule du pod1 au pod 4.

• Ainsi, le paquet quitte le réseau de pod1 à eth0 et entre dans le réseau racine à veth0.
• Ensuite, il est transmis à cbr0, qui fait la requête ARP pour trouver la destination et il découvre par la suite que personne sur ce nœud n'a l'adresse IP de destination.
• Ainsi, le pont envoie le paquet à flannel0 car la table de routage du nœud est configurée avec flannel0.
• Maintenant, le démon flannel parle au serveur API de Kubernetes pour connaître toutes les adresses IP des pods et leurs nœuds respectifs afin de créer des mappages pour les adresses IP des pods vers les adresses IP des nœuds.
• Le plug-in réseau enveloppe ce paquet dans un paquet UDP avec des en-têtes supplémentaires modifiant les adresses IP source et de destination sur leurs nœuds respectifs et envoie ce paquet via eth0.
• Maintenant, puisque la table de routage sait déjà acheminer le trafic entre les nœuds, elle envoie le paquet au nœud de destination2.
• Le paquet arrive à eth0 du node2 et retourne à flannel0 pour décapsuler et le renvoie dans l'espace de nom du réseau racine.
• Encore une fois, le paquet est transmis au pont Linux pour faire une requête ARP pour découvrir l'adresse IP qui appartient à veth1.
• Le paquet traverse enfin le réseau racine et atteint le Pod4 de destination.

C'est ainsi que les services externes sont connectés à l'aide d'un réseau d'entrée. Maintenant, comme je parlais des plugins réseau, laissez-moi vous présenter la liste des plugins réseau populaires disponibles.

Maintenant que je vous ai tellement parlé de Kubernetes Networking, laissez-moi vous montrer une étude de cas réelle.

Étude de cas: Assistant de richesse utilisant la mise en réseau Kubernetes

Wealth Wizards est une plateforme de planification financière en ligne qui combine la planification financière et une technologie logicielle intelligente pour fournir des conseils d'experts à un coût abordable.

Défis

Désormais, il était extrêmement important pour l'entreprise de découvrir et d'éliminer rapidement les vulnérabilités du code avec une visibilité complète de son environnement cloud, mais souhaitait contrôler le trafic via des restrictions d'accès.

Ainsi, ils ont utilisé l'infrastructure Kubernetes pour gérer le provisionnement et le déploiement des clusters à l'aide d'outils pour gérer le déploiement et la configuration des microservices sur les clusters Kube.

Ils ont également utilisé une fonctionnalité de stratégie réseau de Kubernetes pour leur permettre de contrôler le trafic via des restrictions d'accès.

Maintenant, le problème était que ces politiques sont orientées applications et ne peuvent évoluer qu'avec les applications, mais il n'y avait aucun composant pour appliquer ces politiques.

Ainsi, la seule solution que l'entreprise a pu trouver pour cela était d'utiliser un plugin réseau, et a donc commencé à utiliser Weave Net.

Solution

Ce plug-in réseau crée un réseau virtuel doté d'un contrôleur de stratégie réseau pour gérer et appliquer les règles dans Kubernetes. Non seulement cela, mais il connecte également les conteneurs Docker entre plusieurs hôtes et permet leur découverte automatique.

Supposons donc que vous ayez une charge de travail dans le cluster et que vous souhaitiez arrêter toute autre charge de travail du cluster qui lui communique. Vous pouvez y parvenir en créant une stratégie réseau qui restreint l'accès et autorise uniquement l'entrée via le contrôleur d'entrée sur un port spécifique.

Désormais, avec son déploiement sur chaque nœud Kubernetes, le plugin gère le routage inter-pod et a accès pour manipuler les règles IPtables. En termes simples, chaque stratégie est convertie en un ensemble de règles IPtables, coordonnées et configurées sur chaque machine pour traduire les balises Kubernetes.

D'accord, maintenant que vous avez parcouru tant de théories sur le réseau Kubernetes, laissez-moi vous montrer comment cela se fait en pratique.

Pratique

Donc, en supposant que vous avez tous installé Kubernetes sur vos systèmes, j'ai un scénario à présenter.

Supposons que vous souhaitiez stocker le nom du produit et l'ID de produit, pour cela, vous aurez besoin d'une application Web. Fondamentalement, vous avez besoin d'un conteneur pour l'application Web et vous avez besoin d'un autre conteneur en tant que MySQL pour le backend, et ce conteneur MySQL doit être lié au conteneur d'application Web.

Que diriez-vous d'exécuter pratiquement l'exemple ci-dessus.

Commençons!

Étape 1: Créez un dossier dans le répertoire souhaité et modifiez le chemin du répertoire de travail vers ce dossier.

mkdir HandsOn cd HandsOn /

Étape 2: Créez maintenant des fichiers YAML de déploiement, pour l'application Web et la base de données MySQL.

Étape 3: Une fois que vous avez créé les fichiers de déploiement, déployez les deux applications.

kubectl appliquer -f webapp.yml kubectl appliquer -f mysql.yml

Étape 3.1: Vérifiez les deux déploiements.

kubectl obtenir le déploiement

Étape 4: Maintenant, vous devez créer des services pour les deux applications.

kubectl appliquer -f webservice.yml kubectl appliquer -f sqlservice.yml

Étape 4.1: Une fois les services créés, déployez les services.

Étape 4.2: Vérifiez si les services ont été créés ou non.

kubectl obtenir un service

Étape 5: Maintenant, vérifiez la configuration des pods en cours d'exécution.

kubectl obtenir des pods

Étape 6: Allez dans le conteneur à l'intérieur du pod webapp.

kubectl exec -it id_conteneur bash nano var / www / html / index.php

Étape 6.1 : Maintenant, changez le $ nom_serveur de localhost au nom du service SQL qui est ' webapp-sql1 'Dans ce cas, et $ mot de passe de à ' Edureka ». Remplissez également tous les détails de la base de données requis et enregistrez votre fichier index.php en utilisant le raccourci clavier Ctrl + x et après cette presse Oui pour enregistrer et appuyer sur entrer .

Étape 7: Maintenant, allez dans le conteneur MySQL présent dans le pod.

kubectl l'exécute container_id bash

Étape 7.1: Obtenez l'accès pour utiliser le conteneur MySQL.

mysql -u racine -p edureka

Où -u représente l'utilisateur et -p est le mot de passe de votre machine.

Étape 7.2: Créez une base de données dans MySQL qui sera utilisée pour obtenir des données de webapp.

CRÉER UNE BASE DE DONNÉES Détails du produit

Étape 7.3: Utilisez la base de données créée.

UTILISER les détails du produit

Étape 7.4: Créez une table dans cette base de données dans MySQL qui sera utilisée pour obtenir des données de webapp.

CREATE TABLE produits (nom_produit VARCHAR (10), id_produit VARCHAR (11))

Étape 7.5: Maintenant, quittez également le conteneur MySQL en utilisant la commande sortie .

Étape 8: Vérifiez le numéro de port sur lequel votre application Web fonctionne.

kubectl obtenir des services

Étape 8.1: À présent, ouvrez l’application Web sur le numéro de port qui lui a été attribué.

Étape 9: Une fois que vous cliquez sur Soumettre la requête , allez sur le nœud dans lequel votre service MySQL s'exécute puis allez à l'intérieur du conteneur.

Cela vous montrera la sortie de tous les produits de la liste, dont vous avez rempli les détails.

Si vous avez trouvé ce blog Kubernetes Networking pertinent, consultez le par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier.