Ndërsa filloni të krijoni gjithnjë e më shumë shërbime Kubernetes, detyrat që në fillim duken të thjeshta fillojnë të komplikohet. Për shembull, ekipet e zhvilluesve nuk mund të krijojnë shërbime ose meksë me të njëjtin emër. Nëse keni mijëra pod-e, thjesht listimi i tyre do të marrë shumë kohë, pa përmendur menaxhimin e tyre të duhur. Dhe kjo është vetëm maja e akullnajes.
Le të shohim se si hapësira emërtimi (namespace) lehtëson menaxhimin e burimeve Kubernetes. Pra, çfarë është hapësira emërtimi? Ajo mund të shihet si një klaster virtual brenda klasterit tuaj Kubernetes. Mund të keni disa hapësira emërtimi të izoluara nga njëri-tjetri brenda një klasteri Kubernetes. Ato mund t'ju ndihmojnë juve dhe ekipeve tuaja me organizimin, sigurinë dhe madje edhe performancën e sistemit.
Në shumicën e shpërndarjeve Kubernetes, klasteri del 'nga kutia' me një hapësirë emërtimi që quhet 'default'. Në të vërtetë ekzistojnë tri hapësira emërtimi me të cilat merret Kubernetes: default, kube-system dhe kube-public. Aktualisht, kube-public nuk përdoret shumë.
Të mos prekni hapësirën emërtimi kube është një ide e mirë, veçanërisht në një sistem të menaxhuar si Google Kubernetes Engine. Ai përdor hapësirën emërtimi 'default' si vend ku krijohen shërbimet dhe aplikacionet tuaja. Nuk ka asgjë të veçantë përveç faktit se Kubernetes 'nga kutia' është i konfiguruar për ta përdorur, dhe nuk mund ta fshini. Kjo është e shkëlqyer për nisjen dhe sistemet me performancë të ulët, por nuk do ta rekomandoja përdorimin e hapësirës emërtimi default në sisteme të mëdha prodhimi. Në këtë rast, një ekip zhvilluesish mund të rishkruajë lehtësisht kodin e dikujt tjetër dhe të prishë funksionimin e ekipit tjetër, pa e kuptuar fare.
Prandaj, është e nevojshme të krijoni disa hapësira emërtimi dhe t'i përdorni ato për të segmentuar shërbimet tuaja në pjesë të menaxhuara. Një hapësirë emërtimi mund të krijohet me një komandë. Nëse dëshironi të krijoni një hapësirë emërtimi me emrin test, përdorni komandën $ kubectl create namespace test ose thjesht krijoni një skedar YAML dhe përdoreni atë si çdo burim tjetër Kubernetes.
Për të parë të gjitha hapësirat emërtimi, mund të përdorni komandën $ kubectl get namespace.
Pas pas përfundimit të saj, do të shihni tre hapësira emrash të ndërtuara dhe një hapësirë emri të re të quajtur "test". Le të shqyrtojmë një skedar të thjeshtë YAML, i destinuar për të krijuar një pod. Mund të vërehet se nuk ka asnjë përmendje të hapësirës emri.
Nëse aplikoni kubectl për të ekzekutuar këtë skedar, ai do të krijojë modulin mypod në hapësirën aktuale aktive të emrit. Kjo do të jetë hapësira emri për default, derisa ta ndryshoni atë. Ekzistojnë dy mënyra për t'i treguar Kubernetes-it se në cilën hapësirë emri dëshironi të krijoni burimin tuaj. Mënyra e parë është përdorimi i flamurit të hapësirës emri gjatë krijimit të burimit.
Mënyra e dytë është përcaktimi i hapësirës emri në deklaratën YAML.
Nëse përcaktoni hapësirën emri në YAML, burimi gjithmonë do të krijohet në këtë hapësirë. Nëse përpiqeni të përdorni një hapësirë emri tjetër duke përdorur flamurin e hapësirës emri, komandimi do të dështojë. Tani, nëse përpiqeni të gjeni pod-in tuaj, nuk do të jeni në gjendje ta bëni atë.
Kjo ndodh sepse të gjitha komandat ekzekutohen jashtë hapësirës aktuale aktive të emrit. Për të gjetur pod-in tuaj, duhet të përdorni flamurin e hapësirës emri, megjithatë, kjo bëhet shpejt e mërzitshme, veçanërisht nëse jeni një zhvillues në një grup që përdor hapësirën e vet të emrit dhe nuk dëshiron të përdorë një flamur për çdo komandë të veçantë. Le të shohim se si mund ta rregullojmë këtë.
Nga kutia, hapësira juaj aktive e emrit quhet default. Nëse nuk përcaktoni hapësirën emri 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ë emrit me kubectl mund të dështojë. Megjithatë, ekziston një mjet shumë të mirë të quajtur Kubens, i cili e bën këtë proces shumë më të lehtë. Kur ekzekutoni komandën kubens, shihni të gjitha hapësirat e emrave me hapësirën e ndriçuar aktive të emrit.
Për të kaluar hapësirën aktive të emrit në hapësirën e emrit test, thjesht ekzekutoni komandën $ kubens test. Nëse pas kësaj shkruani përsëri komandën $ kubens, mund të shihni se tani është ndriçuar një hapësirë e re aktive e emrit - test.
Kjo do të thotë se nuk keni nevojë për një flamur emri hapësire për të parë pod në hapësirën e emrit test.
Kështu hapësirat e emrave janë të fshehura nga njëra-tjetra, por nuk janë të izoluar nga njëra-tjetra. Një shërbim nga një hapësirë emri mund të komunikojë lehtësisht me një shërbim në një hapësirë tjetër emri, gjë që shpesh është shumë e dobishme. Mundësia e komunikimit midis hapësirave të ndryshme emrash do të thotë që shërbimi i zhvilluesve tuaj mund të interaktojë me shërbimin e një ekipi tjetër zhvilluesish në një hapësirë emri tjetër.
Zakonisht, kur aplikacioni juaj dëshiron të ketë akses në një shërbim Kubernetes, përdorni shërbimin e integruar për zbulimin e DNS dhe thjesht i thoni aplikacionit tuaj emrin e shërbimit. Megjithatë, në këtë rast, mund të krijoni një shërbim me të njëjtin emër në disa hapësira emrash, gjë që është e papranueshme.
Fatmirësisht, kjo është lehtësisht e mundur për t'u anashkaluar duke përdorur formën e zgjeruar të adresës DNS. Shërbimet në Kubernetes ekspozojnë pikët e tyre të përfundimit duke përdorur një model të përbashkët DNS. Kjo duket më pak si kjo:
Si rregull, ju thjesht keni nevojë për emrin e shërbimit, dhe DNS automatikisht do të përcaktojë adresën e plotë.
Megjithatë, nëse keni nevojë për të hyrë në një shërbim në një hapësirë tjetër emri, thjesht përdorni emrin e shërbimit plus emrin e hapësirës emri:
Për shembull, nëse dëshironit të lidheni me bazën e të dhënave të shërbimit në hapësirën e emrit test, mund të përdorni adresën database.test.
Nëse dëshironit të lidheni me bazën e të dhënave të shërbimit në hapësirën e emrit prod, përdorni database.prod.
Nëse vërtet dëshiron të izolohesh dhe të kufizosh aksesin në hapësirën e emrit, Kubernetes e lejon këtë me anë të politikave rrjetesh Kubernetes Network Policies. Për këtë do të flas në serinë e ardhshme.
MĂ« pyetet shpesh se sa hapĂ«sira emrash duhet tĂ« krijohen dhe pĂ«r çfarĂ« qĂ«llimesh? ĂfarĂ« Ă«shtĂ« njĂ« fragment tĂ« dhĂ«nash i menaxhuar?
Nëse krijoni shumë hapësira emrash, ato do t'ju pengojnë. Nëse ndonjëra është tepër e vogël, 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ë adoptoni strategjinë e duhur për krijimin e hapësirave emrash.
Imaginoni qĂ« jeni pjesĂ« e njĂ« ekipi tĂ« vogĂ«l qĂ« punon nĂ« zhvillimin e 5-10 mikroshĂ«rbimeve dhe ju lehtĂ« mund tĂ« mbledhni tĂ« gjithĂ« zhvilluesit nĂ« njĂ« dhomĂ«. NĂ« kĂ«tĂ« situatĂ«, ka kuptim tĂ« lanconi tĂ« gjitha shĂ«rbimet prodhuese nĂ« hapĂ«sirĂ«n emĂ«rore default. Sigurisht, pĂ«r mĂ« shumĂ« hapĂ«sirĂ« veprimi, mund tĂ« pĂ«rdorni 2 hapĂ«sira emrash â njĂ« pĂ«r prodhimin dhe njĂ« pĂ«r zhvillimin. Dhe shumĂ« gjasĂ«, jeni duke testuar zhvillimin tuaj nĂ« kompjuterin lokal me ndihmĂ«n e diçkaje si Minikube.
Supozoni se kushtet kanë ndryshuar dhe tani keni një ekip në rritje të shpejtë që po punon njëkohësisht mbi më shumë se 10 mikroshërbime. Arrin një moment kur duhet të përdorni disa grupe klasteresh ose hapësirash emrash, ndaras për prodhimin dhe zhvillimin. Mund ta ndani ekipin në disa nën-grupe në mënyrë që secila të ketë mikroshërbimet e veta dhe secila nga këto ekipe të mund të zgjedhë hapësirën e saj emërore për të lehtësuar procesin e menaxhimit të zhvillimit dhe lëshimit të software-it.
Ndërsa çdo anëtar i ekipit fiton një kuptim se si funksionon sistemi në tërësi, koordinimi i çdo ndryshimi me të gjithë zhvilluesit e tjerë bëhet gjithnjë e më i vështirë. Tentimi për të drejtuar një stak të plotë në kompjuterin tuaj lokal bëhet çdo ditë më i komplikuar.
Në kompanitë e mëdha, zhvilluesit në përgjithësi nuk dinë se kush konkretisht po punon mbi çfarë. Ekipet komunikojnë përmes kontratave të shërbimeve ose përdorin teknologjinë Service mesh, e cila shton një nivel abstraksioni mbi rrjetin, siç është mjeti i konfigurimit Istio. Përpjekja për të nisur të gjithë stek-un lokalisht është për njëkohësisht e pamundur. Unë e rekomandoj fuqishëm përdorimin e një platforme të dërgesës së vazhdueshme (CD) si Spinnaker në Kubernetes. Prandaj, vjen një moment kur secilit ekip patjetër i nevojitet hapësira e vet emërore. Secili ekip madje mund të zgjedhë disa hapësira emërore për mjedisin dev dhe për mjedisin prod.
Më në fund, ekzistojnë kompani të mëdha sipërmarrëse ku një grup zhvilluesish nuk di as për ekzistencën e grupeve të tjera. Një kompani e tillë mund ta angazhojë në tërësi zhvillues të jashtëm që komunikojnë përmes API-ve të dokumentuara mirë. Në secilën nga këto grupe ka disa ekipe dhe disa mikroshërbime. Në këtë rast, është e nevojshme të përdoren të gjitha mjetet për të cilat fola më parë.
Programuesit nuk duhet të publikojnë shërbimet manualisht dhe nuk duhet të kenë akses në hapësirat emërore që nuk i përkasin. Në këtë fazë, është e arsyeshme të kemi disa klasterë për të zvogëluar "rrezikun e shpërthimit" të aplikacioneve të konfigurura keq, për të thjeshtuar proceset e faturimit dhe menaxhimin e burimeve.
Prandaj, përdorimi i duhur i hapësirave emërore nga organizata juaj e bën Kubernetes më të menaxhueshëm, të kontrollueshëm, të sigurt dhe fleksibël.
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
