Nëse jeni si shumica e njerëzve, është shumë e mundur të përdorni burime që funksionojnë jashtë klasterit tuaj. Ndoshta po përdorni API-në Taleo për të dërguar mesazhe ose po analizoni imazhe me API-në Google Cloud Vision.
NĂ«se po pĂ«rdorni tĂ« njĂ«jtĂ«n pikĂ« pĂ«rfundimi â pikĂ«n e pritjes sĂ« kĂ«rkesave nĂ« anĂ«n e serverit nĂ« tĂ« gjitha mjediset tuaja dhe nuk planifikoni tĂ« transferoni serverĂ«t tuaj nĂ« Kubernetes, atĂ«herĂ« Ă«shtĂ« krejtĂ«sisht nĂ« rregull tĂ« keni pikĂ«n e shĂ«rbimit direkt nĂ« kodin tuaj. MegjithatĂ«, ekzistojnĂ« shumĂ« skenarĂ« tĂ« tjerĂ«. NĂ« kĂ«tĂ« seri "Praktikat mĂ« tĂ« Mira tĂ« Kubernetes", do tĂ« mĂ«soni si tĂ« pĂ«rdorni mekanizmat e integruar tĂ« Kubernetes pĂ«r tĂ« zbuluar shĂ«rbimet si brenda ashtu edhe jashtĂ« klasterit.
Si një shembull të një shërbimi të njohur të jashtëm, mund të përmendim një bazë të dhënash që funksionon jashtë klasterit Kubernetes. Ndryshe nga bazat e të dhënave cloud si Google Cloud Data Store ose Google Cloud Spanner, të cilat përdorin një pikë të vetme për të gjitha llojet e qasjes, shumica e bazave të të dhënave kanë pika të ndara për rrethana të ndryshme.
Praktika më e mirë për përdorimin e bazave të dhënash tradicionale si MySQL dhe MongoDB zakonisht parashikon që ju të lidhni komponentë të ndryshëm për mjedise të ndryshme. Mund të keni një makinë të madhe për të dhënat prodhuese dhe një makinë më të vogël për mjedisin e testimit. Secila prej tyre do të ketë adresën e saj IP ose emrin e domainit, por me siguri nuk do të dëshironit të ndryshoni kodin tuaj kur kaloni nga një mjedis në tjetrin. Prandaj, në vend të kodeve të ngurta të këtyre adresave, mund të përdorni shërbimin e integruar të zbuluar të Kubernetes për shërbimet e jashtme në bazë të DNS, ashtu si për shërbimet natyrore të Kubernetes.
Supozoni se po ekzekutoni një bazë të dhënash MongoDB në Google Compute Engine. Do të mbeteni në këtë botë hibride derisa të arrini ta transferoni atë në klaster.
Fatmirësisht, mund të përdorni shërbime statike të Kubernetes për të lehtësuar pak jetën tuaj. Në këtë shembull kam krijuar një server MongoDB duke përdorur Google Cloud Launcher. Pasi është krijuar në të njëjtën rrjetë (ose VPC të klasterit Kubernetes), qasja në të bëhet me adresë IP të brendshme me performancë të lartë.
Në Google Cloud, kjo është konfigurimi i parazgjedhur, kështu që nuk keni nevojë të konfiguroni asgjë. Tani, kur kemi një adresë IP, hapi i parë është krijimi i shërbimit. Mund të vëreni se për këtë shërbim nuk ka selektorë podësh. Kështu, kemi krijuar një shërbim që nuk do të dijë se ku të dërgojë trafikun. Kjo do të lejojë krijimin manual të objektit endpoint, i cili do të marrë trafik nga ky shërbim.
Shembulli i mëposhtëm i kodit tregon se endpointet përcaktojnë adresën IP për bazën e të dhënave duke përdorur të njëjtin emër mongo si shërbimi.
Kubernetes do të përdorë të gjitha adresat IP për të gjetur endpointet, siç do të ishin podët normalë të Kubernetes, kështu që tani mund të qaseni në bazën e të dhënave me një varg të thjeshtë lidhjeje për emrin e mësipërm mongodb://mongo. Nuk ka nevojë për adresat IP në kodin tuaj.
Nëse ndodhi që adresat IP të ndryshojnë në të ardhmen, mund ta përditësoni thjesht endpointet me adresën e re IP, dhe aplikacionet tuaja nuk do të kenë nevojë të ndryshojnë ndonjë mënyrë të tjera.
Nëse po përdorni një bazë të dhënash të hostuar në një host të tretë, ka të ngjarë që pronarët e hostit t'ju kenë ofruar një identifikator të unifikuar të burimeve URI për lidhje. Pra, nëse ju dhanë një adresë IP, mund të përdorni thjesht metodën e mëparshme. Ky shembull tregon se kam dy baza të dhënash MongoDB të të hostuara në hostin mLab.
Njëra është baza e të dhënave për zhvilluesit, ndërsa tjetra është baza e të dhënave për prodhimin. Rrugët e lidhjes për këto baza të dhënash duken siç vijon - mLab ju ofron një URI dinamik dhe një port dinamik. Siç e shihni, ato janë të ndryshme.
Për të u abstrahuar nga kjo, ne përdorim Kubernetes dhe lidhemi me bazën e të dhënave për zhvilluesit. Mund të krijoni një emër shërbimi të jashtëm Kubernetes, i cili do t'ju ofrojë një shërbim statik që do të drejtojë trafik në shërbimin e jashtëm.
Ky shërbim do të kryejë një riciklim të thjeshtë CNAME në nivelin e bërthamës, duke e pasur ndikimin minimal në performancë. Falë kësaj, mund të përdorni një varg lidhjeje më të thjeshtë.
Por çfarëdo që emri i jashtëm përdor një ridrejtim CNAME, ai nuk mund të ketë një rimësim portesh. Prandaj, ky zgjidhje është e vlefshme vetëm për portet statike dhe nuk mund të përdoret me portet dinamike. Por plani falas i mLab Free Tier përfundimisht ofron një numër dinamik porti për përdoruesit, dhe ju nuk mund ta ndryshoni këtë. Kjo do të thotë se për dev dhe prod ju nevojiten rreshta të ndryshëm komandash lidhës. E keqja është se do të kërkohet të kodoni me ngulm numrin e portit. Pra, si ta bëni që rimësimi i portit të funksionojë?
Hapi i parë është marrja e adresës IP nga URI. Nëse kryeni komandën nslookup, hostname ose pingoni URI-në, mund të merrni adresën IP të bazës së të dhënave. Nëse shërbimi ju kthen disa adresa IP, të gjitha këto adresa mund të përdoren në pikëfundet e objektit.
Duhet të mbani mend se adresat IP të URI-së mund të ndryshojnë pa paralajmërim, kështu që është mjaft rrezikshme të përdoren në prodhimin. Me një adresë IP të tillë, mund të lidhesh në një bazë të dhënash të largët pa specifikuar portin. Në këtë mënyrë, shërbimi Kubernetes kryen rimësim portesh mjaft transparente.
Mappimi, ose përputhja e burimeve të jashtme me ato të brendshme, ju jep mundësinë për të përdorur këto shërbime brenda klasterit në të ardhmen me minimizimin e përpjekjeve për refaktorizimin. Po ashtu, e lehtëson menaxhimin dhe ofron një mirëkuptim se cilat shërbime të jashtme po përdor kompania juaj.
Do të vazhdojë shumë shpejt...
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
