Habang sinisimulan mong lumikha ng parami nang parami ng mga serbisyo ng Kubernetes, ang mga gawain na sa una ay simple ay magsisimulang maging mas kumplikado. Halimbawa, ang mga development team ay hindi makakagawa ng mga serbisyo o deployment sa ilalim ng parehong pangalan. Kung mayroon kang libu-libong pod, ang paglilista lang sa mga ito ay aabutin ng maraming oras, lalo pa ang tamang pamamahala sa mga ito. At ito lamang ang dulo ng malaking bato ng yelo.
Tingnan natin kung paano pinapadali ng namespace na pamahalaan ang mga mapagkukunan ng Kubernetes. Kaya ano ang isang namespace? Maaaring isipin ang namespace bilang isang virtual na cluster sa loob ng iyong Kubernetes cluster. Maaari kang magkaroon ng maraming namespace na nakahiwalay sa isa't isa sa loob ng iisang Kubernetes cluster. Talagang makakatulong sila sa iyo at sa iyong mga team sa organisasyon, seguridad, at maging sa performance ng system.
Sa karamihan ng mga distribusyon ng Kubernetes, ang cluster ay lalabas sa kahon na may namespace na tinatawag na "default". Mayroong talagang tatlong namespace na pinag-uusapan ng Kubernetes: default, kube-system, at kube-public. Sa kasalukuyan, hindi masyadong madalas na ginagamit ang Kube-public.
Ang pag-iwan sa namespace ng kube ay isang magandang ideya, lalo na sa isang pinamamahalaang system tulad ng Google Kubernetes Engine. Ginagamit nito ang "default" na namespace bilang lugar kung saan nilikha ang iyong mga serbisyo at application. Talagang walang espesyal tungkol dito, maliban na ang Kubernetes ay na-configure sa labas ng kahon upang gamitin ito, at hindi mo ito maaalis. Ito ay mahusay para sa pagsisimula at mababang pagganap ng mga system, ngunit hindi ko inirerekomenda ang paggamit ng default na namespace sa malalaking prod system. Sa huling kaso, ang isang development team ay madaling muling magsulat ng code ng ibang tao at masira ang trabaho ng isa pang team nang hindi man lang ito napagtatanto.
Samakatuwid, dapat kang lumikha ng maraming namespace at gamitin ang mga ito upang i-segment ang iyong mga serbisyo sa mga napapamahalaang unit. Ang isang namespace ay maaaring malikha gamit ang isang utos. Kung gusto mong gumawa ng namespace na pinangalanang pagsubok, pagkatapos ay gamitin ang command na $ kubectl create namespace test o gumawa lang ng YAML file at gamitin ito tulad ng ibang mapagkukunan ng Kubernetes.
Maaari mong tingnan ang lahat ng namespace gamit ang $ kubectl get namespace command.
Kapag tapos na ito, makakakita ka ng tatlong built-in na namespace at isang bagong namespace na tinatawag na "pagsubok". Tingnan natin ang isang simpleng YAML file para gumawa ng pod. Mapapansin mo na walang binanggit na namespace.
Kung gagamit ka ng kubectl upang patakbuhin ang file na ito, lilikha ito ng mypod module sa kasalukuyang aktibong namespace. Ito ang magiging default na namespace hanggang sa baguhin mo ito. Mayroong 2 paraan para sabihin sa Kubernetes kung saang namespace mo gustong gawin ang iyong mapagkukunan. Ang unang paraan ay ang paggamit ng flag ng namespace kapag gumagawa ng mapagkukunan.
Ang pangalawang paraan ay ang tukuyin ang namespace sa deklarasyon ng YAML.
Kung tumukoy ka ng namespace sa YAML, palaging gagawin ang mapagkukunan sa namespace na iyon. Kung susubukan mong gumamit ng ibang namespace habang ginagamit ang flag ng namespace, mabibigo ang command. Ngayon kung susubukan mong hanapin ang iyong pod, hindi mo ito magagawa.
Nangyayari ito dahil ang lahat ng mga utos ay isinasagawa sa labas ng kasalukuyang aktibong namespace. Upang mahanap ang iyong pod, kailangan mong gumamit ng flag ng namespace, ngunit mabilis itong nakakabagot, lalo na kung isa kang developer sa isang team na gumagamit ng sarili nitong namespace at ayaw mong gamitin ang flag na iyon para sa bawat command. Tingnan natin kung paano natin ito maaayos.
Sa labas ng kahon, ang iyong aktibong namespace ay tinatawag na default. Kung hindi ka tumukoy ng namespace sa resource na YAML, gagamitin ng lahat ng Kubernetes command ang aktibong default na namespace na ito. Sa kasamaang palad, maaaring mabigo ang pagsisikap na pamahalaan ang aktibong namespace gamit ang kubectl. Gayunpaman, mayroong isang napakahusay na tool na tinatawag na Kubens na ginagawang mas madali ang prosesong ito. Kapag pinatakbo mo ang kubens command, makikita mo ang lahat ng namespace na may naka-highlight na aktibong namespace.
Upang ilipat ang aktibong namespace sa test namespace, patakbuhin mo lang ang $kubens test command. Kung patakbuhin mo muli ang $kubens command, makikita mo na ang isang bagong aktibong namespace ay inilalaan na ngayon - pagsubok.
Nangangahulugan ito na hindi mo kailangan ang namespace flag para makita ang pod sa test namespace.
Sa ganitong paraan ang mga namespace ay nakatago sa isa't isa, ngunit hindi nakahiwalay sa isa't isa. Ang isang serbisyo sa isang namespace ay madaling makipag-ugnayan sa isang serbisyo sa isa pang namespace, na kadalasang lubhang kapaki-pakinabang. Ang kakayahang makipag-usap sa iba't ibang namespace ay nangangahulugan na ang serbisyo ng iyong mga developer ay maaaring makipag-ugnayan sa serbisyo ng isa pang dev team sa ibang namespace.
Kadalasan, kapag gusto ng iyong application na mag-access ng serbisyo ng Kubernetes, ginagamit mo ang built-in na DNS discovery na serbisyo at ibibigay lang sa iyong application ang pangalan ng serbisyo. Gayunpaman, sa paggawa nito, maaari kang lumikha ng isang serbisyo sa ilalim ng parehong pangalan sa maraming mga namespace, na hindi katanggap-tanggap.
Sa kabutihang-palad, ito ay madaling makalibot sa pamamagitan ng paggamit ng pinalawak na anyo ng DNS address. Inilalantad ng mga serbisyo sa Kubernetes ang kanilang mga endpoint gamit ang isang karaniwang template ng DNS. Mukhang ganito:
Karaniwan, kailangan mo lang ng pangalan ng serbisyo at awtomatikong matutukoy ng DNS ang buong address.
Gayunpaman, kung kailangan mong mag-access ng isang serbisyo sa ibang namespace, gamitin lang ang pangalan ng serbisyo kasama ang pangalan ng namespace:
Halimbawa, kung gusto mong kumonekta sa isang database ng serbisyo sa isang namespace ng pagsubok, maaari mong gamitin ang database ng address database.test
Kung gusto mong kumonekta sa database ng serbisyo sa namespace ng prod, gumamit ka ng database.prod.
Kung talagang gusto mong ihiwalay at paghigpitan ang pag-access sa namespace, pinapayagan ka ng Kubernetes na gawin ito gamit ang Mga Patakaran sa Network ng Kubernetes. Pag-uusapan ko ito sa susunod na episode.
Madalas akong tinatanong ng tanong, ilang namespace ang dapat kong gawin at para sa anong layunin? Ano ang isang pinamamahalaang piraso ng data?
Kung gagawa ka ng masyadong maraming namespaces, makakasagabal lang ang mga ito sa iyong paraan. Kung napakakaunti sa kanila, mawawala sa iyo ang lahat ng mga benepisyo ng naturang solusyon. Sa tingin ko mayroong apat na pangunahing yugto na pinagdadaanan ng bawat kumpanya kapag lumilikha ng istraktura ng organisasyon nito. Depende sa yugto ng pagbuo ng iyong proyekto o kumpanya, maaaring gusto mong gumamit ng naaangkop na diskarte sa namespace.
Isipin na ikaw ay bahagi ng isang maliit na koponan na nagtatrabaho sa pagbuo ng 5-10 microservice at madali mong matipon ang lahat ng mga developer sa isang silid. Sa sitwasyong ito, makatuwirang patakbuhin ang lahat ng serbisyo ng prod sa default na namespace. Siyempre, para sa higit na kakayahang umangkop, maaari kang gumamit ng 2 namespace - hiwalay para sa prod at dev. At malamang, sinubukan mo ang iyong pag-unlad sa iyong lokal na computer gamit ang isang bagay tulad ng Minikube.
Sabihin nating nagbabago ang mga bagay-bagay at mayroon ka na ngayong mabilis na lumalagong team na nagtatrabaho sa higit sa 10 microservice sa isang pagkakataon. Darating ang panahon na kailangang gumamit ng ilang cluster o namespace, nang hiwalay para sa prod at dev. Maaari mong hatiin ang koponan sa ilang mga sub-team upang ang bawat isa sa kanila ay may sarili nitong mga microservice at ang bawat isa sa mga koponang ito ay maaaring pumili ng sarili nitong namespace upang mapadali ang proseso ng pamamahala ng software development at release.
Habang nagkakaroon ng insight ang bawat miyembro ng team sa kung paano gumagana ang system sa kabuuan, nagiging mas mahirap i-coordinate ang bawat pagbabago sa lahat ng iba pang developer. Ang pagsisikap na paikutin ang isang buong stack sa iyong lokal na makina ay nagiging mas mahirap araw-araw.
Sa malalaking kumpanya, karaniwang hindi alam ng mga developer kung sino ang eksaktong nagtatrabaho sa kung ano. Ang mga koponan ay nakikipag-usap gamit ang mga kontrata ng serbisyo o gumagamit ng teknolohiya ng mesh ng serbisyo, na nagdaragdag ng abstraction layer sa network, gaya ng tool sa pagsasaayos ng Istio. Ang pagsisikap na magpatakbo ng isang buong stack sa lokal ay hindi posible. Lubos kong inirerekomenda ang paggamit ng tuluy-tuloy na paghahatid (CD) na platform tulad ng Spinnaker sa Kubernetes. Kaya, darating ang isang punto kung saan ang bawat utos ay tiyak na nangangailangan ng sarili nitong namespace. Ang bawat team ay maaaring pumili ng maraming namespace para sa dev environment at sa prod environment.
Sa wakas, may mga malalaking kumpanyang pangnegosyo kung saan hindi alam ng isang grupo ng mga developer ang pagkakaroon ng ibang mga grupo. Ang nasabing kumpanya ay karaniwang maaaring umarkila ng mga third-party na developer na nakikipag-ugnayan dito sa pamamagitan ng mga API na mahusay na dokumentado. Ang bawat naturang grupo ay naglalaman ng ilang mga koponan at ilang mga microservice. Sa kasong ito, kailangan mong gamitin ang lahat ng mga tool na napag-usapan ko kanina.
Ang mga programmer ay hindi dapat manu-manong mag-deploy ng mga serbisyo at hindi dapat magkaroon ng access sa mga namespace na walang kinalaman sa kanila. Sa yugtong ito, ipinapayong magkaroon ng ilang mga kumpol upang bawasan ang "blast radius" ng mga hindi maayos na na-configure na mga application, upang pasimplehin ang mga proseso ng pagsingil at pamamahala ng mapagkukunan.
Kaya, ang wastong paggamit ng mga namespace ng iyong organisasyon ay nagbibigay-daan sa iyong gawing mas madaling pamahalaan, nakokontrol, secure, at flexible ang Kubernetes.
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