Če ste podobni večini ljudi, verjetno uporabljate vire, ki delujejo zunaj vašega klasterja. Mogoče uporabljate API Taleo za pošiljanje besedilnih sporočil ali analizirate slike s pomočjo API Google Cloud Vision.
Če uporabljate isto končno točko endpoint — točko za sprejemanje zahtevkov na strežniški strani v vseh svojih okoljih in ne načrtujete prenosa svojih strežnikov v Kubernetes, je povsem v redu imeti endpoint storitve neposredno v vašem kodi. Vendar pa obstaja veliko drugih scenarijev. V tej seriji „Kubernetes Best Practices“ boste izvedeli, kako uporabiti vgrajene mehanizme Kubernetes za odkrivanje storitev tako znotraj kot zunaj klasterja.
Za primer dobro znane zunanje storitve lahko navedemo bazo podatkov, ki deluje zunaj klasterja Kubernetes. V nasprotju s takšnimi oblačnimi bazami podatkov, kot sta Google Cloud Data Store ali Google Cloud Spanner, ki uporabljata eno končno točko za vse vrste dostopa, ima večina baz podatkov ločene končne točke za različne okoliščine.
Najboljše prakse pri uporabi tradicionalnih baz podatkov, kot sta MySQL in MongoDB, običajno predvidevajo, da se povezujete na različne komponente za različna okolja. Morda imate večji stroj za proizvodne podatke in manjši stroj za testno okolje. Vsaka od njih bo imela svoj IP naslov ali domeno, vendar zagotovo ne želite spreminjati svoje kode, ko prehajate iz enega okolja v drugo. Zato namesto trdega kodiranja teh naslovov lahko uporabite vgrajeno odkrivanje zunanjih storitev v Kubernetesu na osnovi DNS, prav tako kot za naravne storitve Kubernetes.
Recimo, da zaženete bazo podatkov MongoDB v Google Compute Engine. Priklenili boste v tem hibridnem svetu, dokler je ne boste uspeli prenesti v klaster.
Na srečo lahko uporabite statične storitve Kubernetes, da si nekoliko olajšate življenje. V tem primeru sem ustvaril strežnik MongoDB z uporabo Google Cloud Launcher. Ker je ustvarjen v isti omrežni (ali VPC klasterja Kubernetes), je dostop do njega omogočen s pomočjo visoko zmogljivega notranjega IP naslova.
V Google Cloud je to privzeta nastavitev, zato vam ni treba ničesar nastaviti. Zdaj, ko imamo IP naslov, je prvi korak ustvariti storitev. Opaziti je mogoče, da za to storitev ni selektorjev vozlišč. To pomeni, da smo ustvarili storitev, ki ne bo vedela, kam poslati promet. To bo omogočilo ročno ustvarjanje objekta končne točke, ki bo prejemal promet od te storitve.
Naslednji primer kode prikazuje, da končne točke določajo IP naslov za podatkovno bazo, ki uporablja isto ime mongo kot storitev.
Kubernetes bo uporabil vse IP naslove, da najde končne točke, kot da bi bile običajna vozlišča Kubernetes, tako da zdaj lahko dostopate do podatkovne baze z enostavno povezovalno vrstico do zgoraj navedenega imena mongodb://mongo. Pri tem ni treba uporabljati IP naslovov v vaši kodi.
Če se v prihodnosti IP naslovi spremenijo, lahko preprosto posodobite končne točke z novim IP naslovom, in vaših aplikacij ni treba dodatno spreminjati.
Če uporabljate podatkovno bazo, gostovano na zunanjih strežnikih, so vam verjetno lastniki gostiteljskih storitev zagotovili univerzalni identifikator vira URI za povezovanje. Tako, če ste dobili IP naslov, lahko preprosto uporabite prejšnjo metodo. Ta primer prikazuje, da imam dve podatkovni bazi MongoDB, gostovani na strežniku mLab.
Ena izmed njiju je podatkovna baza razvijalcev, druga pa je produkcijska BDP. Povezovalne vrstice za ti dve podatkovni bazi izgledajo takole — mLab vam zagotovi dinamični URI in dinamično pristanišče. Kot vidite, sta različni.
Da bi se od tega abstrahirali, uporabite Kubernetes in se povežite s podatkovno bazo razvijalcev. Lahko ustvarite zunanje ime storitve Kubernetes, ki vam bo dalo statično storitev, ki bo preusmerila promet zunanji storitvi.
Ta storitev bo izvedla preprosto CNAME preusmerjanje na ravni jedra, kar bo imelo minimalen vpliv na zmogljivost. Tako lahko uporabite enostavnejšo povezovalno vrstico.
Toda pače so externi naziv uporablja preusmeritev CNAME, ne more izvesti preusmeritve vrat. Zato je ta rešitev uporabna le za statična vrata in je ne moremo uporabiti z dinamičnimi vrati. Brezplačni mLab Free Tier pa privzeto uporabniku dodeli dinamično številko vrat, tega ne morete spremeniti. To pomeni, da potrebujete različne povezovalne ukaze za dev in prod. Slabo je, da bo potrebno trdo kodirati številko vrat. Kako torej omogočiti delovanje preusmeritve vrat?
Prvi korak je pridobitev IP-naslova iz URI. Če izvedete ukaz nslookup, hostname ali pingate URI, lahko pridobite IP-naslov baze podatkov. Če storitev vrne več IP-naslovov, lahko vse te naslove uporabite v končnih točkah objekta.
Treba je vedeti, da se IP-naslovi URI lahko spremenijo brez predhodnega obvestila, zato je njihova uporaba v prod zapletena. S takim IP-naslovom se lahko povežete z oddaljeno bazo podatkov, ne da bi pri tem navedli vrata. Tako storitev Kubernetes zelo transparentno izvaja preusmeritev vrat.
Mapping ali usklajevanje zunanjih virov z notranjimi vam omogoča prilagodljivo uporabo teh storitev znotraj klustra v prihodnosti ob minimalnih naporih pri refaktoringu. Prav tako olajša upravljanje in daje razumevanje, katerih zunanjih storitev vaša podjetja uporablja.
Nadaljevanje kmalu...
Malo reklame 🙂
Hvala što ostajete s nama. Da li vam se sviđaju naši članci? Želite li videti više zanimljivih materijala? Podržite nas tako što ćete naručiti ili preporučiti prijateljima, , jedinstveni ekvivalent entry-level servera koji smo stvorili za vas: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd je dvostruko jeftiniji u Equinix Tier IV data centru u Amsterdamu? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Izvor: habr.com
