Þegar þú byrjar að búa til fleiri og fleiri Kubernetes þjónustu byrja verkefni sem eru einföld í upphafi að verða flóknari. Til dæmis geta þróunarteymi ekki búið til þjónustu eða dreifingu undir sama nafni. Ef þú ert með þúsundir fræbelgja, einfaldlega að skrá þá mun taka mikinn tíma, hvað þá að stjórna þeim rétt. Og þetta er bara toppurinn á ísjakanum.
Við skulum skoða hvernig nafnrýmið gerir það auðveldara að stjórna Kubernetes auðlindum. Svo hvað er nafnrými? Hægt er að hugsa um nafnarými sem sýndarþyrping innan Kubernetes þyrpingarinnar. Þú getur haft mörg nafnrými einangruð hvert frá öðru innan eins Kubernetes þyrpingar. Þeir geta virkilega hjálpað þér og teymunum þínum með skipulagningu, öryggi og jafnvel frammistöðu kerfisins.
Í flestum Kubernetes dreifingum kemur þyrpingin út úr kassanum með nafnrými sem kallast "sjálfgefið". Það eru í raun þrjú nafnrými sem Kubernetes fjallar um: sjálfgefið, kube-system og kube-public. Eins og er er Kube-public ekki notað mjög oft.
Það er góð hugmynd að skilja kube nafnrýmið eftir, sérstaklega á stýrðu kerfi eins og Google Kubernetes Engine. Það notar „sjálfgefið“ nafnrými sem staðurinn þar sem þjónustan þín og forrit eru búin til. Það er nákvæmlega ekkert sérstakt við það, nema að Kubernetes er stillt út úr kassanum til að nota það, og þú getur ekki fjarlægt það. Þetta er frábært til að byrja og afkastalítil kerfi, en ég myndi ekki mæla með því að nota sjálfgefið nafnrými á stórum framleiðslukerfum. Í síðara tilvikinu getur eitt þróunarteymi auðveldlega endurskrifað kóða einhvers annars og brotið vinnu annars liðs án þess að átta sig á því.
Þess vegna ættir þú að búa til mörg nafnrými og nota þau til að skipta þjónustunni niður í viðráðanlegar einingar. Hægt er að búa til nafnrými með einni skipun. Ef þú vilt búa til nafnrými sem heitir próf, notaðu þá skipunina $ kubectl búa til nafnrýmispróf eða einfaldlega búðu til YAML skrá og notaðu hana eins og hver önnur Kubernetes tilföng.
Þú getur skoðað öll nafnrýmin með $ kubectl get namespace skipuninni.
Þegar því er lokið muntu sjá þrjú innbyggð nafnarými og nýtt nafnrými sem kallast „próf“. Við skulum skoða einfalda YAML skrá til að búa til fræbelg. Þú munt taka eftir því að það er ekkert minnst á nafnrými.
Ef þú notar kubectl til að keyra þessa skrá mun hún búa til mypod eininguna í virku nafnrýminu. Þetta verður sjálfgefið nafnrými þar til þú breytir því. Það eru tvær leiðir til að segja Kubernetes í hvaða nafnrými þú vilt búa til auðlindina þína. Fyrsta leiðin er að nota nafnrýmisfána þegar tilfang er búið til.
Önnur leiðin er að tilgreina nafnrýmið í YAML yfirlýsingunni.
Ef þú tilgreinir nafnrými í YAML verður tilfangið alltaf búið til í því nafnarými. Ef þú reynir að nota annað nafnrými á meðan þú notar nafnrýmisfánann mun skipunin mistakast. Nú ef þú reynir að finna belg þinn, muntu ekki geta gert það.
Þetta gerist vegna þess að allar skipanir eru keyrðar fyrir utan virka nafnrýmið. Til að finna podinn þinn þarftu að nota nafnrýmisfána, en þetta verður fljótt leiðinlegt, sérstaklega ef þú ert þróunaraðili í teymi sem notar eigið nafnrými og vill ekki nota það fána fyrir hverja einustu skipun. Við skulum sjá hvernig við getum lagað þetta.
Fyrir utan kassann er virka nafnarýmið þitt kallað sjálfgefið. Ef þú tilgreinir ekki nafnrými í auðlindinni YAML, þá munu allar Kubernetes skipanir nota þetta virka sjálfgefna nafnrými. Því miður getur það mistekist að reyna að stjórna virka nafnrýminu með því að nota kubectl. Hins vegar er til mjög gott tól sem heitir Kubens sem gerir þetta ferli mun auðveldara. Þegar þú keyrir kubens skipunina sérðu öll nafnasvæði með virka nafnarýmið auðkennt.
Til að skipta um virka nafnrýmið yfir í prófunarnafnarýmið keyrirðu einfaldlega $kubens prófskipunina. Ef þú keyrir síðan $kubens skipunina aftur, muntu sjá að nýju virku nafnrými er nú úthlutað - próf.
Þetta þýðir að þú þarft ekki nafnrýmisfánann til að sjá hólfið í prófunarnafnarýminu.
Þannig eru nafnarýmin falin hvert frá öðru, en ekki einangrað hvert frá öðru. Þjónusta í einu nafnarými getur átt mjög auðvelt með að eiga samskipti við þjónustu í öðru nafnrými, sem er oft mjög gagnlegt. Möguleikinn á að hafa samskipti á milli mismunandi nafnarúma þýðir að þjónusta þróunaraðila þíns getur átt samskipti við þjónustu annars þróunarteymis í öðru nafnrými.
Venjulega, þegar forritið þitt vill fá aðgang að Kubernetes þjónustu, notarðu innbyggðu DNS uppgötvunarþjónustuna og gefur forritinu þínu einfaldlega nafn þjónustunnar. Hins vegar, með því að gera það, geturðu búið til þjónustu undir sama nafni í mörgum nafnasvæðum, sem er ekki ásættanlegt.
Sem betur fer er auðvelt að komast um þetta með því að nota útvíkkað form DNS heimilisfangsins. Þjónusta í Kubernetes afhjúpar endapunkta sína með því að nota sameiginlegt DNS sniðmát. Það lítur eitthvað svona út:
Venjulega þarftu bara þjónustunafnið og DNS mun sjálfkrafa ákvarða fullt heimilisfang.
Hins vegar, ef þú þarft að fá aðgang að þjónustu í öðru nafnrými, notaðu einfaldlega þjónustunafnið ásamt nafnrýminu:
Til dæmis, ef þú vilt tengjast þjónustugagnagrunni í prófunarnafnarými, geturðu notað heimilisfangagagnagrunninn database.test
Ef þú vilt tengjast þjónustugagnagrunninum í vöruheitarýminu notarðu database.prod.
Ef þú vilt virkilega einangra og takmarka aðgang að nafnrými, gerir Kubernetes þér kleift að gera þetta með því að nota Kubernetes netstefnur. Ég mun tala um þetta í næsta þætti.
Ég er oft spurð spurningarinnar, hversu mörg nafnrými ætti ég að búa til og í hvaða tilgangi? Hvað er stýrt gagnastykki?
Ef þú býrð til of mörg nafnrými verða þau bara í vegi þínum. Ef þeir eru of fáir taparðu öllum ávinningi slíkrar lausnar. Ég held að það séu fjórir meginþrep sem hvert fyrirtæki fer í gegnum þegar þeir búa til skipulag sitt. Það fer eftir þróunarstigi verkefnisins eða fyrirtækis þíns, þú gætir viljað samþykkja viðeigandi nafnrýmisstefnu.
Ímyndaðu þér að þú sért hluti af litlu teymi sem vinnur að því að þróa 5-10 örþjónustur og þú getur auðveldlega safnað öllum þróunaraðilum í eitt herbergi. Í þessum aðstæðum er skynsamlegt að keyra allar prod þjónustur í sjálfgefnu nafnrými. Auðvitað, til að fá meiri sveigjanleika, geturðu notað 2 nafnrými - sérstaklega fyrir framleiðslu og þróun. Og líklega prófarðu þróun þína á staðbundinni tölvu með því að nota eitthvað eins og Minikube.
Segjum að hlutirnir breytast og þú ert nú með ört vaxandi teymi sem vinnur að meira en 10 örþjónustum í einu. Það kemur tími þegar nauðsynlegt er að nota nokkra klasa eða nafnarými, sérstaklega fyrir framleiðslu og þróun. Þú getur skipt liðinu í nokkur undirteymi þannig að hvert þeirra hefur sína eigin örþjónustu og hvert þessara teyma getur valið sér nafnrými til að auðvelda stjórnun hugbúnaðarþróunar og útgáfu.
Eftir því sem hver og einn liðsmaður fær innsýn í hvernig kerfið í heild sinni virkar, verður erfiðara og erfiðara að samræma hverja breytingu við alla aðra þróunaraðila. Það verður erfiðara með hverjum deginum að reyna að snúa upp fullum stafla á heimavélinni þinni.
Í stórum fyrirtækjum vita verktaki almennt ekki hver vinnur nákvæmlega við hvað. Liðin hafa samskipti með því að nota þjónustusamninga eða nota þjónustunetstækni, sem bætir abstraktlagi yfir netið, eins og Istio stillingartólið. Það er einfaldlega ekki hægt að reyna að keyra heilan stafla á staðnum. Ég mæli eindregið með því að nota samfellda afhendingu (CD) vettvang eins og Spinnaker á Kubernetes. Svo kemur tími þar sem hver skipun þarf örugglega sitt eigið nafnrými. Hvert lið getur jafnvel valið mörg nafnrými fyrir þróunarumhverfið og framleiðsluumhverfið.
Að lokum eru stór frumkvöðlafyrirtæki þar sem einn hópur þróunaraðila veit ekki einu sinni um tilvist annarra hópa. Slíkt fyrirtæki gæti almennt ráðið þriðja aðila forritara sem hafa samskipti við það í gegnum vel skjalfest API. Hver slíkur hópur inniheldur nokkur teymi og nokkrar örþjónustur. Í þessu tilfelli þarftu að nota öll tækin sem ég talaði um áðan.
Forritarar ættu ekki að dreifa þjónustu handvirkt og ættu ekki að hafa aðgang að nafnasvæðum sem snerta þá ekki. Á þessu stigi er ráðlegt að hafa nokkra klasa til að minnka „sprengjuradíus“ illa stilltra forrita, til að einfalda innheimtuferli og auðlindastjórnun.
Þannig, rétt notkun á nafnasvæðum hjá fyrirtækinu þínu gerir þér kleift að gera Kubernetes viðráðanlegri, stýranlegri, öruggari og sveigjanlegri.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com