Ndërsa filloni të krijoni gjithnjë e më shumë shërbime Kubernetes, detyrat, që në fillim ishin të thjeshta, fillojnë të bëhen të komplikuara. Për shembull, ekipet e zhvilluesve nuk mund të krijojnë shërbime ose shpërndarje me të njëjtin emër. Nëse keni mijëra pods, thjesht listimi i tyre do të zgjedhë shumë kohë, pa llogaritur menaxhimin normal të tyre. Dhe kjo është vetëm maja e ajsbergut.
Le tĂ« shqyrtojmĂ« se si hapĂ«sira e emrave (namespace) e lehtĂ«son menaxhimin e burimeve Kubernetes. ĂfarĂ« Ă«shtĂ« hapĂ«sira e emrave? Hapesira e emrave mund tĂ« konsiderohet si njĂ« klasĂ« virtuale brenda klasĂ«s tuaj Kubernetes. Mund tĂ« keni disa hapĂ«sira emrash tĂ« izoluara nga njĂ«ra-tjetra brenda njĂ« klasteri Kubernetes. Ato realisht mund tĂ« ndihmojnĂ« ju dhe ekipet tuaja nĂ« organizim, siguri dhe madje nĂ« performancĂ«n e sistemit.
Në shumicën e shpërndarjeve të Kubernetes, klasteri "del nga kutia" me një hapësirë emrash që ka emrin "default". Në të vërtetë, ekzistojnë tre hapësira emrash me të cilat merret Kubernetes: default, kube-system dhe kube-public. Aktualisht, Kube-public përdoret jo aq shpesh.
Të mos e prekni hapësirën emërore kube është një ide e mirë, veçanërisht në një sistem të menaxhuar si Google Kubernetes Engine. Ajo përdor hapësirën emërore "default" si vend ku krijohen shërbimet dhe aplikacionet tuaja. Nuk ka asgjë të veçantë në të, përveç faktit se Kubernetes është parazgjedhur për ta përdorur dhe nuk mund ta fshini atë. Kjo është e shkëlqyer për të filluar punën dhe për sistemet me performancë të ulët, por nuk rekomandoj të përdoret hapësira emërore default në sisteme të mëdha prodhimi. Në këtë rast, një ekip zhvilluesish mund të lehtë të rishkruajë kodin e tjetrit dhe të prishë punën e një ekipi tjetër, edhe pa e kuptuar.
Prandaj, Ă«shtĂ« e nevojshme tĂ« krijoni disa hapĂ«sira emĂ«rore dhe tâi pĂ«rdorni ato pĂ«r tĂ« segmentezuar shĂ«rbimet tuaja nĂ« zinxhirĂ« tĂ« menaxhuar. HapĂ«sira emĂ«rore mund tĂ« krijohet me njĂ« komandĂ«. NĂ«se dĂ«shironi tĂ« krijoni njĂ« hapĂ«sirĂ« emĂ«rore me emrin test, pĂ«rdorni komandĂ«n $ kubectl create namespace test ose thjesht krijoni njĂ« skedal YAML dhe pĂ«rdorini atĂ«, ashtu si çdo burim tjetĂ«r Kubernetes.
Mund ta shikoni të gjitha hapësirat emërore me komandën $ kubectl get namespace.
Pas saj përfundon, do të shihni tre emra hapësinorë të integruar dhe një emër hapësinor të ri me emrin "test". Le të shqyrtojmë një skedar të thjeshtë YAML, i destinuar për krijimin e pod-it. Mund të vëreni se nuk ka asnjë përmendje të emrit të hapësirës.
Nëse aplikoni kubectl për të ekzekutuar këtë skedar, ai do të krijojë modulin mypod në hapësirën e tanishme aktive. Kjo do të jetë hapësira e paracaktuar derisa ta ndryshoni. Ka dy mënyra për të thënë Kubernetes në cilën hapësirë dëshironi të krijoni burimin tuaj. Mënyra e parë është të përdorni flamurin e hapësirës gjatë krijimit të burimit.
Mënyra e dytë është të specifikoni emrin e hapësirës në deklaratën YAML.
Nëse e specifikoni emrin e hapësirës në YAML, atëherë burimi gjithmonë do të krijohet në atë hapësirë. Nëse përpiqeni të përdorni një hapësirë tjetër duke përdorur flamurin e hapësirës, komanda do të përfundojë me një gabim. Tani, nëse përpiqeni të gjeni pod-in tuaj, nuk do të jeni në gjendje ta bëni këtë.
Kjo ndodh sepse të gjitha komandat ekzekutohen jashtë hapësirës aktive aktuale të emrave. Për të gjetur pod-in tuaj, ju nevojitet të përdorni flagun e hapësirës së emrave, megjithatë kjo bëhet shpejt e mërzitshme, sidomos nëse jeni zhvillues në një grup që përdor hapësirën e veta të emrave dhe nuk dëshiron të përdorë një flag të tillë për çdo komandë të veçantë. Le të shohim se si mund ta rregullojmë këtë.
Nga kutia, hapësira juaj aktive e emrave quhet default. Nëse nuk specifikoni hapësirën e emrave në burimin YAML, të gjitha komandat Kubernetes do të përdorin këtë hapësirë aktive default. Fatkeqësisht, përpjekja për të menaxhuar hapësirën aktive të emrave me kubectl mund të dështojë. Sidoqoftë, ekziston një mjet shumë i mirë i quajtur Kubens, i cili e bën këtë proces shumë më të lehtë. Kur drejtoni komandën kubens, shihni të gjitha hapësirat e emrave me hapësirën aktive të emrave të ndriçuar.
Për të kaluar nga hapësira e emrit aktiv në hapësirën e emrit test, thjesht ekzekutoni komandën $ kubens test. Nëse pas kësaj futni përsëri komandën $ kubens, do të shihni se tani është caktuar një hapësirë e re emri aktive - test.
Kjo do të thotë se nuk keni nevojë për një flamur hapësire emri për të parë pod-in në hapësirën e emrit test.
Prandaj, hapësirat e emrit janë të fshehura nga njëra-tjetra, por nuk janë të izoluar. Një shërbim nga një hapësirë emri mund të komunikojë mjaft lehtë me një shërbim në një hapësirë tjetër, e cila shpesh është shumë e dobishme. Mundësia e komunikimit midis hapësirave të ndryshme të emrave do të thotë se shërbimi juaj mund të bashkëpunojë me shërbimin e një ekipi tjetër zhvilluesish në një hapësirë tjetër emri.
Zakonisht, kur aplikacioni juaj dëshiron të qasë një shërbim Kubernetes, ju përdorni shërbimin e integruar të zbulimit DNS dhe thjesht i thoni aplikacionit tuaj emrin e shërbimit. Megjithatë, duke bërë këtë, mund të krijoni një shërbim me të njëjtin emër në disa hapësira emri, e cila është e papranueshme.
Fatkeqësisht, këtë është lehtë ta anashkaloni duke përdorur formën e zgjeruar të adresës DNS. Shërbimet në Kubernetes ekspozojnë pikët e tyre të fundit duke përdorur një model të zakonshëm DNS. Kjo duket përafërsisht kështu:
Si rregull, ju vetëm keni nevojë për emrin e shërbimit, dhe DNS automatikisht do të identifikojë adresën e plotë.
Megjithatë, nëse keni nevojë të aksesoni një shërbim në një hapësirë tjetër emërimi, thjesht përdorni emrin e shërbimit plus emrin e hapësirës emërtuese:
Për shembull, nëse dëshironi të lidheni me bazën e të dhënave të shërbimit në hapësirën e emërtimit test, mund të përdorni adresën e bazës database.test.
Nëse dëshironi të lidheni me bazën e të dhënave të shërbimit në hapësirën e emërtimit prod, përdorni database.prod.
Nëse me të vërtetë dëshironi të izoloheni dhe të kufizoni aksesin në hapësirën e emërtimit, Kubernetes e lejon këtë përmes politikave të rrjetit Kubernetes Network Policies. Për këtë do flas në serinë e ardhshme.
MĂ« shpesh mĂ« bĂ«het pyetje, sa hapĂ«sira emĂ«rtimi duhet tĂ« krijohen dhe pĂ«r çfarĂ«lloj qĂ«llimesh? ĂfarĂ« Ă«shtĂ« njĂ« fragment i menaxhuar tĂ« dhĂ«nash?
Nëse krijoni shumë hapësira emri, ato do t'ju pengojnë. Nëse ka shumë pak, do të humbni të gjitha përfitimet e këtij zgjidhjeje. Mendoj se ka katër faza kryesore që kalon çdo kompani gjatë procesit të krijimit të strukturës së saj organizative. Në varësi të fazës së zhvillimit në të cilën ndodhet projekti ose kompania juaj, mund të pranoni një strategji përkatëse për krijimin e hapësirave të emrave.
Imagjinoni se jeni pjesĂ« e njĂ« ekipi tĂ« vogĂ«l qĂ« punon nĂ« zhvillimin e 5-10 mikroshĂ«rbimeve dhe mund tĂ« grumbulloni lehtĂ«sisht tĂ« gjithĂ« zhvilluesit nĂ« njĂ« dhomĂ«. NĂ« kĂ«tĂ« situatĂ«, ka kuptim tĂ« filloni tĂ« gjitha shĂ«rbimet prodhuese nĂ« hapĂ«sirĂ«n e emrit default. Sigurisht, pĂ«r mĂ« shumĂ« liri veprimi, mund tĂ« pĂ«rdorni 2 hapĂ«sira emri â veçmas pĂ«r prodhim dhe zhvillim. Dhe Ă«shtĂ« shumĂ« e mundshme qĂ« tĂ« jeni duke testuar zhvillimin tuaj nĂ« kompjuterin lokal me ndihmĂ«n e ndonjĂ« gjĂ«je si Minikube.
Supozoni se kushtet kanë ndryshuar dhe tani keni një ekip në rritje të shpejtë që punon në të njëjtën kohë mbi më shumë se 10 mikroshërbime. Arrin një moment kur është e nevojshme të përdoren disa grupe të klasterëve ose emrash hapësinorë, veçmas për prodhimin dhe zhvillimin. Mund të ndani ekipin në disa nëngrupe, duke i dhënë secilës grup të vetat mikroshërbime dhe çdo grupi mund t'i lejohet të zgjedhë hapësirën e tij të emrit për të lehtësuar procesin e menaxhimit të zhvillimit dhe nxjerrjes së softuerit.
Duke përparuar, ndërsa secili anëtar i ekipit merr një kuptim të sistemit në tërësi, koordinimi i çdo ndryshimi me të gjithë zhvilluesit e tjerë bëhet gjithnjë e më e vështirë. Përpjekjet për të rrotulluar pilin e plotë në kompjuterin tuaj lokal po bëhen çdo ditë më të vështira.
NĂ« kompanitĂ« e mĂ«dha, zhvilluesit as qĂ« nuk e dinĂ« se kush punon nĂ« çfarĂ« projekti. Ekipet komunikojnĂ« pĂ«rmes kontratave tĂ« shĂ«rbimeve ose pĂ«rdorin teknologjinĂ« Service mesh, e cila shton njĂ« nivel abstraksioni mbi rrjetin, siç Ă«shtĂ« instrumenti i konfigurimit Istio. TĂ« provosh tĂ« lançosh tĂ« gjithĂ« stek-un lokal Ă«shtĂ« thjesht e pamundur. UnĂ« rekomandoj gjithnjĂ« qĂ« tĂ« pĂ«rdoret njĂ« platformĂ« pĂ«r shpĂ«rndarje tĂ« vazhdueshme (CD) nĂ« Kubernetes, si Spinnaker. Pra, vjen njĂ« moment kur çdo ekip patjetĂ«r ka nevojĂ« pĂ«r hapĂ«sirĂ«n e vet emĂ«rore. Ădo ekip madje mund tĂ« zgjedhĂ« disa hapĂ«sira emĂ«rore pĂ«r ambientin dev dhe ambientin prod.
Më në fund, ekzistojnë kompani të mëdha ndërrmarje, ku një grup zhvilluesish as që nuk e di për ekzistencën e grupeve të tjera. Një kompani e tillë mund të angazhojë madje zhvillues të jashtëm, të cilët ndërveprojnë përmes API-ve të dokumentuara mirë. Në çdo grup të tillë ka disa ekipe dhe disa mikrosherbime. Në këtë rast, është e nevojshme të përdoren të gjitha mjetet për të cilat kam folur më parë.
Programuesit nuk duhet të vendosin shërbime manualisht dhe nuk duhet të kenë akses në hapësira emrash që nuk lidhen me ta. Në këtë fazë, është e arsyeshme të keni disa klasterë për të reduktuar "rrezen e shpërthimit" të aplikacioneve të konfiguruara keq, për të thjeshtuar proceset e faturimit dhe menaxhimit të burimeve.
Kështu, përdorimi i duhur i hapësirave emrash nga organi juaj e bën Kubernetes më të menaxhueshëm, të kontrollueshëm, të sigurt dhe fleksibël.
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
