I den forrige blog på , du må have forstået Kubernetes. I denne blog om Kubernetes-netværk vil jeg primært fokusere på de netværkskoncepter, der er involveret i Kubernetes.
I denne blog på Kubernetes Networking vil du forstå følgende emner:
Hvad er Kubernetes?
Du kan definere Kubernetes som et open source container orkestreringsværktøj, der giver en bærbar platform til automatisering af implementeringen af containeriserede applikationer.
Nu skal enhver, der arbejder med Kubernetes, have en klar forståelse af Kubernetes Cluster, da det vil hjælpe dig med at forstå Kubernetes Networking.
Kubernetes Cluster
Kubernetes-platformen tilbyder ønsket tilstandsstyring, som gør det muligt for klyngetjenesterne at køre, den fødte konfiguration i infrastrukturen. Lad mig forklare med et eksempel.
Overvej en YAML-fil, der har alle de konfigurationsoplysninger, der skal føres til klyngetjenesterne. Så denne fil fødes til API for klyngetjenester, og så er det op til klyngetjenesterne at finde ud af, hvordan man planlægger bælg i miljøet. Så antag, at der er to containerbilleder til pod 1 med tre replikaer, og et containerbillede til pod 2 med to replikaer, det vil være op til klyngetjenesterne at tildele disse pod-replika-par til arbejderne.
c ++ stl spørgsmål til interview
Se ovenstående diagram. Som du kan se, har klyngetjenesterne nu tildelt den første medarbejder med to pod-replikapar, den anden med et enkelt pod-replika-par og den tredje med to pod-replika-par. Nu er det Kubelet-processen, der er ansvarlig for at kommunikere klyngetjenesterne til arbejdstagerne.
Så hele denne opsætning af klyngetjenester og arbejderne selv udgør dette Kubernetes klynge !!
Hvordan tror du, at disse individuelt tildelte bælg kommunikerer med hinanden?
Svaret ligger i Kubernetes Networking!
Abonner på vores youtube-kanal for at få nye opdateringer ..!
Der er hovedsageligt 4 problemer at løse med netværkskoncepterne.
- Container til container kommunikation
- Kommunikation mellem pod til pod
- Pod til servicekommunikation
- Ekstern til kommunikation
Lad mig fortælle dig, hvordan er ovenstående problemer løst med Kubernetes Networking.
Kubernetes netværk
Kommunikationen mellem bælg, tjenester og eksterne tjenester til dem i en klynge bringer konceptet med Kubernetes-netværk ind.
Så for din bedre forståelse, lad mig opdele begreberne i det følgende.
- Bælter og containerkommunikation
- Tjenester
- Forbindelse eksternt til tjenester via Ingress Network
Bælter og containerkommunikation
Før jeg fortæller dig, hvordan kommunikerer bælg, lad mig introducere dig, hvad der er bælg?
Bælg
Pods er basisenheder i Kubernetes-applikationer, der består af en eller flere containere, der er allokeret på den samme vært til at dele en netværksstak og andre ressourcer. Så det betyder, at alle containere i en pod kan nå andre på en lokal vært.
Lad mig nu orientere dig om, hvordan disse pods kommunikerer?
Der er to typer kommunikation. Det inter-node kommunikation og intra-node kommunikation.
Så lad os starte med intra-nodekommunikation, men før det vil jeg introducere dig for komponenterne i pod-netværket.
Intra-node under netværk
Intra-node pod-netværk er dybest set kommunikationen mellem to forskellige noder på den samme pod. Lad mig forklare dig med et eksempel.
Antag, at en pakke går fra pod1 til pod2.
- Pakken forlader Pod 1's netværk på eth0 og går ind i rodnetværket ved veth0
- Derefter går pakken videre til Linux-broen (cbr0), som opdager destinationen ved hjælp af en ARP-anmodning
- Så hvis veth1 har IP, ved broen nu, hvor pakken skal videresendes.
Lad mig ligeledes fortælle dig om inter-node pod-kommunikationen.
Interesseret i at lære Kubernetes?Inter-node under netværket
Overvej to noder, der har forskellige netværksnavneområder, netværksgrænseflader og en Linux-bro.
Antag nu, at en pakke rejser fra pod1 til en pod4, som er på en anden node.
- Pakken forlader pod 1-netværket og går ind i rodnetværket ved veth0
- Derefter videreføres pakken til Linux-broen (cbr0), hvis ansvar er at stille en ARP-anmodning om at finde destinationen.
- Når broen er klar over, at denne pod ikke har destinationsadressen, vender pakken tilbage til hovednetværksgrænsefladen eth0.
- Pakken forlader nu noden 1 for at finde sin destination på den anden node og går ind i rutetabellen, der ruter pakken til den node, hvis CIDR-blok indeholder pod4.
- Så nu når pakken node2, og derefter tager broen pakken, som fremsætter en ARP-anmodning om at finde ud af, at IP'en tilhører veth0.
- Endelig krydser pakken rørparret og når pod4.
Så det er sådan, at bælg kommunikerer med hinanden. Lad os nu gå videre og se, hvordan tjenester hjælper med at kommunikere pods.
Så hvad tror du, tjenesterne er?
Tjenester
Dybest set er tjenester en type ressource, der konfigurerer en proxy til at videresende anmodningerne til et sæt bælg, som modtager trafik og bestemmes af vælgeren. Når tjenesten er oprettet, har den en tildelt IP-adresse, som accepterer anmodninger i porten.
Nu er der forskellige servicetyper, der giver dig mulighed for at eksponere en tjeneste uden for din klynges IP-adresse.
Typer af tjenester
Der er hovedsagelig 4 typer tjenester.
ClusterIP: Dette er standardtjenestetypen, der eksponerer tjenesten på en klynge-intern IP ved at gøre tjenesten kun tilgængelig inden for klyngen.
NodePort: Dette eksponerer tjenesten på hver nodes IP i en statisk port. Siden, a ClusterIP tjenesten, som NodePort-tjenesten dirigeres til, oprettes automatisk. Vi kan kontakte NodePort-tjenesten uden for klyngen.
LoadBalancer: Dette er den servicetype, der eksponerer tjenesten eksternt ved hjælp af en cloud-udbyders load balancer. Så oprettes NodePort- og ClusterIP-tjenesterne, hvortil den eksterne belastningsafbalancering skal rute, automatisk.
Eksternt navn : Denne servicetype kortlægger tjenesten til indholdet af eksternt navn felt ved at returnere en CNAME registrere med dens værdi.
Så fyre, det handlede kun om tjenester. Nu spekulerer du måske over, hvordan eksterne tjenester opretter forbindelse til disse netværk, ikke?
Nå, det er af ingen ringere end Ingress-netværk .
Ingress-netværk
Nå, Ingress-netværk er den mest kraftfulde måde at eksponere tjenester på, da det er en samling af regler, der tillader indgående forbindelser, der kan konfigureres til at give tjenester eksternt via tilgængelige URL-adresser. Så det fungerer grundlæggende som et indgangspunkt til Kubernetes-klyngen, der administrerer ekstern adgang til tjenesterne i en klynge.
Lad mig nu forklare dig arbejdet med Ingress Network med et eksempel.
Vi har 2 noder, der har pod- og rodnetværksnavneområder med en Linux-bro. Ud over dette har vi også tilføjet en ny virtuel ethernet-enhed kaldet flannel0 (netværksplugin) til rodnetværket.
Nu ønsker vi, at pakken flyder fra pod1 til pod 4.
- Så pakken forlader pod1's netværk ved eth0 og går ind i rodnetværket ved veth0.
- Derefter sendes det videre til cbr0, hvilket gør ARP-anmodningen om at finde destinationen, og det finder derefter ud af, at ingen på denne node har destinations-IP-adressen.
- Så broen sender pakken til flannel0, da nodens rutetabel er konfigureret med flannel0.
- Nu taler flannel-dæmonen med API-serveren i Kubernetes for at kende alle pod-IP'erne og deres respektive noder for at oprette tilknytninger til pods-IP'er til node-IP'er.
- Netværkspluginet indpakker denne pakke i en UDP-pakke med ekstra overskrifter, der ændrer kilde- og destinations-IP'erne til deres respektive noder og sender denne pakke ud via eth0.
- Nu, da rutetabellen allerede ved, hvordan man dirigerer trafik mellem noder, sender den pakken til destinationsnoden2.
- Pakken ankommer til eth0 i node2 og går tilbage til flannel0 for at afkapslere og udsender den tilbage i rodnetværksnavnet.
- Igen videresendes pakken til Linux-broen for at fremsætte en ARP-anmodning om at finde ud af den IP, der tilhører veth1.
- Pakken krydser endelig rodnetværket og når destinationen Pod4.
Så det er sådan, eksterne tjenester er forbundet ved hjælp af et indgangsnetværk. Nu, mens jeg talte om netværks plugins, lad mig introducere dig til listen over populære tilgængelige netværks plugins.
Nu hvor jeg har fortalt dig så meget om Kubernetes Networking, så lad mig vise dig en real-life casestudie.
Casestudie: Rigdomsguide ved hjælp af Kubernetes-netværk
Wealth Wizards er en online finansiel planlægningsplatform, der kombinerer økonomisk planlægning og smart softwareteknologi til at levere ekspertrådgivning til en overkommelig pris.
Udfordringer
Nu var det yderst vigtigt for virksomheden hurtigt at opdage og eliminere kodesårbarheder med fuld synlighed af deres skymiljø, men ønskede at kontrollere trafik gennem adgangsbegrænsninger.
Så de brugte Kubernetes-infrastruktur til at styre klargøring og udrulning af klyngerne ved hjælp af værktøjer til at styre implementering og konfiguration af mikrotjenester på tværs af Kube-klynger.
De brugte også en netværkspolitisk funktion i Kubernetes for at give dem mulighed for at kontrollere trafik gennem adgangsbegrænsninger.
Nu var problemet, at disse politikker er applikationsorienterede og kun kan udvikle sig med applikationerne, men der var ingen komponent til at håndhæve disse politikker.
Så den eneste løsning, som virksomheden kunne finde på dette, var at bruge et netværksplugin, og derfor begyndte de at bruge Weave Net.
Løsning
Dette netværksplugin opretter et virtuelt netværk, der har en netværkspolitisk controller til at styre og håndhæve reglerne i Kubernetes. Ikke kun dette, men det forbinder også Docker-containere på tværs af flere værter og muliggør deres automatiske opdagelse.
Så antag, at du har en arbejdsbyrde i klyngen, og at du vil stoppe enhver anden arbejdsbyrde i klyngen, der taler til den. Du kan opnå dette ved at oprette en netværkspolitik, der begrænser adgangen og kun tillader indgang til den via indgangscontrolleren på en bestemt port.
Nu, med sin implementering på hver Kubernetes-node, styrer pluginet inter-pod-routing og har adgang til at manipulere IPtables-reglerne. Enkelt sagt konverteres hver politik til en samling af IPtables-regler, koordineret og konfigureret på tværs af hver maskine til at oversætte Kubernetes-tags.
Okay, nu hvor du har gennemgået så meget teori om Kubernetes Networking, lad mig vise dig, hvordan det gøres praktisk.
Praktisk erfaring
Så med en antagelse om, at alle jer har installeret Kubernetes på dine systemer, har jeg et scenarie at fremvise.
Antag, at du vil gemme produktnavn og produkt-id, for at du skal bruge en webapplikation. Dybest set har du brug for en container til webapplikation, og du har brug for endnu en container som MySQL til backend, og at MySQL-containeren skal være knyttet til webapplikationscontaineren.
Hvad med at jeg udfører ovennævnte eksempel praktisk.
Lad os komme igang!
Trin 1: Opret en mappe i det ønskede bibliotek, og skift stien til den mappe, der fungerer.
mkdir HandsOn cd HandsOn /
Trin 2: Opret nu implementerings YAML-filer til webapplikationen og MySQL-databasen.
Trin 3: Når du har oprettet implementeringsfilerne, skal du implementere begge applikationerne.
kubectl anvende -f webapp.yml kubectl anvende -f mysql.yml
Trin 3.1: Kontroller begge implementeringer.
kubectl få implementering
Trin 4: Nu skal du oprette tjenester til begge applikationer.
kubectl anvende -f webservice.yml kubectl anvende -f sqlservice.yml
Trin 4.1: Når tjenesterne er oprettet, skal du implementere tjenesterne.
Trin 4.2: Kontroller, om tjenesterne er oprettet eller ej.
kubectl få service
Trin 5: Kontroller nu konfigurationen af kørende bælg.
kubectl få bælg
Trin 6: Gå ind i beholderen inde i webapp-pod'en.
kubectl exec -it container_id bash nano var / www / html / index.php
Trin 6.1 : Skift nu $ servernavn fra localhost til navnet på SQL-tjenesten, som er “ webapp-sql1 ”I dette tilfælde, og $ adgangskode fra til ' edureka ”. Udfyld også alle de nødvendige databaseoplysninger, og gem din index.php-fil ved hjælp af tastaturgenvejen Ctrl + x og derefter trykke på Y for at gemme og trykke på gå ind .
Trin 7: Gå nu ind i MySQL-containeren til stede i pod'en.
kubectl exec it container_id bash
Trin 7.1: Få adgang til at bruge MySQL-containeren.
mysql -u root -p edureka
Hvor -u repræsenterer brugeren, og -p er adgangskoden til din maskine.
Trin 7.2: Opret en database i MySQL, som vil blive brugt til at hente data fra webapp.
OPRET DATABASE Produktdetaljer
Trin 7.3: Brug den oprettede database.
BRUG Produktoplysninger
Trin 7.4: Opret en tabel i denne database i MySQL, som vil blive brugt til at hente data fra webapp.
Opret TABEL-produkter (produktnavn VARCHAR (10), produkt_ID VARCHAR (11))
Trin 7.5: Afslut nu også MySQL-container ved hjælp af kommandoen Afslut .
Trin 8: Kontroller det portnummer, som din webapplikation fungerer på.
kubectl få tjenester
Trin 8.1: Åbn nu webapplikationen på det tildelte portnummer.
Trin 9: Når du klikker på Send forespørgsel , gå til den node, hvor din MySQL-tjeneste kører, og gå derefter ind i containeren.
Dette viser dig output af alle listeprodukter, som du har udfyldt detaljerne for.
Interesseret i at lære Kubernetes?Hvis du fandt denne Kubernetes Networking-blog relevant, skal du tjekke af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden.