Kubernetes Networking - En omfattende guide til nettverkskonseptene i Kubernetes



Denne bloggen på Kubernetes Networking vil dype dykk i konseptene som er involvert i Kubernetes, for eksempel kommunikasjon med pods, tjenester og inngangsnettverk.

I forrige blogg på , du må ha forståelse på Kubernetes. I denne bloggen om Kubernetes nettverk vil jeg først og fremst fokusere på nettverkskonseptene som er involvert i Kubernetes.

I denne bloggen på Kubernetes Networking vil du forstå følgende emner:





Hva er Kubernetes?

Du kan definere Kubernetes som et open-source container orkestreringsverktøy som gir en bærbar plattform for automatisering av distribusjon av containeriserte applikasjoner.

Nå må alle som jobber med Kubernetes ha en klar forståelse av Kubernetes Cluster, da det vil hjelpe deg med å forstå Kubernetes Networking.



Kubernetes Cluster

Kubernetes-plattformen tilbyr ønsket statsadministrasjon, som gjør det mulig for klyngetjenester å kjøre, den matede konfigurasjonen i infrastrukturen. La meg forklare med et eksempel.

Vurder en YAML-fil som har all konfigurasjonsinformasjonen som må mates inn i klyngetjenestene. Så denne filen blir matet til API for klyngetjenester, og så blir det opp til klyngetjenestene å finne ut hvordan du kan planlegge pods i miljøet. Anta at det er to containerbilder for pod 1 med tre kopier, og ett containerbilde for pod 2 med to replikaer, det vil være opp til klyngetjenestene å tildele disse pod-replika-parene til arbeiderne.

sorter algoritmer c ++

Kubernetes Cluster - Kubernetes Networking - Edureka



Se diagrammet ovenfor. Nå, som du kan se at klyngetjenestene har tildelt den første arbeideren med to pod-replikapar, den andre arbeideren med et enkelt pod-replica-par, og den tredje arbeideren med to pod-replika-par. Nå er det Kubelet-prosessen som er ansvarlig for å kommunisere klyngetjenester med arbeidere.

Så hele oppsettet av klyngetjenester og arbeiderne selv utgjør dette Kubernetes-klynge !!

Hvordan, tror du disse individuelt tildelte podene kommuniserer med hverandre?

Svaret ligger i Kubernetes Networking!

Abonner på youtube-kanalen vår for å få nye oppdateringer ..!

Det er hovedsakelig 4 problemer å løse med nettverkskonseptene.

  • Beholder til container kommunikasjon
  • Pod to pod Kommunikasjon
  • Pod til servicekommunikasjon
  • Ekstern til tjenestekommunikasjon

La meg fortelle deg hvordan er de ovennevnte problemene løst med Kubernetes Networking.

Kubernetes Networking

Kommunikasjonen mellom pods, tjenester og eksterne tjenester til de i en klynge bringer inn konseptet med Kubernetes nettverk.

Så, for din bedre forståelse, la meg dele konseptene i det følgende.

  • Pods & Container Communication
  • Tjenester
  • Koble eksternt til tjenester via Ingress Network

Pods & Container Communication

Før jeg forteller deg hvordan kommuniserer pods, la meg introdusere deg hva er pods?

Pods

Pods er grunnleggende enheter for Kubernetes-applikasjoner, som består av en eller flere containere som er tildelt på samme vert for å dele en nettverksstabel og andre ressurser. Så dette innebærer at alle containere i en pod kan nå andre på en lokal vert.

La meg informere deg om hvordan disse podene kommuniserer?

Det er to typer kommunikasjon. De kommunikasjon mellom noder og intra-node kommunikasjon.

Så, la oss begynne med kommunikasjon innen noder, men før det, la meg introdusere deg for komponentene i podnettverket.

Intra-node Under Network

Intra-node pod-nettverk er i utgangspunktet kommunikasjonen mellom to forskjellige noder på samme pod. La meg forklare deg med et eksempel.

Anta at en pakke går fra pod1 til pod2.

  • Pakken forlater Pod 1’s nettverk på eth0 og går inn i rotnettverket på veth0
  • Deretter går pakken videre til Linux bridge (cbr0) som oppdager destinasjonen ved hjelp av en ARP-forespørsel
  • Så hvis veth1 har IP, vet broen nå hvor du skal videresende pakken.

La meg på samme måte fortelle deg om inter-node pod-kommunikasjonen.

Interessert i å lære Kubernetes?
Inter-node under nettverket

Tenk på to noder som har forskjellige nettverksnavnområder, nettverksgrensesnitt og en Linux-bro.

Anta nå at en pakke reiser fra pod1 til en pod4 som er på en annen node.

  • Pakken forlater pod 1-nettverket og går inn i rotnettverket på veth0
  • Deretter går pakken videre til Linux bridge (cbr0) hvis ansvar er å gjøre en ARP-forespørsel om å finne destinasjonen.
  • Etter at broen innser at denne pod ikke har destinasjonsadressen, kommer pakken tilbake til hovednettverksgrensesnittet eth0.
  • Pakken forlater nå noden 1 for å finne destinasjonen på den andre noden og går inn i rutetabellen som ruter pakken til noden hvis CIDR-blokk inneholder pod4.
  • Så nå når pakken node2, og deretter tar broen pakken som gjør en ARP-forespørsel om å finne ut at IP-en som tilhører veth0.
  • Til slutt krysser pakken rørparet og når pod4.

Så det er slik pods kommuniserer med hverandre. La oss nå gå videre og se hvordan tjenester hjelper i kommunikasjonen av pods.

Så, hva tror du tjenestene er?

Tjenester

I utgangspunktet er tjenester en type ressurs som konfigurerer en proxy for å videresende forespørslene til et sett med pods, som vil motta trafikk og bestemmes av velgeren. Når tjenesten er opprettet, har den en tildelt IP-adresse som vil godta forespørsler i porten.

Nå er det forskjellige tjenestetyper som gir deg muligheten til å eksponere en tjeneste utenfor klyngens IP-adresse.

Typer tjenester

Det er hovedsakelig 4 typer tjenester.

ClusterIP: Dette er standard tjenestetype som avslører tjenesten på en klynge-intern IP ved å gjøre tjenesten bare tilgjengelig i klyngen.

NodePort: Dette eksponerer tjenesten på hver Node sin IP i en statisk port. Siden, a ClusterIP tjenesten, som NodePort-tjenesten vil rute til, opprettes automatisk. Vi kan kontakte NodePort-tjenesten utenfor klyngen.

LoadBalancer: Dette er tjenestetypen som eksponerer tjenesten eksternt ved hjelp av en skyleverandørens lastbalanser. Så NodePort- og ClusterIP-tjenestene, som den eksterne belastningsutjevneren skal rute til, opprettes automatisk.

Eksternt navn : Denne tjenestetypen tilordner tjenesten til innholdet i eksternt navn felt ved å returnere en CNAME post med verdien.

Så, gutter som handlet om tjenester. Nå lurer du kanskje på hvordan eksterne tjenester kobles til disse nettverkene, ikke sant?

Vel, det er av ingen ringere enn Ingress Network .

Ingress Network

Vel, Ingress-nettverk er den kraftigste måten å eksponere tjenester på, da det er en samling regler som tillater inngående tilkoblinger, som kan konfigureres til å gi tjenester eksternt gjennom tilgjengelige URL-adresser. Så det fungerer i utgangspunktet som et inngangspunkt til Kubernetes-klyngen som administrerer ekstern tilgang til tjenestene i en klynge.

La meg nå forklare deg arbeidet med Ingress Network med et eksempel.

Vi har to noder, som har nav- og rodenavnens navneområder med en Linux-bro. I tillegg til dette har vi også lagt til en ny virtuell Ethernet-enhet kalt flannel0 (nettverksplugin) i rotnettverket.

Nå vil vi at pakken skal flyte fra pod1 til pod 4.

  • Så, pakken forlater pod1s nettverk ved eth0 og går inn i rotnettverket på veth0.
  • Deretter sendes den videre til cbr0, noe som gjør at ARP-forespørselen om å finne destinasjonen, og deretter finner den ut at ingen på denne noden har destinasjonens IP-adresse.
  • Så broen sender pakken til flannel0 ettersom nodens rutetabell er konfigurert med flannel0.
  • Nå snakker flanelldemonen med API-serveren til Kubernetes for å kjenne alle pod-IP-ene og deres respektive noder for å lage tilordninger for pod-IP-er til node-IP-er.
  • Nettverkspluginet pakker denne pakken i en UDP-pakke med ekstra overskrifter som endrer kilde- og destinasjons-IP-er til sine respektive noder og sender denne pakken ut via eth0.
  • Nå, siden rutetabellen allerede vet hvordan man skal dirigere trafikk mellom noder, sender den pakken til målnoden2.
  • Pakken kommer til eth0 av node2 og går tilbake til flannel0 for å avkapslere og sender den tilbake i root-nettverksnavnet.
  • Igjen blir pakken videresendt til Linux-broen for å gjøre en ARP-forespørsel om å finne ut IP-en som tilhører veth1.
  • Pakken krysser endelig rotnettverket og når destinasjonen Pod4.

Så det er slik eksterne tjenester er koblet til ved hjelp av et inngangsnettverk. Nå som jeg snakket om nettverkstillegg, la meg introdusere deg til listen over populære tilgjengelige nettverkstillegg.

Nå som jeg har fortalt deg så mye om Kubernetes Networking, la meg vise deg en sanntidsstudie.

Case Study: Wealth Wizard Using Kubernetes Networking

Wealth Wizards er en online finansiell planleggingsplattform som kombinerer økonomisk planlegging og smart programvareteknologi for å levere ekspertråd til en overkommelig pris.

Utfordringer

Nå var det ekstremt viktig for selskapet å raskt oppdage og eliminere kodesårbarheter med full synlighet for skymiljøet, men ønsket å kontrollere trafikken gjennom tilgangsbegrensninger.

