Phenquestions
- En applikasjon distribuert på en Kubernetes-klynge kjører som en samlebøyle.
- Podene er egentlig containere som er planlagt på tvers av flere noder.
- Noder kan være fysiske servere eller virtuelle maskiner som tilbys av hostingleverandøren din. Åpenbart kan du også Kubernetes på en lokal server, hvis du ønsker det.
- Hver Pod har en unik IP-adresse.
- Søknaden din er delt inn i mange underkomponenter, ofte referert til som mikrotjenester.
- For hver mikroservice i applikasjonen din, har en tilsvarende tjeneste i Kubernetes.
- I sammenheng med Kubernetes, a Service eksponerer en samling pods for resten av klyngen som en enkelt abstraksjon. En enkelt virtuell IP.
- Dette hjelper en tjeneste i applikasjonen din til å kommunisere med en annen tjeneste. Det er en abstraksjon som lar deg adressere en samling pods, i stedet for å spesifisere IP-adressen til en pod, hver gang du vil snakke med den.
- En Kubernetes-tjeneste fungerer også som en lastbalanser for alle belgene som den representerer. Trafikken fordeles jevnt over alle nodene.
Så langt så bra. Hver tjeneste kan snakke med en annen tjeneste. Denne kommunikasjonen er mulig i hele Kubernetes-klyngen
Eksponere tjenester
“Hvis et tre faller i en skog og ingen er i nærheten for å høre det, lager det en lyd?”
På samme måte, hvis applikasjonen din ikke tjener et formål utenfor Kubernetes-klyngen, betyr det virkelig noe om klyngen din er godt bygget? Sannsynligvis ikke.
For å gi deg et konkret eksempel, la oss si at vi har en klassisk webapp sammensatt av en frontend skrevet i Nodejs og en backend skrevet i Python som bruker MySQL-database. Du distribuerer to tilsvarende tjenester på Kubernetes-klyngen.
Du lager en Dockerfile som spesifiserer hvordan du pakker frontend-programvaren i en container, og på samme måte pakker du backend. Neste i Kubernetes-klyngen din, vil du distribuere to tjenester som hver kjører et sett med bøtter bak den. Nettjenesten kan snakke med databaseklyngen og omvendt.
Imidlertid utsetter Kubernetes ikke noen av disse tjenestene (som er essensielle HTTP-endepunkter) for resten av verden. Som nevnt i de offisielle dokumentene:
“Tjenester antas å ha virtuelle IP-er som bare kan rutes i klyngenettverket”
Dette er helt rimelig fra et sikkerhetssynspunkt, tjenestene dine kan snakke med hverandre, men klyngen tillater ikke eksterne enheter å snakke direkte med tjenestene. For eksempel er det bare nettgrensesnittet som kan snakke med databasetjenesten, og ingen andre kan engang sende forespørsler til databasetjenesten.
Problemet oppstår når vi ser på brukstilfellet til en frontend-tjeneste. Det må eksponeres for resten av publikum, slik at sluttbrukere kan bruke applikasjonen din. Vi avslører slike tjenester ved bruk av Kubernetes Ingress.
Kubernetes Ingress
Ingress eksponerer HTTP- og HTTPS-ruter fra utenfor klyngen til tjenester i klyngen. Du kan kontrollere rutingsreglene ved å definere Kubernetes Ingress-ressursen. Men det gjør mye mer enn det. Å eksponere en enkelt tjeneste kan oppnås ved hjelp av forskjellige andre alternativer som NodePort eller Load Balancers, men disse fasilitetene har ikke funksjoner som er sofistikerte nok til en moderne webapp.
Funksjoner som å eksponere flere apper på en enkelt IP, definere ruter osv.
Så la oss forstå disse funksjonene for resten av artikkelen:
Single Service Ingress
Dette er den enkleste versjonen av å eksponere en enkelt tjeneste som en webfront med en IP (eller et domenenavn) og standard HTTP- og HTTPS-porter (i.e, 80 og 443).
Enkelt Fanout
Dette er et inngangsoppsett som lar deg tillate innkommende trafikk til en enkelt IP og dirigere den til flere tjenester.
Det består av:
- En inngangsressurs består av et vertsnavn foo.bar.com
- En liste over stier der trafikken skal rutes som foo.bar.com / admin foo.bar.com / hjem foo.bar.com / sso
Single fanout er tilfelle der en enkelt IP brukes til flere tjenester. Tjenestene kan være på forskjellige stier i URI som foo.bar.com / admin kan være en tjeneste for administratorer og foo.bar.com / home kan være tjenesten som genererer hver brukeres hjemmeside.
Inngangsporten vil alltid være 80 eller 443, men porten der tjenestene kjører (inne i klyngen) kan variere ganske mye.
Denne typen inngang hjelper oss med å minimere antall lastbalanserere i klyngen, siden den egentlig fungerer som en.
Navnbasert virtuell hosting
Offentlige IP-adresser er endelige. De er også ganske dyre. Ideen om navnebasert virtuell hosting er eldre enn Kubernetes. Kjernen i det er at du peker DNS-postene for forskjellige nettsteder som ww1.eksempel.com og ww2.eksempel.com til samme IP-adresse. Serveren som kjører på den IP-adressen vil se den innkommende forespørselen, og hvis vertsnavnet som er nevnt i forespørselen, er for ww1.eksempel.com så serverer det nettstedet for deg, og hvis ww2.eksempel.com blir bedt om, så blir det servert.
I sammenheng med Kubernetes kan vi kjøre to tjenester som kjører på for eksempel port 80 og eksponere dem begge på en enkelt IP-adresse ved å bruke en inngang også til port 80. Ved inngangspunktet trafikken til ww1.eksempel.com blir skilt fra trafikken for 2. verdenskrig.eksempel.com. Derav begrepet navn basert virtuell hosting.
Konklusjon
Ingress i Kubernetes er ganske sofistikert for å bli dekket av et enkelt innlegg. Det er en rekke brukssaker for det, og en rekke Ingress Controllers som vil legge Ingress-funksjonaliteten til klyngen din. Jeg vil anbefale å starte med Nginx Ingress Controller.
For ytterligere detaljer og spesifikasjoner kan du også følge den offisielle dokumentasjonen.
