Kubernetes ima puno pokretnih dijelova. To se može očekivati ​​od bilo kojeg modela namijenjenog distribuiranom računanju. Da bismo istražili što nam Kubernetes Ingress pomaže u ostvarenju, najprije rezimirajmo nekoliko relevantnih detalja o tipičnom Kubernetesovom klasteru:

1. Aplikacija postavljena na klasteru Kubernetes radi kao mahune za prikupljanje.
2. Mahune su u osnovi spremnici koji su raspoređeni na više čvorova.
3. Čvorovi mogu biti fizički poslužitelji ili VM-ovi koje nudi vaš davatelj usluga hostinga. Očito je da Kubernetes možete i na lokalnom poslužitelju, ako tako želite.
4. Svaki Pod ima jedinstvenu IP adresu.
5. Vaša je aplikacija podijeljena na mnoge potkomponente, koje se često nazivaju mikrouslugama.
6. Za svaku mikroservisu vaše aplikacije postoji odgovarajuća usluga u Kubernetesu.
7. U kontekstu Kubernetesa, a Servis izlaže zbirku mahuna ostatku klastera kao jednu apstrakciju. Jedna virtualna IP adresa.
8. To pomaže da jedna usluga vaše aplikacije komunicira s drugom uslugom. To je apstrakcija koja vam omogućuje da se obratite kolekciji mahuna, umjesto da navedete IP adresu mahune, svaki put kada želite razgovarati s njom.
9. Usluga Kubernetes također djeluje kao uravnoteživač tereta za sve mahune koje predstavlja. Promet se ravnomjerno raspoređuje na sve čvorove.

Zasada je dobro. Svaka služba može razgovarati s drugom službom. Ova je komunikacija moguća na cijelom klasteru Kubernetes

Izlaganje usluga

“Ako drvo padne u šumi, a nikoga nema u blizini, čuje li ga zvuk?"

Slično tome, ako vaša aplikacija nema svrhu izvan klastera Kubernetes, je li stvarno važno je li vaš klaster dobro izgrađen ili ne? Vjerojatno ne.

Da bismo vam dali konkretan primjer, recimo da imamo klasičnu web aplikaciju koja se sastoji od frontenda napisanog u Nodejsu i pozadine napisane na Pythonu koja koristi MySQL bazu podataka. Na svom Kubernetesovom klasteru rasporedite dvije odgovarajuće usluge.

Napravite Dockerfile koji određuje kako spakirati prednji softver u spremnik, a slično tome pakirate i svoju pozadinu. Sljedeće u svom Kubernetesovom klasteru, rasporedit ćete dvije usluge od kojih svaka pokreće skup podslova iza sebe. Web usluga može razgovarati s klasterom baze podataka i obrnuto.

Međutim, Kubernetes ne izlaže niti jednu od ovih usluga (koje su ključne HTTP krajnje točke) ostatku svijeta. Kao što je navedeno u službenim dokumentima:

“Pretpostavlja se da usluge imaju virtualne IP-ove samo za usmjeravanje unutar mreže klastera"

To je sa sigurnosne točke gledišta sasvim razumno, vaše usluge mogu međusobno razgovarati, ali klaster neće dopustiti vanjskim entitetima da izravno razgovaraju sa uslugama. Na primjer, samo vaš web sučelje može razgovarati sa uslugom baze podataka, a nitko drugi ne može ni slati zahtjeve usluzi baze podataka.

Problem nastaje kada pogledamo slučaj korištenja frontend usluge. Treba biti izložen ostatku javnosti kako bi krajnji korisnici mogli koristiti vašu aplikaciju. Takve usluge izlažemo koristeći Kubernetes Ingress.

Kubernetes Ingress

Ingress izlaže HTTP i HTTPS rute izvan klastera uslugama unutar klastera. Možete kontrolirati pravila usmjeravanja definiranjem resursa Kubernetes Ingress. Ali čini puno više od toga. Izlaganje jedne usluge može se postići upotrebom raznih drugih alternativa poput NodePort-a ili Load Balancera, ali ti sadržaji nemaju značajke koje su dovoljno sofisticirane za modernu web-aplikaciju.

Značajke poput izlaganja više aplikacija na jednoj IP adresi, definiranja ruta itd.

Dakle, shvatimo ove značajke za ostatak članka:

Ulaz za jednu uslugu

Ovo je najjednostavnija verzija izlaganja jedne usluge poput web sučelja s IP-om (ili imenom domene) i zadanim HTTP i HTTPS priključcima (i.e, 80 i 443).

Pojedinačni fanout

Ovo je postavka ulaza koja vam omogućuje dopuštanje dolaznog prometa na jednu IP adresu i usmjeravanje na više usluga.

Sastoji se od:

• Ulazni resurs sastoji se od imena hosta foo.bar.com
• Popis staza na kojima će se promet usmjeravati poput foo-a.bar.com / admin foo.bar.com / home foo.bar.com / sso

Pojedinačni odlaz je slučaj kada se jedan IP koristi za više usluga. Usluge mogu biti na različitim putovima u URI-u poput foo.bar.com / admin može biti usluga za administratore i foo.bar.com / home može biti usluga koja generira početnu stranicu svakog korisnika.

Ulazni priključak uvijek će biti 80 ili 443, ali priključak na kojem se izvršavaju usluge (unutar klastera) može se prilično razlikovati.

Ovakav ulaz nam pomaže smanjiti broj uravnoteživača opterećenja u klasteru, jer u osnovi djeluje poput njega.

Virtualni hosting temeljen na imenu

Javne IP adrese su ograničene. Također su prilično skupe. Ideja virtualnog hostinga temeljenog na imenu starija je od Kubernetesa. Suština je u tome što usmjeravate DNS zapise za različite web stranice poput ww1.primjer.com i ww2.primjer.com na istu IP adresu. Poslužitelj pokrenut na toj IP adresi vidjet će dolazni zahtjev i ako je ime hosta spomenuto u zahtjevu za ww1.primjer.com onda vam služi tu web stranicu, a ako ww2.primjer.com zatraži, pa se to posluži.

U kontekstu Kubernetesa možemo pokrenuti dvije usluge koje se izvode na, recimo, luci 80 i obje izložiti na jednoj IP adresi koristeći ulaz i porta 80. Na ulaznoj točki promet ww1.primjer.com će se odvojiti od prometa za ww2.primjer.com. Otuda pojam virtualni hosting zasnovan na imenu.

Zaključak

Ulazak u Kubernetes prilično je sofisticiran da bi bio pokriven u jednom postu. Postoje razni slučajevi upotrebe za to, i razni Ingress kontroleri koji će dodati Ingress funkcionalnost vašem klasteru. Preporučio bih da započnete s Nginx Ingress Controllerom.

Za daljnje detalje i specifikacije također možete slijediti službenu dokumentaciju.