Če ste kot večina ljudi, verjetno uporabljate vire, ki delujejo zunaj vaše gruče. Morda uporabljate Taleo API za pošiljanje besedilnih sporočil ali analizirate slike z Google Cloud Vision API.
Če uporabljate isto končno točko zahteve na strani strežnika v vseh svojih okoljih in ne nameravate preseliti svojih strežnikov v Kubernetes, potem je popolnoma v redu, če imate končno točko storitve neposredno v svoji kodi. Obstaja pa še veliko drugih scenarijev razvoja dogodkov. V tej seriji najboljših praks Kubernetes se boste naučili uporabljati vgrajene mehanizme Kubernetesa za odkrivanje storitev tako znotraj kot zunaj gruče.
Primer običajne zunanje storitve je zbirka podatkov, ki se izvaja zunaj gruče Kubernetes. Za razliko od zbirk podatkov v oblaku, kot sta Google Cloud Data Store ali Google Cloud Spanner, ki uporabljajo eno končno točko za ves dostop, ima večina zbirk podatkov ločene končne točke za različne okoliščine.
Najboljše prakse za uporabo tradicionalnih baz podatkov, kot sta MySQL in MongoDB, običajno pomenijo, da se povežete z različnimi komponentami za različna okolja. Lahko imate velik stroj za proizvodne podatke in manjši stroj za testno okolje. Vsak od njih bo imel svoj naslov IP ali ime domene, vendar verjetno ne boste želeli spremeniti kode, ko se premikate iz enega okolja v drugo. Torej namesto trdega kodiranja teh naslovov lahko uporabite vgrajeno odkrivanje zunanjih storitev Kubernetes, ki temelji na DNS, na enak način kot domače storitve Kubernetes.
Recimo, da uporabljate bazo podatkov MongoDB na Google Compute Engine. V tem hibridnem svetu boste obtičali, dokler ga ne uspete prenesti v gručo.
Na srečo lahko uporabite statične storitve Kubernetes, da si nekoliko olajšate življenje. V tem primeru sem ustvaril strežnik MongoDB z Google Cloud Launcherjem. Ker je ustvarjen v istem omrežju (ali v gruči Kubernetes VPC), se do njega dostopa z visoko zmogljivim notranjim naslovom IP.
To je privzeta nastavitev za Google Cloud, zato vam ni treba ničesar konfigurirati. Zdaj, ko imate naslov IP, je prvi korak ustvariti storitev. Morda boste opazili, da za to storitev ni izbirnikov podov. Se pravi, ustvarili smo storitev, ki ne bo vedela, kam poslati promet. To vam bo omogočilo ročno ustvarjanje predmeta končne točke, ki bo prejemal promet od te storitve.
Naslednji primer kode prikazuje, da končne točke določajo naslov IP za bazo podatkov z istim imenom mongo kot storitev.
Kubernetes bo uporabil vse naslove IP za iskanje končnih točk, kot da bi bili navadni Kubernetes Pods, tako da lahko zdaj dostopate do baze podatkov s preprostim povezovalnim nizom do zgornjega imena mongodb://mongo. V vaši kodi sploh ni treba uporabljati naslovov IP.
Če se naslovi IP v prihodnosti spremenijo, lahko preprosto posodobite svoje končne točke z novim naslovom IP in vaših aplikacij ne bo treba dodatno spreminjati.
Če uporabljate zbirko podatkov, ki gostuje na gostitelju tretje osebe, so vam lastniki gostitelja verjetno zagotovili URI enotnega identifikatorja vira, s katerim se lahko povežete. Če ste torej dobili naslov IP, lahko preprosto uporabite prejšnjo metodo. Ta primer kaže, da imam dve bazi podatkov MongoDB, ki gostujeta na gostitelju mLab.
Ena je baza podatkov razvijalcev, druga pa baza podatkov proizvodnje. Povezavni nizi za te zbirke podatkov so videti takole - mLab vam nudi dinamični URI in dinamična vrata. Kot lahko vidite, so različni.
Da bi to abstrahirali, uporabimo Kubernetes in se povežimo z bazo podatkov razvijalcev. Ustvarite lahko ime zunanje storitve Kubernetes, ki vam bo dalo statično storitev, ki bo posredovala promet zunanji storitvi.
Ta storitev bo izvajala preprosto posredovanje CNAME na ravni jedra z minimalnim vplivom na zmogljivost. Zahvaljujoč temu lahko uporabite enostavnejši povezovalni niz.
Ker pa zunanje ime uporablja posredovanje CNAME, ne more izvesti posredovanja vrat. Zato je ta rešitev uporabna samo za statična vrata in je ni mogoče uporabiti z dinamičnimi vrati. Toda mLab Free Tier daje uporabniku privzeto dinamično številko vrat in je ne morete spremeniti. To pomeni, da potrebujete različne ukazne vrstice za povezavo za dev in prod. Slaba stvar je, da boste morali za to vnesti številko vrat. Kako torej omogočiti, da posredovanje vrat deluje?
Prvi korak je pridobitev naslova IP iz URI-ja. Če zaženete nslookup, ime gostitelja ali ping URI, lahko dobite naslov IP baze podatkov. Če vam storitev vrne več naslovov IP, lahko vse te naslove uporabite na končnih točkah objekta.
Ena stvar, ki jo morate imeti v mislih, je, da se lahko URI-ji IP spremenijo brez predhodnega obvestila, zaradi česar je njihova uporaba v prod. S tem naslovom IP se lahko povežete z oddaljeno bazo podatkov, ne da bi navedli vrata. Tako storitev Kubernetes posredovanje vrat izvaja precej transparentno.
Preslikava ali preslikava zunanjih virov v notranje vam daje prilagodljivost za uporabo teh storitev znotraj gruče v prihodnosti, hkrati pa zmanjšuje prizadevanja za preoblikovanje. Omogoča tudi lažje upravljanje in omogoča vpogled v zunanje storitve, ki jih uporablja vaše podjetje.
Nadaljevanje kmalu ...
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com