„Kubernetes“ turi daug judančių dalių. To reikia tikėtis iš bet kurio modelio, skirto paskirstytam skaičiavimui. Norėdami ištirti, ką „Kubernetes Ingress“ padeda mums pasiekti, pirmiausia pakartokime keletą svarbių detalių apie tipišką „Kubernetes“ grupę:

„Kubernetes“ sankaupoje įdiegta programa veikia kaip rinkinio dėklai.
Ankštys iš esmės yra konteineriai, suplanuoti keliuose mazguose.
Mazgai gali būti fiziniai serveriai arba VM, kuriuos siūlo jūsų prieglobos paslaugų teikėjas. Aišku, jei norite, „Kubernetes“ galite naudoti ir vietos serveryje.
Kiekvienas „Pod“ turi unikalų IP adresą.
Jūsų programa yra suskirstyta į daugelį komponentų, dažnai vadinamų mikropaslaugomis.
Kiekvienai jūsų programos mikro paslaugai turite atitinkamą paslaugą „Kubernetes“.
„Kubernetes“ kontekste a Aptarnavimas atskleidžia ankščių kolekciją likusiai grupei kaip vieną abstrakciją. Vienas virtualus IP.
Tai padeda vienai jūsų programos tarnybai bendrauti su kita tarnyba. Tai abstrakcija, leidžianti jums adresuoti podkų rinkinį, o ne nurodyti pod adreso IP adresą, visada, kai tik norite su juo kalbėtis.
„Kubernetes“ tarnyba taip pat veikia kaip visų jos atstovaujamų ankščių apkrova. Eismas paskirstomas tolygiai visuose mazguose.

Kol kas viskas gerai. Kiekviena tarnyba gali kalbėtis su kita tarnyba. Šis ryšys įmanomas visame „Kubernetes“ klasteryje

Demonstravimo paslaugos

„Jei medis krenta miške ir šalia jo niekas negirdi, ar jis skleidžia garsą?“

Panašiai pažymėtina, kad jei jūsų programa neatlieka tikslo už „Kubernetes“ sankaupos ribų, ar tikrai svarbu, ar klasteris yra gerai pastatytas, ar ne? Tikriausiai ne.

Pateiksime konkretų pavyzdį, tarkime, kad mes turime klasikinę žiniatinklio programą, susidedančią iš „Nodejs“ parašytos priekinės dalies ir „Python“ parašytos „backend“, kuri naudoja „MySQL“ duomenų bazę. Jūs įdiegiate dvi atitinkamas paslaugas savo „Kubernetes“ klasteryje.

Jūs darote „Dockerfile“ nurodydami, kaip supakuoti priekinės programos programinę įrangą į konteinerį, ir panašiai pakuojate savo vidinę programą. Toliau savo „Kubernetes“ grupėje dislokuosite dvi tarnybas, kurių kiekviena veiks už jos. Žiniatinklio tarnyba gali bendrauti su duomenų bazių grupe ir atvirkščiai.

Tačiau „Kubernetes“ nė vienai iš šių paslaugų (kurios yra būtinas HTTP galinis taškas) neatskleidžia viso pasaulio. Kaip teigiama oficialiuose dokumentuose:

„Laikoma, kad paslaugos turi virtualius IP, kurie gali būti nukreipiami tik grupių tinkle“

Saugumo požiūriu tai yra visiškai pagrįsta, jūsų paslaugos gali kalbėtis tarpusavyje, tačiau klasteris neleis išorės subjektams tiesiogiai kalbėti su tarnybomis. Pavyzdžiui, tik jūsų žiniatinklio sąsaja gali susisiekti su duomenų bazės tarnyba, o niekas kitas net negali siųsti užklausų duomenų bazės tarnybai.

Problema kyla, kai žiūrime į „frontend“ paslaugos naudojimo atvejį. Ji turi būti matoma likusiai visuomenei, kad galutiniai vartotojai galėtų naudoti jūsų programą. Tokias paslaugas atskleidžiame naudodami „Kubernetes Ingress“.

