Kung ikaw ay tulad ng karamihan sa mga tao, malamang na gumagamit ka ng mga mapagkukunan na tumatakbo sa labas ng iyong cluster. Marahil ay ginagamit mo ang Taleo API upang magpadala ng mga text message, o magsuri ng mga larawan gamit ang Google Cloud Vision API.
Kung gumagamit ka ng parehong server-side na endpoint ng kahilingan sa lahat ng iyong kapaligiran at hindi planong i-migrate ang iyong mga server sa Kubernetes, ayos lang na magkaroon ng endpoint ng serbisyo sa mismong code mo. Gayunpaman, maraming iba pang mga senaryo para sa pagbuo ng mga kaganapan. Sa seryeng ito ng Kubernetes Best Practices, matututunan mo kung paano gamitin ang mga built-in na mekanismo ng Kubernetes upang tumuklas ng mga serbisyo sa loob at labas ng cluster.
Ang isang halimbawa ng isang karaniwang panlabas na serbisyo ay isang database na tumatakbo sa labas ng isang Kubernetes cluster. Hindi tulad ng mga cloud database tulad ng Google Cloud Data Store o Google Cloud Spanner, na gumagamit ng iisang endpoint para sa lahat ng access, karamihan sa mga database ay may magkakahiwalay na endpoint para sa iba't ibang sitwasyon.
Ang pinakamahuhusay na kagawian para sa paggamit ng mga tradisyunal na database gaya ng MySQL at MongoDB ay karaniwang nangangahulugan na kumonekta ka sa iba't ibang bahagi para sa iba't ibang kapaligiran. Maaari kang magkaroon ng malaking makina para sa data ng produksyon at mas maliit na makina para sa kapaligiran ng pagsubok. Ang bawat isa sa kanila ay magkakaroon ng sarili nitong IP address o domain name, ngunit malamang na hindi mo nais na baguhin ang iyong code kapag lumipat mula sa isang kapaligiran patungo sa isa pa. Kaya sa halip na hard-coding ang mga address na ito, maaari mong gamitin ang built-in na DNS-based na pagtuklas ng external na serbisyo ng Kubernetes sa parehong paraan tulad ng mga native na serbisyo ng Kubernetes.
Sabihin nating nagpapatakbo ka ng database ng MongoDB sa Google Compute Engine. Ikaw ay maiipit sa hybrid na mundong ito hanggang sa magawa mong ilipat ito sa cluster.
Sa kabutihang-palad, maaari mong gamitin ang mga static na serbisyo ng Kubernetes upang gawing mas madali ang iyong buhay. Sa halimbawang ito, gumawa ako ng MongoDB server gamit ang Google Cloud Launcher. Dahil nilikha ito sa parehong network (o Kubernetes cluster VPC), ina-access ito gamit ang isang mataas na pagganap na panloob na IP address.
Ito ang default na setting sa Google Cloud, kaya hindi mo kailangang mag-configure ng anuman. Ngayon na mayroon kang isang IP address, ang unang hakbang ay upang lumikha ng isang serbisyo. Maaari mong mapansin na walang mga tagapili ng pod para sa serbisyong ito. Ibig sabihin, gumawa kami ng serbisyo na hindi alam kung saan magpapadala ng trapiko. Papayagan ka nitong manu-manong lumikha ng endpoint object na makakatanggap ng trapiko mula sa serbisyong ito.
Ipinapakita ng sumusunod na halimbawa ng code na tinutukoy ng mga endpoint ang IP address para sa database gamit ang parehong pangalan ng mongo bilang serbisyo.
Gagamitin ng Kubernetes ang lahat ng IP address para maghanap ng mga endpoint na parang regular na Kubernetes Pod, kaya ngayon ay maa-access mo na ang database gamit ang isang simpleng string ng koneksyon sa pangalan sa itaas na mongodb://mongo. Hindi na kailangang gumamit ng mga IP address sa iyong code sa lahat.
Kung magbabago ang mga IP address sa hinaharap, maaari mo lamang i-update ang iyong mga endpoint gamit ang bagong IP address at hindi na kailangang baguhin ang iyong mga application sa anumang karagdagang paraan.
Kung gumagamit ka ng database na naka-host sa isang third-party na host, malamang na ang mga may-ari ng host ay nagbigay sa iyo ng Uniform Resource Identifier URI upang kumonekta. Kaya kung nabigyan ka ng IP address, maaari mo lamang gamitin ang nakaraang paraan. Ipinapakita ng halimbawang ito na mayroon akong dalawang database ng MongoDB na naka-host sa isang mLab host.
Ang isa ay ang database ng pag-unlad at ang isa ay ang database ng produksyon. Ang mga string ng koneksyon para sa mga database na ito ay ganito ang hitsura - ang mLab ay nagbibigay sa iyo ng isang dynamic na URI at isang dynamic na port. Tulad ng nakikita mo, iba sila.
Para mawala ito, gamitin natin ang Kubernetes at kumonekta sa database ng developer. Maaari kang lumikha ng panlabas na pangalan ng serbisyo ng Kubernetes, na magbibigay sa iyo ng static na serbisyo na magpapasa ng trapiko sa panlabas na serbisyo.
Ang serbisyong ito ay magsasagawa ng simpleng pagpapasa ng CNAME sa antas ng kernel na may kaunting epekto sa pagganap. Salamat dito maaari kang gumamit ng isang mas simpleng string ng koneksyon.
Ngunit dahil ang panlabas na pangalan ay gumagamit ng pagpapasa ng CNAME, hindi ito maaaring magsagawa ng pagpapasa ng port. Samakatuwid, ang solusyon na ito ay naaangkop lamang para sa mga static na port at hindi maaaring gamitin sa mga dynamic na port. Ngunit ang mLab Free Tier ay nagbibigay sa user ng dynamic na port number bilang default at hindi mo ito mababago. Nangangahulugan ito na kailangan mo ng iba't ibang mga linya ng command ng koneksyon para sa dev at prod. Ang masamang bagay ay kakailanganin mong i-hardcode ang numero ng port. Kaya paano mo gagana ang port forwarding?
Ang unang hakbang ay upang makuha ang IP address mula sa URI. Kung magpapatakbo ka ng nslookup, hostname, o ping sa URI, maaari mong makuha ang IP address ng database. Kung ang serbisyo ay nagbabalik ng ilang IP address sa iyo, ang lahat ng mga address na ito ay maaaring gamitin sa mga endpoint ng object.
Ang isang bagay na dapat tandaan ay ang mga IP URI ay maaaring magbago nang walang abiso, na ginagawa itong medyo delikado na gamitin sa prod. Gamit ang IP address na ito, maaari kang kumonekta sa isang malayuang database nang hindi tinukoy ang isang port. Kaya, ang serbisyo ng Kubernetes ay nagsasagawa ng port forwarding nang malinaw.
Ang pagmamapa, o pagmamapa ng mga panlabas na mapagkukunan sa mga panloob, ay nagbibigay sa iyo ng flexibility na gamitin ang mga serbisyong ito sa loob ng cluster sa hinaharap habang pinapaliit ang mga pagsisikap sa refactoring. Pinapadali din nito ang pamamahala at pagbibigay ng insight sa kung anong mga panlabas na serbisyo ang ginagamit ng iyong kumpanya.
Itutuloy sa lalong madaling panahon...
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com