Jende gehiena bezalakoa bazara, ziurrenik zure clusterretik kanpo exekutatzen diren baliabideak erabiltzen ari zara. Agian Taleo APIa erabiltzen duzu testu-mezuak bidaltzeko edo irudiak aztertzeko Google Cloud Vision APIa erabiliz.
Zure ingurune guztietan zerbitzariaren aldeko eskaera-puntu bera erabiltzen baduzu eta ez baduzu zure zerbitzariak Kubernetesera migratzeko asmorik, ezin hobeto dago zerbitzuaren amaiera-puntu bat zure kodean bertan edukitzea. Hala ere, gertakarien garapenerako beste eszenatoki asko daude. Kubernetes Praktika Onen serie honetan, Kubernetesen barneko mekanismoak nola erabiltzen ikasiko duzu kluster barruan zein kanpoan zerbitzuak ezagutzeko.
Kanpoko zerbitzu arrunt baten adibide bat Kubernetes kluster batetik kanpo exekutatzen den datu-base bat da. Google Cloud Data Store edo Google Cloud Spanner bezalako hodeiko datu-baseek ez bezala, azken puntu bakarra erabiltzen baitute sarbide guztietarako, datu-base gehienek egoera ezberdinetarako amaierako puntu bereiziak dituzte.
MySQL eta MongoDB bezalako datu-base tradizionalak erabiltzeko praktika onek ingurune desberdinetarako osagai desberdinetara konektatzen zarela esan nahi dute normalean. Makina handi bat izan dezakezu ekoizpen-datuetarako eta makina txikiagoa proba-ingurunerako. Horietako bakoitzak bere IP helbidea edo domeinu izena izango du, baina ziurrenik ez duzu zure kodea aldatu nahi ingurune batetik bestera mugitzean. Beraz, helbide hauek gogor kodetu beharrean, Kubernetes-en DNS barnean oinarritutako kanpoko zerbitzuen aurkikuntza erabil dezakezu Kubernetes jatorrizko zerbitzuen modu berean.
Demagun MongoDB datu-base bat exekutatzen ari zarela Google Compute Engine-n. Mundu hibrido honetan geratuko zara klusterera transferitzea lortu arte.
Zorionez, Kubernetes zerbitzu estatikoak erabil ditzakezu zure bizitza apur bat errazteko. Adibide honetan, MongoDB zerbitzari bat sortu nuen Google Cloud Launcher erabiliz. Sare berean (edo Kubernetes kluster VPC) sortzen denez, errendimendu handiko barne IP helbide bat erabiliz sartzen da.
Hau Google Cloud-en ezarpen lehenetsia da, beraz, ez duzu ezer konfiguratu beharrik. Orain IP helbidea duzunean, lehen urratsa zerbitzu bat sortzea da. Konturatuko zara zerbitzu honetarako pod hautatzailerik ez dagoela. Hau da, trafikoa nora bidali jakingo ez duen zerbitzu bat sortu dugu. Honek zerbitzu honen trafikoa jasoko duen amaierako objektu bat eskuz sortzeko aukera emango dizu.
Hurrengo kode-adibide honek erakusten du amaierako puntuek datu-basearen IP helbidea zehazten dutela zerbitzuaren mongo izen bera erabiliz.
Kubernetes-ek IP helbide guztiak erabiliko ditu amaiera-puntuak aurkitzeko Kubernetes Pods arruntak balira bezala, beraz, orain datu-basera sar zaitezke goiko mongodb://mongo izenarekin konexio-kate soil batekin. Ez dago zure kodean IP helbideak erabili beharrik.
Etorkizunean IP helbideak aldatzen badira, zure amaierako puntuak IP helbide berriarekin egunera ditzakezu eta zure aplikazioak ez dira inola ere aldatu beharko.
Hirugarrenen ostalari batean ostatatutako datu-base bat erabiltzen ari bazara, baliteke ostalariaren jabeek konektatzeko Baliabide Identifikatzaile Uniformeko URI bat ematea. Beraz, IP helbide bat eman badizute, aurreko metodoa erabil dezakezu. Adibide honek erakusten du bi MongoDB datu-base ditudala mLab ostalari batean.
Bata garatzaileen datu-basea da eta bestea ekoizpen datu-basea. Datu-base hauetarako konexio-kateek itxura hau dute - mLab-ek URI dinamikoa eta ataka dinamikoa eskaintzen dizkizu. Ikusten duzuenez, desberdinak dira.
Hau abstraitzeko, erabil dezagun Kubernetes eta konektatu garatzaileen datu-basera. Kanpoko Kubernetes zerbitzuaren izena sor dezakezu, eta horrek kanpoko zerbitzura trafikoa birbidaliko duen zerbitzu estatiko bat emango dizu.
Zerbitzu honek CNAME birbidaltze sinplea egingo du nukleo mailan, errendimendu-eragin minimoarekin. Horri esker, konexio-kate sinpleagoa erabil dezakezu.
Baina kanpoko izenak CNAME birbidaltzea erabiltzen duenez, ezin du portuen birbidaltzea egin. Hori dela eta, irtenbide hau portu estatikoetarako soilik da aplikagarria eta ezin da portu dinamikoekin erabili. Baina mLab Free Tier-ek erabiltzaileari ataka-zenbaki dinamiko bat ematen dio lehenespenez eta ezin duzu aldatu. Horrek esan nahi du konexio-komando-lerro desberdinak behar dituzula dev eta prod-erako. Gauza txarra da honek ataka-zenbakia gogor kodetu beharko duzula. Beraz, nola lortzen duzu portuaren birbidaltzea funtzionatzen?
Lehen urratsa URItik IP helbidea lortzea da. nslookup, ostalari-izena edo URIa ping egiten baduzu, datu-basearen IP helbidea lor dezakezu. Zerbitzuak hainbat IP helbide itzultzen badizu, orduan helbide horiek guztiak objektuaren amaierako puntuetan erabil daitezke.
Kontuan izan beharreko gauza bat da IP URIak abisurik gabe alda daitezkeela, produktuan erabiltzeko nahiko arriskutsuak direlarik. IP helbide hau erabiliz, urruneko datu-base batera konekta zaitezke atakarik zehaztu gabe. Horrela, Kubernetes zerbitzuak portuen birbidalketa nahiko gardena egiten du.
Kartografiak edo kanpoko baliabideak barnekoekin mapatzeak malgutasuna ematen dizu etorkizunean zerbitzu hauek klusterraren barruan erabiltzeko, birfactorizazio ahaleginak gutxituz. Gainera, zure enpresak zer kanpoko zerbitzuak erabiltzen dituen kudeatzea eta ezagutzea errazten du.
Oso laster jarraitzeko...
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com