Kubernetes Ingress

„Ingress“ atskleidžia HTTP ir HTTPS maršrutus iš klasterio ribų į klasterio paslaugas. Maršrutavimo taisykles galite valdyti apibrėždami „Kubernetes Ingress“ šaltinį. Bet tai daro daug daugiau. Atskleisti vieną paslaugą galima naudojant įvairias kitas alternatyvas, tokias kaip „NodePort“ ar „Load Balansers“, tačiau šiose funkcijose nėra pakankamai modernios žiniatinklio programos funkcijų.

Tokios funkcijos kaip kelių programų atskleidimas viename IP, maršrutų nustatymas ir kt.

Taigi supraskime šias likusio straipsnio funkcijas:

Vienos paslaugos patekimas

Tai paprasčiausia vienos paslaugos, pvz., Žiniatinklio sąsajos su IP (arba domeno pavadinimu) ir numatytųjų HTTP ir HTTPS prievadų (i.e, 80 ir 443).

Vienvietis „Fanout“

Tai patekimo sąranka, leidžianti leisti įeinantį srautą į vieną IP ir nukreipti jį į kelias paslaugas.

Tai susideda iš:

Patekimo šaltinį sudaro pagrindinio kompiuterio vardas foo.baras.com
Kelių, kuriuose eismas bus nukreiptas kaip foo, sąrašas.baras.com / admin foo.baras.com / home foo.baras.com / sso

Vienas „fanout“ yra atvejis, kai vienas IP naudojamas kelioms paslaugoms. Paslaugos gali būti skirtingais URI keliais, pavyzdžiui, foo.baras.„com / admin“ gali būti paslauga administratoriams ir foo.baras.„com / home“ gali būti paslauga, generuojanti kiekvieno vartotojo pagrindinį puslapį.

Patekimo prievadas visada bus 80 arba 443, tačiau uostas, kuriame veikia paslaugos (klasterio viduje), gali skirtis.

Toks įsiskverbimas padeda mums sumažinti apkrovos balanserių skaičių klasteryje, nes jis iš esmės veikia kaip vienas.

Vardas pagrįstas virtualusis hostingas

Viešieji IP adresai yra riboti. Jie taip pat yra gana brangūs. Vardais pagrįsto virtualaus prieglobos idėja yra senesnė nei „Kubernetes“. Esmė ta, kad nurodote skirtingų svetainių, pvz., „W1“, DNS įrašus.pavyzdys.com ir w2.pavyzdys.com tuo pačiu IP adresu. Tuo IP adresu veikiantis serveris matys gaunamą užklausą ir, jei prašyme minimas pagrindinio kompiuterio vardas yra skirtas ww1.pavyzdys.„com“ tada jums aptarnauja tą svetainę, o jei „ww2“.pavyzdys.com yra prašoma, tada jis yra įteiktas.

„Kubernetes“ kontekste galime paleisti dvi tarnybas, veikiančias, tarkim, 80 prievadą, ir apžiūrėti abi jas vienu IP adresu, taip pat patekus į 80 prievadą. Įėjimo vietoje ww1 srautas.pavyzdys.„com“ bus atskirta nuo „ww2“ srauto.pavyzdys.com. Taigi terminas pavadinimu pagrįstas virtualusis priegloba.

Išvada

Ingresas Kubernetes yra gana rafinuotas, kad būtų apipintas vienu pranešimu. Yra įvairių naudojimo atvejų ir įvairių „Ingress“ valdiklių, kurie pridės „Ingress“ funkciją prie jūsų grupės. Aš rekomenduočiau pradėti nuo „Nginx Ingress Controller“.

Norėdami gauti daugiau informacijos ir specifikacijas, taip pat galite vadovautis oficialiais dokumentais.