Så de brukte Kubernetes infrastruktur til å administrere klargjøring og utrulling av klyngene ved hjelp av verktøy for å administrere distribusjon og konfigurasjon av mikrotjenester på tvers av Kube-klyngene.

De brukte også en nettverkspolitisk funksjon i Kubernetes for å tillate dem å kontrollere trafikk gjennom tilgangsbegrensninger.

Nå var problemet at disse policyene er applikasjonsorienterte og kan bare utvikle seg med applikasjonene, men det var ingen komponent for å håndheve disse policyene.

Så den eneste løsningen selskapet kunne finne på dette var å bruke et nettverkspluggprogram, og derfor begynte de å bruke Weave Net.

Løsning

Dette nettverkspluginet oppretter et virtuelt nettverk som har en nettverkspolicykontroller for å administrere og håndheve reglene i Kubernetes. Ikke bare dette, men det kobler også Docker-containere på tvers av flere verter og muliggjør automatisk oppdagelse.

Anta at du har en arbeidsmengde i klyngen, og at du vil stoppe annen arbeidsmengde i klyngen som snakker med den. Du kan oppnå dette ved å opprette en nettverkspolicy som begrenser tilgangen og bare tillater inngang til den via inngangskontrolleren på en bestemt port.

Nå, med distribusjonen på hver Kubernetes-node, styrer plugin-programmet routing mellom podene og har tilgang til å manipulere IPtables-reglene. Enkelt sagt konverteres hver policy til en samling av IPtables-regler, koordinert og konfigurert på tvers av hver maskin for å oversette Kubernetes-kodene.

Greit, nå som du har gått gjennom så mye teori om Kubernetes Networking, la meg vise deg hvordan det gjøres praktisk.

Praktisk

Så med en antagelse om at dere alle har installert Kubernetes på systemene, har jeg et scenario å vise frem.

Anta at du vil lagre produktnavn og produkt-ID, for det trenger du en webapplikasjon. I utgangspunktet trenger du en container for webapplikasjon, og du trenger en container til som MySQL for backend, og at MySQL-container skal være koblet til webapplikasjonscontaineren.

Hva med å utføre ovennevnte eksempel praktisk.

La oss komme i gang!

Trinn 1: Opprett en mappe i ønsket katalog og endre banen til den mappen.

mkdir HandsOn cd HandsOn /

Steg 2: Lag nå distribusjon YAML-filer, for webapplikasjonen og MySQL-databasen.

Steg 3: Når du har opprettet distribusjonsfilene, distribuerer du begge applikasjonene.

kubectl gjelder -f webapp.yml kubectl gjelder -f mysql.yml

Trinn 3.1: Sjekk begge distribusjonene.

kubectl få distribusjon

Trinn 4: Nå må du opprette tjenester for begge applikasjonene.

kubectl gjelder -f webservice.yml kubectl gjelder -f sqlservice.yml

Trinn 4.1: Når tjenestene er opprettet, distribuerer du tjenestene.

Trinn 4.2: Sjekk om tjenestene er opprettet eller ikke.

kubectl få service

Trinn 5: Sjekk nå konfigurasjonen av løpende pods.

kubectl få pods

Trinn 6: Gå inn i beholderen inne i webapp-pod.

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

Trinn 6.1 : Nå, endre $ servernavn fra localhost til SQL-tjenestenavnet som er “ webapp-sql1 ”I dette tilfellet, og $ passord fra til ' edureka ”. Fyll også alle nødvendige databasedetaljer og lagre index.php-filen ved hjelp av hurtigtasten Ctrl + x og etter det trykk Y for å lagre og trykk Tast inn .

Trinn 7: Gå nå inn i MySQL-beholderen som er tilstede i poden.

kubectl exec it container_id bash

Trinn 7.1: Få tilgang til å bruke MySQL-beholderen.

mysql -u root -p edureka

Hvor -u representerer brukeren og -p er passordet til maskinen din.

Trinn 7.2: Opprett en database i MySQL som skal brukes til å hente data fra webapp.

OPPRETT DATABASE Produktdetaljer

Trinn 7.3: Bruk den opprettede databasen.

BRUK Produktdetaljer

Trinn 7.4: Lag en tabell i denne databasen i MySQL som skal brukes til å hente data fra webapp.

OPPRETT TABELLprodukter (produktnavn VARCHAR (10), produkt_ID VARCHAR (11))

Trinn 7.5: Gå nå ut av MySQL-beholderen ved å bruke kommandoen exit .

Trinn 8: Sjekk portnummeret som webapplikasjonen din fungerer på.

kubectl få tjenester

Trinn 8.1: Nå åpner du nettapplikasjonen på det tildelte portnummeret.

Trinn 9: Når du klikker på Send inn spørring , gå til noden der MySQL-tjenesten din kjører, og gå deretter inn i containeren.

Dette vil vise deg utdataene fra alle listeproduktene, som du har fylt ut detaljene i.

Interessert i å lære Kubernetes?

Hvis du fant denne Kubernetes Networking-bloggen relevant, sjekk ut av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden.