In de vorige blog over , moet u kennis hebben van Kubernetes. In deze blog over Kubernetes-netwerken, zal ik me vooral richten op de netwerkconcepten die bij Kubernetes komen kijken.
In deze blog over Kubernetes-netwerken begrijpt u de volgende onderwerpen:
Wat is Kubernetes?
U kunt Kubernetes definiëren als een open-source tool voor het indelen van containers die een draagbaar platform biedt voor het automatiseren van de implementatie van gecontaineriseerde applicaties.
Iedereen die met Kubernetes werkt, moet een duidelijk begrip hebben van Kubernetes Cluster, omdat dit u zal helpen om Kubernetes Networking te begrijpen.
Kubernetes-cluster
Het Kubernetes-platform biedt het gewenste statusbeheer, waardoor de clusterservices kunnen worden uitgevoerd, de gevoede configuratie in de infrastructuur. Ik zal het uitleggen met een voorbeeld.
Beschouw een YAML-bestand dat alle configuratie-informatie bevat die in de clusterservices moet worden ingevoerd. Dit bestand wordt dus naar de API van clusterservices gestuurd en vervolgens is het aan de clusterservices om uit te zoeken hoe pods in de omgeving kunnen worden gepland. Stel dat er twee containerinstallatiekopieën zijn voor pod 1 met drie replica's en één containerinstallatiekopie voor pod 2 met twee replica's, dan is het aan de clusterservices om deze pod-replicaparen aan de werkrollen toe te wijzen.
voorwaarden voor de cursus kunstmatige intelligentie
Raadpleeg het bovenstaande diagram. Zoals u kunt zien, hebben de clusterservices de eerste worker met twee pod-replicaparen toegewezen, de tweede worker met één pod-replica-paar en de derde worker met twee pod-replicaparen. Nu is het Kubelet-proces verantwoordelijk voor de communicatie van de clusterservices met werknemers.
Dus deze hele opzet van clusterdiensten en de werknemers zelf vormen dit Kubernetes-cluster !!
Hoe denk je dat deze individueel toegewezen pods met elkaar communiceren?
Het antwoord ligt in Kubernetes Networking!
Abonneer je op ons YouTube-kanaal om nieuwe updates te ontvangen ..!
Er zijn hoofdzakelijk 4 problemen die moeten worden opgelost met de netwerkconcepten.
- Container naar container communicatie
- Pod to pod Communicatie
- Pod om communicatie te onderhouden
- Externe communicatie
Laat me u nu vertellen hoe de bovenstaande problemen worden opgelost met Kubernetes Networking.
Kubernetes-netwerken
De communicatie tussen pods, services en externe services naar degenen in een cluster brengt het concept van Kubernetes-netwerken met zich mee.
Dus, voor een beter begrip, laat me de concepten in het volgende verdelen.
- Pods & Container Communicatie
- Diensten
- Extern verbinding maken met services via Ingress Network
Pods & Container Communicatie
Voordat ik je vertel hoe pods communiceren, wil ik je voorstellen wat zijn pods?
Peulen
Pods zijn basiseenheden van Kubernetes-applicaties, die bestaan uit een of meer containers die op dezelfde host zijn toegewezen om een netwerkstack en andere bronnen te delen. Dit houdt dus in dat alle containers in een pod andere containers op een lokale host kunnen bereiken.
Laat me u nu vertellen hoe deze pods communiceren?
Er zijn 2 soorten communicatie. De communicatie tussen knooppunten en de intra-node communicatie.
Laten we dus beginnen met intra-node-communicatie, maar laat me eerst de componenten van het pod-netwerk aan u voorstellen.
Intra-node onder netwerk
Intra-node pod-netwerk is in feite de communicatie tussen twee verschillende knooppunten op dezelfde pod. Ik zal je een voorbeeld geven.
Stel dat een pakket van pod1 naar pod2 gaat.
- Het pakket verlaat het netwerk van Pod 1 op eth0 en komt het rootnetwerk binnen op veth0
- Vervolgens gaat het pakket naar de Linux-brug (cbr0) die de bestemming ontdekt met behulp van een ARP-verzoek
- Dus als veth1 het IP-adres heeft, weet de bridge nu waar het pakket naartoe moet worden gestuurd.
Laat me u nu op dezelfde manier vertellen over de communicatie tussen de knooppunten.
Geïnteresseerd in het leren van Kubernetes?Interknooppunt onder het netwerk
Overweeg twee knooppunten met verschillende netwerknaamruimten, netwerkinterfaces en een Linux-bridge.
Stel nu dat een pakket van pod1 naar een pod4 gaat die zich op een ander knooppunt bevindt.
- Het pakket verlaat het pod 1-netwerk en komt het root-netwerk binnen op veth0
- Vervolgens gaat het pakket door naar de Linux-bridge (cbr0) wiens verantwoordelijkheid het is om een ARP-verzoek in te dienen om de bestemming te vinden.
- Nadat de bridge zich realiseert dat deze pod niet het bestemmingsadres heeft, keert het pakket terug naar de hoofdnetwerkinterface eth0.
- Het pakket verlaat nu knooppunt 1 om zijn bestemming op het andere knooppunt te vinden en gaat de routetabel binnen die het pakket routeert naar het knooppunt waarvan het CIDR-blok de pod4 bevat.
- Dus nu bereikt het pakket node2 en dan pakt de bridge het pakket dat een ARP-verzoek doet om erachter te komen dat het IP-adres van veth0.
- Ten slotte kruist het pakket het buizenpaar en bereikt het pod4.
Zo communiceren pods met elkaar. Laten we nu verder gaan en kijken hoe services helpen bij de communicatie van pods.
Dus, wat denkt u dat de services zijn?
Diensten
In feite zijn services een type resource dat een proxy configureert om de verzoeken door te sturen naar een set pods, die verkeer zullen ontvangen en wordt bepaald door de selector. Zodra de service is gemaakt, heeft deze een toegewezen IP-adres dat verzoeken op de poort accepteert.
Nu zijn er verschillende servicetypen die u de mogelijkheid bieden om een service buiten uw cluster-IP-adres te tonen.
Soorten services
Er zijn hoofdzakelijk 4 soorten diensten.
ClusterIP: Dit is het standaard servicetype waarmee de service op een cluster-intern IP-adres wordt weergegeven door de service alleen binnen het cluster bereikbaar te maken.
NodePort: Dit stelt de service bloot op het IP-adres van elk knooppunt op een statische poort. Sinds een ClusterIP service, waarnaar de NodePort-service zal routeren, automatisch gemaakt. Buiten het cluster kunnen we contact opnemen met de NodePort-service.
LoadBalancer: Dit is het servicetype dat de service extern blootstelt met behulp van de load balancer van een cloudprovider. De NodePort- en ClusterIP-services waarnaar de externe load balancer zal routeren, worden dus automatisch gemaakt.
ExternalName : Dit servicetype wijst de service toe aan de inhoud van het externalName veld door een CNAME record met zijn waarde.
Dus jongens, dat was alles over diensten. Nu vraagt u zich misschien af hoe externe services verbinding maken met deze netwerken, toch?
Nou, dat is door niemand minder dan Ingress-netwerk .
Ingress-netwerk
Welnu, het Ingress-netwerk is de krachtigste manier om services te tonen, aangezien het een verzameling regels is die inkomende verbindingen mogelijk maken, die kunnen worden geconfigureerd om extern services te verlenen via bereikbare URL's. Het fungeert dus in feite als een toegangspunt tot het Kubernetes-cluster dat externe toegang tot de services in een cluster beheert.
Laat me je nu de werking van Ingress Network uitleggen met een voorbeeld.
We hebben 2 knooppunten, met de naamruimten van de pod en het rootnetwerk met een Linux-bridge. Daarnaast hebben we ook een nieuw virtueel ethernet-apparaat genaamd flannel0 (netwerkplug-in) toegevoegd aan het root-netwerk.
Nu willen we dat het pakket van pod1 naar pod 4 stroomt.
- Het pakket verlaat dus het netwerk van pod1 op eth0 en gaat het root-netwerk binnen op veth0.
- Vervolgens wordt het doorgegeven aan cbr0, die de ARP-aanvraag doet om de bestemming te vinden en daarna ontdekt dat niemand op dit knooppunt het IP-adres van de bestemming heeft.
- Dus de bridge stuurt het pakket naar flannel0 terwijl de routetabel van de node is geconfigureerd met flannel0.
- Nu praat de flaneldaemon met de API-server van Kubernetes om alle pod-IP's en hun respectieve knooppunten te kennen om toewijzingen te maken voor pods-IP's naar knoop-IP's.
- De netwerkplug-in verpakt dit pakket in een UDP-pakket met extra headers die de bron- en bestemmings-IP's naar hun respectievelijke knooppunten wijzigen en dit pakket via eth0 verzenden.
- Nu, aangezien de routetabel al weet hoe verkeer tussen knooppunten moet worden gerouteerd, verzendt deze het pakket naar het bestemmingsknooppunt2.
- Het pakket arriveert bij eth0 van node2 en keert terug naar flannel0 om te decapsuleren en zendt het terug in de naamruimte van het rootnetwerk.
- Nogmaals, het pakket wordt doorgestuurd naar de Linux-bridge om een ARP-verzoek te doen om het IP-adres te achterhalen dat bij veth1 hoort.
- Het pakket kruist uiteindelijk het root-netwerk en bereikt de bestemmings-Pod4.
Dat is dus hoe externe services zijn verbonden met behulp van een inkomend netwerk. Nu, terwijl ik het had over netwerkplug-ins, wil ik u kennis laten maken met de lijst met populaire beschikbare netwerkplug-ins.
Nu ik je zoveel heb verteld over Kubernetes Networking, wil ik je een praktijkvoorbeeld laten zien.
Case Study: Wealth Wizard met behulp van Kubernetes-netwerken
Wealth Wizards is een online platform voor financiële planning dat financiële planning en slimme softwaretechnologie combineert om tegen een betaalbare prijs deskundig advies te geven.
Uitdagingen
Nu was het buitengewoon belangrijk voor het bedrijf om snel kwetsbaarheden in code te ontdekken en te elimineren met volledige zichtbaarheid van hun cloudomgeving, maar het wilde het verkeer beheersen via toegangsbeperkingen.
Daarom gebruikten ze de Kubernetes-infrastructuur om de provisioning en uitrol van de clusters te beheren met behulp van tools om de implementatie en configuratie van microservices over de Kube-clusters te beheren.
Ze gebruikten ook een netwerkbeleidsfunctie van Kubernetes om hen in staat te stellen het verkeer te beheren via toegangsbeperkingen.
Het probleem was nu dat deze beleidsregels toepassingsgericht zijn en alleen kunnen evolueren met de toepassingen, maar er was geen onderdeel om deze beleidsregels af te dwingen.
De enige oplossing die het bedrijf hiervoor kon vinden, was het gebruik van een netwerkplug-in, en daarom gingen ze Weave Net gebruiken.
Oplossing
Deze netwerkplug-in maakt een virtueel netwerk met een netwerkbeleidcontroller om de regels in Kubernetes te beheren en af te dwingen. Niet alleen dit, maar het verbindt ook Docker-containers over meerdere hosts en maakt hun automatische detectie mogelijk.
Stel dat u een werkbelasting in het cluster heeft en dat u een andere werkbelasting in het cluster wilt stoppen die ermee praat. U kunt dit bereiken door een netwerkbeleid te maken dat de toegang beperkt en alleen toegang via de ingangscontroller op een specifieke poort toestaat.
Nu, met zijn implementatie op elk Kubernetes-knooppunt, beheert de plug-in inter-pod routering en heeft hij toegang om de IPtables-regels te manipuleren. In eenvoudige bewoordingen wordt elk beleid geconverteerd naar een verzameling IPtables-regels, gecoördineerd en geconfigureerd op elke machine om de Kubernetes-tags te vertalen.
Oké, nu je zoveel theorie over Kubernetes-netwerken hebt doorgenomen, wil ik je laten zien hoe het praktisch wordt gedaan.
Hands-on
Dus, in de veronderstelling dat jullie allemaal Kubernetes op jullie systemen hebben geïnstalleerd, heb ik een scenario om te demonstreren.
Stel dat u de productnaam en product-ID wilt opslaan, daarvoor heeft u een webapplicatie nodig. In principe heb je één container nodig voor webapplicaties en je hebt nog een container nodig als MySQL voor de backend, en die MySQL-container moet worden gekoppeld aan de webapplicatiecontainer.
Hoe zit het met ik voer het bovenstaande voorbeeld praktisch uit.
Laten we beginnen!
Stap 1: Maak een map in de door u gewenste map en wijzig het pad van de werkmap naar die map.
mkdir HandsOn cd HandsOn /
Stap 2: Maak nu YAML-implementatiebestanden voor de webtoepassing en MySQL-database.
Stap 3: Zodra u de implementatiebestanden heeft gemaakt, implementeert u beide applicaties.
kubectl toepassen -f webapp.yml kubectl toepassen -f mysql.yml
Stap 3.1: Controleer beide implementaties.
kubectl krijgt implementatie
Stap 4: Nu moet u services maken voor beide applicaties.
kubectl toepassen -f webservice.yml kubectl toepassen -f sqlservice.yml
Stap 4.1: Zodra de services zijn gemaakt, implementeert u de services.
Stap 4.2: Controleer of de services zijn gemaakt of niet.
kubectl service krijgen
Stap 5: Controleer nu de configuratie van actieve pods.
kubectl krijgt pods
Stap 6: Ga naar de container in de webapp-pod.
kubectl exec -it container_id bash nano var / www / html / index.php
Stap 6.1 : Wijzig nu de $ servernaam van localhost naar de SQL-servicenaam die ' webapp-sql1 ”In dit geval, en $ wachtwoord van naar ' edureka ”. Vul ook alle vereiste databasegegevens in en sla uw index.php-bestand op met behulp van de sneltoets Ctrl + x en daarna pers Y om op te slaan en druk op invoeren .
Stap 7: Ga nu naar de MySQL-container die aanwezig is in de pod.
kubectl voert het uit container_id bash
Stap 7.1: Krijg toegang om de MySQL-container te gebruiken.
mysql -u root -p edureka
Waar -u de gebruiker vertegenwoordigt en -p het wachtwoord van uw machine.
Stap 7.2: Maak een database in MySQL die zal worden gebruikt om gegevens uit de webapp te halen.
CREËER DATABASE ProductDetails
Stap 7.3: Gebruik de aangemaakte database.
USE ProductDetails
Stap 7.4: Maak een tabel in deze database in MySQL die zal worden gebruikt om gegevens uit de webapp te halen.
CREATE TABLE products (product_name VARCHAR (10), product_id VARCHAR (11))
Stap 7.5: Sluit nu ook de MySQL-container af met de opdracht Uitgang .
Stap 8: Controleer het poortnummer waarop uw webapplicatie werkt.
kubectl krijgt services
Stap 8.1: Open nu de webapplicatie op het toegewezen poortnummer.
Stap 9: Zodra u op klikt Vraag indienen , ga naar het knooppunt waarin uw MySQL-service wordt uitgevoerd en ga vervolgens naar de container.
Dit toont u de output van alle lijstproducten, waarvan u de details heeft ingevuld.
Geïnteresseerd in het leren van Kubernetes?Als je deze Kubernetes Networking-blog relevant vond, bekijk dan het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld.