Kubernetes Networking - En omfattande guide till nätverksbegreppen i Kubernetes



Den här bloggen på Kubernetes Networking kommer att dyka djupt in i de begrepp som är involverade i Kubernetes, såsom kommunikation med pods, tjänster och ingångsnätverk.

I föregående blogg på , du måste ha fått förståelse för Kubernetes. I den här bloggen om Kubernetes nätverk kommer jag främst att fokusera på de nätverkskoncept som är involverade i Kubernetes.

I den här bloggen på Kubernetes Networking förstår du följande ämnen:





Vad är Kubernetes?

Du kan definiera Kubernetes som ett verktyg för öppen källkodsbehandlingsorkestring som tillhandahåller en bärbar plattform för automatisering av distributionen av containeriserade applikationer.

Nu måste alla som arbetar med Kubernetes ha en tydlig förståelse för Kubernetes Cluster eftersom det hjälper dig att förstå Kubernetes Networking.



Kubernetes Cluster

Kubernetes-plattformen erbjuder önskad tillståndshantering, vilket gör att klustertjänsterna kan köras, den matade konfigurationen i infrastrukturen. Låt mig förklara med ett exempel.

Tänk på en YAML-fil som har all konfigurationsinformation som behöver matas in i klustertjänsterna. Så den här filen matas till API för klustertjänster, och sedan är det upp till klustertjänsterna att ta reda på hur man schemalägger pods i miljön. Anta att det finns två containerbilder för pod 1 med tre repliker och en container image för pod 2 med två repliker, det är upp till klustertjänsterna att tilldela dessa pod-replikpar till arbetarna.

vad svävar i css

Kubernetes Cluster - Kubernetes Networking - Edureka



Se ovanstående diagram. Nu, som du kan se att klustertjänsterna har tilldelat den första arbetaren med två pod-replikpar, den andra arbetaren med ett enda pod-replikpar och den tredje arbetaren med två pod-replikpar. Nu är det Kubelet-processen som ansvarar för att kommunicera klustertjänsterna till arbetarna.

Så hela denna uppsättning av klustertjänster och arbetarna själva utgör detta Kubernetes kluster !!

Hur tror du att dessa individuellt tilldelade skida kommunicerar med varandra?

Svaret ligger i Kubernetes Networking!

Prenumerera på vår youtube-kanal för att få nya uppdateringar ..!

Det finns huvudsakligen fyra problem att lösa med nätverkskoncepten.

  • Container till container kommunikation
  • Kommunikation från pod till pod
  • Kommunikation med pod till tjänst
  • Extern till kommunikation

Nu, låt mig berätta hur problemen ovan löses med Kubernetes Networking.

Kubernetes nätverk

Kommunikationen mellan pods, tjänster och externa tjänster till de i ett kluster ger konceptet Kubernetes nätverk.

Så, för din bättre förståelse, låt mig dela upp begreppen i följande.

  • Pods & Container Communication
  • Tjänster
  • Ansluter externt till tjänster via Ingress Network

Pods & Container Communication

Innan jag berättar för dig hur kommandon kommunicerar, låt mig introducera dig vad är pods?

Skida

Pods är basenheter för Kubernetes-applikationer, som består av en eller flera containrar som tilldelats på samma värd för att dela en nätverksstack och andra resurser. Så detta innebär att alla containrar i en pod kan nå andra på en lokal värd.

Låt mig nu informera dig om hur kommunicerar dessa pods?

Det finns två typer av kommunikation. De kommunikation mellan noder och den kommunikation inom noden.

Så låt oss börja med kommunikation inom noder, men innan det låt mig presentera komponenterna i podnätverket.

Intra-nod under nätverk

Intra-nod-podnätverk är i grunden kommunikationen mellan två olika noder på samma pod. Låt mig förklara dig med ett exempel.

Antag att ett paket går från pod1 till pod2.

  • Paketet lämnar Pod 1: s nätverk vid eth0 och går in i rotnätverket vid veth0
  • Därefter passerar paketet till Linux-bron (cbr0) som upptäcker destinationen med en ARP-begäran
  • Så om veth1 har IP-adressen, vet bron nu vart paketet ska vidarebefordras.

Nu, låt mig på samma sätt berätta om kommunikationen mellan pod-noder.

Intresserad av att lära dig Kubernetes?
Inter-nod under nätverket

Tänk på två noder med olika nätverksnamnområden, nätverksgränssnitt och en Linux-bro.

Antag nu att ett paket reser från pod1 till en pod4 som är på en annan nod.

  • Paketet lämnar pod 1-nätverket och går in i rotnätverket vid veth0
  • Sedan går paketet vidare till Linux-bron (cbr0) vars ansvar är att göra en ARP-begäran för att hitta destinationen.
  • När bron inser att denna pod inte har destinationsadressen kommer paketet tillbaka till huvudnätverksgränssnittet eth0.
  • Paketet lämnar nu noden 1 för att hitta sin destination på den andra noden och går in i ruttabellen som dirigerar paketet till noden vars CIDR-block innehåller pod4.
  • Så nu når paketet nod2 och sedan tar bron paketet som gör en ARP-begäran för att ta reda på att IP tillhör veth0.
  • Slutligen korsar paketet rörparet och når pod4.

Så det är så pods kommunicerar med varandra. Nu kan vi gå vidare och se hur tjänster hjälper till att kommunicera pods.

Så, vad tror du att tjänsterna är?

Tjänster

I grund och botten är tjänster en typ av resurs som konfigurerar en proxy för att vidarebefordra förfrågningarna till en uppsättning pods, som kommer att ta emot trafik och bestäms av väljaren. När tjänsten har skapats har den en tilldelad IP-adress som accepterar förfrågningar i porten.

Nu finns det olika tjänstetyper som ger dig möjlighet att exponera en tjänst utanför din kluster IP-adress.

Typer av tjänster

Det finns huvudsakligen fyra typer av tjänster.

ClusterIP: Detta är standardtjänsttypen som exponerar tjänsten på en kluster-intern IP genom att göra tjänsten endast tillgänglig inom klustret.

NodePort: Detta exponerar tjänsten på varje nods IP i en statisk port. Sedan, a ClusterIP tjänsten, till vilken NodePort-tjänsten dirigeras, skapas automatiskt. Vi kan kontakta NodePort-tjänsten utanför klustret.

Lastbalanserare: Det här är den servicetyp som exponerar tjänsten externt med hjälp av en molnleverantörs belastningsutjämnare. Så, NodePort- och ClusterIP-tjänsterna, som den externa belastningsutjämnaren ska dirigeras till, skapas automatiskt.

Externt namn : Den här servicetypen mappar tjänsten till innehållet i externt namn fält genom att returnera en CNAME post med sitt värde.

Så killar som handlade om tjänster. Nu kanske du undrar hur externa tjänster ansluter till dessa nätverk, eller hur?

Tja, det är av ingen ringare än Ingress Network .

Ingress Network

Ingress-nätverket är det mest kraftfulla sättet att exponera tjänster eftersom det är en samling regler som tillåter inkommande anslutningar, som kan konfigureras för att ge tjänster externt via tillgängliga webbadresser. Så det fungerar i grunden som en ingång till Kubernetes-klustret som hanterar extern åtkomst till tjänsterna i ett kluster.

Låt mig nu förklara för dig hur Ingress Network fungerar med ett exempel.

Vi har två noder som har namn- och rotnätverksnamnrymden med en Linux-bro. Utöver detta har vi också lagt till en ny virtuell Ethernet-enhet som heter flannel0 (nätverksplugin) till rotnätverket.

Nu vill vi att paketet ska flöda från pod1 till pod 4.

  • Så, paketet lämnar pod1: s nätverk vid eth0 och går in i rotnätverket vid veth0.
  • Sedan skickas den vidare till cbr0, vilket gör att ARP begär att hitta destinationen och därefter får reda på att ingen på denna nod har destinations-IP-adressen.
  • Så bron skickar paketet till flannel0 eftersom nodens ruttabell är konfigurerad med flannel0.
  • Nu pratar flanelldemonen med API-servern i Kubernetes för att känna till alla IP-adresser och deras respektive noder för att skapa mappningar för pods-IP: er till nod-IP: er.
  • Nätverkspluginet slår in det här paketet i ett UDP-paket med extra rubriker som ändrar käll- och destinations-IP: erna till sina respektive noder och skickar detta paket via eth0.
  • Eftersom ruttabellen redan vet hur man dirigerar trafik mellan noder skickar den paketet till destinationsnoden2.
  • Paketet anländer till eth0 för node2 och går tillbaka till flannel0 för att avkapsla och sänder tillbaka det i rotnätverksnamnutrymmet.
  • Återigen vidarebefordras paketet till Linux-bron för att göra en ARP-begäran för att ta reda på IP-adressen som tillhör veth1.
  • Paketet passerar äntligen rotnätverket och når destinationen Pod4.

Så, så är externa tjänster anslutna med hjälp av ett ingångsnätverk. Nu, när jag pratade om nätverksplugins, låt mig presentera dig för listan över populära nätverkspluggins.

Nu när jag har berättat så mycket om Kubernetes Networking, låt mig visa dig en verklig fallstudie.

Fallstudie: Wealth Wizard Using Kubernetes Networking

Wealth Wizards är en online-planeringsplattform som kombinerar ekonomisk planering och smart programvaruteknik för att ge expertråd till en överkomlig kostnad.

Utmaningar

Nu var det oerhört viktigt för företaget att snabbt upptäcka och eliminera kodsårbarheter med full synlighet för sin molnmiljö men ville kontrollera trafiken genom åtkomstbegränsningar.

Så de använde Kubernetes infrastruktur för att hantera tillhandahållande och utrullning av kluster med hjälp av verktyg för att hantera distribution och konfiguration av mikrotjänster över Kube-kluster.

De använde också en nätverkspolicy i Kubernetes för att låta dem kontrollera trafik genom åtkomstbegränsningar.

Nu var problemet, dessa policyer är applikationsorienterade och kan bara utvecklas med applikationerna, men det fanns ingen komponent för att genomdriva dessa policyer.

Så den enda lösningen som företaget kunde hitta för detta var att använda ett nätverksplugin, och därför började de använda Weave Net.

Lösning

Detta nätverksplugin skapar ett virtuellt nätverk som har en nätverkspolicykontroll för att hantera och tillämpa reglerna i Kubernetes. Inte bara detta, men det kopplar också Docker-behållare över flera värdar och möjliggör deras automatiska upptäckt.

Anta att du har en arbetsbelastning i klustret och att du vill stoppa alla andra arbetsbelastningar i klustret som pratar med det. Du kan uppnå detta genom att skapa en nätverkspolicy som begränsar åtkomst och endast tillåter ingång till den via ingångskontrollen på en viss port.

Nu, med sin distribution på varje Kubernetes-nod, hanterar pluginet inter-pod-routing och har tillgång till att manipulera IPtables-reglerna. Enkelt uttryckt konverteras varje policy till en samling regler för IPtables, samordnas och konfigureras över varje maskin för att översätta Kubernetes-taggarna.

Okej, nu när du har gått igenom så mycket teori om Kubernetes Networking, låt mig visa dig hur det görs praktiskt.

Praktisk

Så med ett antagande att ni alla har installerat Kubernetes på era system har jag ett scenario att visa upp.

Antag att du vill lagra produktnamn och produkt-ID, för det behöver du en webbapplikation. I grund och botten behöver du en behållare för webbapplikation och du behöver ytterligare en behållare som MySQL för backend, och att MySQL-behållaren ska länkas till webbapplikationsbehållaren.

Vad sägs om att jag utför det ovan nämnda exemplet praktiskt taget.

Låt oss börja!

Steg 1: Skapa en mapp i önskad katalog och ändra sökvägen till den mappen.

mkdir HandsOn cd HandsOn /

Steg 2: Skapa nu YAML-filer för distribution för webbapplikationen och MySQL-databasen.

Steg 3: När du har skapat distributionsfilerna distribuerar du båda applikationerna.

kubectl applicera -f webapp.yml kubectl applicera -f mysql.yml

Steg 3.1: Kontrollera båda distributionerna.

kubectl få distribution

Steg 4: Nu måste du skapa tjänster för båda applikationerna.

kubectl applicera -f webservice.yml kubectl applicera -f sqlservice.yml

Steg 4.1: När tjänsterna har skapats distribuerar du tjänsterna.

Steg 4.2: Kontrollera om tjänsterna har skapats eller inte.

kubectl få service

Steg 5: Kontrollera nu konfigurationen av löpande pods.

kubectl få skida

Steg 6: Gå in i behållaren inuti webapp-podden.

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

Steg 6.1 : Ändra nu $ servernamn från localhost till SQL-tjänstnamnet som är “ webapp-sql1 ”I detta fall, och $ lösenord från till ' edureka ”. Fyll också alla nödvändiga databasuppgifter och spara din index.php-fil med kortkommandot Ctrl + x och tryck sedan på Y för att spara och tryck på stiga på .

Steg 7: Gå nu in i MySQL-behållaren i podden.

kubectl exec it container_id bash

Steg 7.1: Få tillgång till att använda MySQL-behållaren.

mysql -u root -p edureka

Var -u representerar användaren och -p är lösenordet för din maskin.

Steg 7.2: Skapa en databas i MySQL som kommer att användas för att hämta data från webapp.

SKAPA DATABAS Produktdetaljer

Steg 7.3: Använd den skapade databasen.

ANVÄND produktinformation

Steg 7.4: Skapa en tabell i denna databas i MySQL som kommer att användas för att hämta data från webapp.

SKAPA TABELLprodukter (produktnamn VARCHAR (10), produkt_ID VARCHAR (11))

Steg 7.5: Avsluta nu också MySQL-behållaren med kommandot utgång .

Steg 8: Kontrollera portnumret som din webbapplikation fungerar på.

kubectl få tjänster

Steg 8.1: Öppna nu webbapplikationen på det tilldelade portnumret.

Steg 9: När du klickar på Skicka fråga , gå till noden där din MySQL-tjänst körs och gå sedan in i behållaren.

Detta visar dig resultatet av alla listprodukter, som du har fyllt i detaljerna för.

Intresserad av att lära dig Kubernetes?

Om du tyckte att den här Kubernetes Networking-bloggen var relevant, kolla in av Edureka, ett pålitligt online-lärande företag med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen.