Ko začnete ustvarjati vedno več storitev Kubernetes, začnejo naloge, ki so sprva preproste, postajati bolj zapletene. Na primer, razvojne skupine ne morejo ustvariti storitev ali uvedb pod istim imenom. Če imate na tisoče podov, vam bo preprosto naštevanje vzelo veliko časa, kaj šele pravilno upravljanje z njimi. In to je le vrh ledene gore.
Poglejmo, kako imenski prostor olajša upravljanje virov Kubernetes. Kaj je torej imenski prostor? Imenski prostor si lahko predstavljate kot navidezno gručo znotraj vaše gruče Kubernetes. V eni gruči Kubernetes lahko imate več imenskih prostorov, izoliranih drug od drugega. Resnično lahko pomagajo vam in vašim ekipam pri organizaciji, varnosti in celo zmogljivosti sistema.
V večini distribucij Kubernetes je gruča takoj pripravljena z imenskim prostorom, imenovanim "privzeto". Pravzaprav obstajajo trije imenski prostori, s katerimi se Kubernetes ukvarja: privzeti, kube-system in kube-public. Trenutno se Kube-public ne uporablja prav pogosto.
Pustiti imenski prostor kube pri miru je dobra ideja, zlasti v upravljanem sistemu, kot je Google Kubernetes Engine. Uporablja "privzeti" imenski prostor kot mesto, kjer so ustvarjene vaše storitve in aplikacije. Na njem ni prav nič posebnega, razen tega, da je Kubernetes že pripravljen za uporabo in ga ne morete odstraniti. To je super za začetnike in nizko zmogljive sisteme, vendar ne priporočam uporabe privzetega imenskega prostora na velikih sistemih prod. V slednjem primeru lahko ena razvojna ekipa zlahka prepiše kodo nekoga drugega in prekine delo druge ekipe, ne da bi se tega sploh zavedala.
Zato bi morali ustvariti več imenskih prostorov in jih uporabiti za segmentacijo svojih storitev v obvladljive enote. Imenski prostor lahko ustvarite z enim samim ukazom. Če želite ustvariti imenski prostor z imenom test, uporabite ukaz $ kubectl create namespace test ali preprosto ustvarite datoteko YAML in jo uporabite kot kateri koli drug vir Kubernetes.
Vse imenske prostore si lahko ogledate z ukazom $ kubectl get namespace.
Ko bo končano, boste videli tri vgrajene imenske prostore in nov imenski prostor, imenovan »test«. Oglejmo si preprosto datoteko YAML za ustvarjanje stroka. Opazili boste, da imenski prostor ni omenjen.
Če za zagon te datoteke uporabite kubectl, bo ustvaril modul mypod v trenutno aktivnem imenskem prostoru. To bo privzeti imenski prostor, dokler ga ne spremenite. Kubernetesu lahko na dva načina poveste, v katerem imenskem prostoru želite ustvariti svoj vir. Prvi način je uporaba zastavice imenskega prostora pri ustvarjanju vira.
Drugi način je določitev imenskega prostora v deklaraciji YAML.
Če določite imenski prostor v YAML, bo vir vedno ustvarjen v tem imenskem prostoru. Če med uporabo zastavice imenskega prostora poskusite uporabiti drug imenski prostor, ukaz ne bo uspel. Zdaj, če poskušate najti svoj pod, tega ne boste mogli storiti.
To se zgodi, ker se vsi ukazi izvajajo zunaj trenutno aktivnega imenskega prostora. Če želite najti svoj pod, morate uporabiti zastavico imenskega prostora, a to hitro postane dolgočasno, še posebej, če ste razvijalec v skupini, ki uporablja svoj lasten imenski prostor in ne želi uporabiti te zastavice za vsak posamezen ukaz. Poglejmo, kako lahko to popravimo.
Vaš aktivni imenski prostor se takoj imenuje privzeti. Če v sredstvu YAML ne podate imenskega prostora, bodo vsi ukazi Kubernetes uporabljali ta aktivni privzeti imenski prostor. Na žalost lahko poskus upravljanja aktivnega imenskega prostora s kubectl ne uspe. Vendar pa obstaja zelo dobro orodje, imenovano Kubens, ki ta postopek precej olajša. Ko zaženete ukaz kubens, vidite vse imenske prostore z označenim aktivnim imenskim prostorom.
Če želite preklopiti aktivni imenski prostor v testni imenski prostor, preprosto zaženite ukaz $kubens test. Če nato znova zaženete ukaz $kubens, boste videli, da je zdaj dodeljen nov aktivni imenski prostor - test.
To pomeni, da ne potrebujete zastavice imenskega prostora, če želite videti pod v testnem imenskem prostoru.
Na ta način so imenski prostori skriti drug pred drugim, vendar niso izolirani drug od drugega. Storitev v enem imenskem prostoru lahko precej enostavno komunicira s storitvijo v drugem imenskem prostoru, kar je pogosto zelo koristno. Zmožnost komuniciranja prek različnih imenskih prostorov pomeni, da lahko storitev vašega razvijalca komunicira s storitvijo druge skupine razvijalcev v drugem imenskem prostoru.
Običajno, ko vaša aplikacija želi dostopati do storitve Kubernetes, uporabite vgrajeno storitev odkrivanja DNS in svoji aplikaciji preprosto dodelite ime storitve. Vendar pa lahko s tem ustvarite storitev pod istim imenom v več imenskih prostorih, kar ni sprejemljivo.
Na srečo je to enostavno rešiti z uporabo razširjene oblike naslova DNS. Storitve v Kubernetesu izpostavijo svoje končne točke z uporabo skupne predloge DNS. Videti je nekako takole:
Običajno potrebujete le ime storitve in DNS bo samodejno določil celoten naslov.
Če pa morate dostopati do storitve v drugem imenskem prostoru, preprosto uporabite ime storitve in ime imenskega prostora:
Na primer, če se želite povezati s storitveno bazo podatkov v testnem imenskem prostoru, lahko uporabite naslovno bazo podatkov database.test
Če se želite povezati s servisno bazo podatkov v imenskem prostoru prod, uporabite database.prod.
Če res želite izolirati in omejiti dostop do imenskega prostora, vam Kubernetes omogoča, da to storite z omrežnimi pravilniki Kubernetes. O tem bom govoril v naslednji epizodi.
Pogosto se mi postavlja vprašanje, koliko imenskih prostorov naj ustvarim in za kakšen namen? Kaj je upravljani podatek?
Če ustvarite preveč imenskih prostorov, vam bodo samo ovirali. Če jih bo premalo, boste izgubili vse prednosti takšne rešitve. Mislim, da obstajajo štiri glavne faze, skozi katere gre vsako podjetje, ko ustvarja svojo organizacijsko strukturo. Glede na stopnjo razvoja, v kateri je vaš projekt ali podjetje, boste morda želeli sprejeti ustrezno strategijo imenskega prostora.
Predstavljajte si, da ste del majhne ekipe, ki se ukvarja z razvojem 5-10 mikroservisov in zlahka zberete vse razvijalce v eni sobi. V tej situaciji je smiselno zagnati vse proizvodne storitve v privzetem imenskem prostoru. Seveda lahko za večjo prilagodljivost uporabite 2 imenska prostora - ločeno za prod in dev. Najverjetneje preizkusite svoj razvoj na lokalnem računalniku z uporabo nečesa, kot je Minikube.
Recimo, da se stvari spremenijo in imate zdaj hitro rastočo ekipo, ki dela na več kot 10 mikrostoritvah hkrati. Pride čas, ko je treba uporabiti več gruč ali imenskih prostorov, ločeno za prod in dev. Ekipo lahko razdelite na več podskupin, tako da ima vsaka svoje mikrostoritve in vsaka od teh skupin lahko izbere svoj lasten imenski prostor, da olajša proces upravljanja razvoja in izdaje programske opreme.
Ker vsak član ekipe dobi vpogled v delovanje sistema kot celote, postane vse težje uskladiti vsako spremembo z vsemi drugimi razvijalci. Vsak dan je težje poskušati zavrteti polni sklad na vašem lokalnem računalniku.
V velikih podjetjih razvijalci na splošno ne vedo, kdo točno na čem dela. Ekipe komunicirajo s pogodbami o storitvah ali uporabljajo mrežno tehnologijo storitev, ki dodaja plast abstrakcije prek omrežja, kot je konfiguracijsko orodje Istio. Poskus izvajanja celotnega sklada lokalno preprosto ni mogoč. Zelo priporočam uporabo platforme za neprekinjeno dostavo (CD), kot je Spinnaker na Kubernetes. Torej pride do točke, ko vsak ukaz zagotovo potrebuje svoj imenski prostor. Vsaka ekipa lahko celo izbere več imenskih prostorov za razvojno in proizvodno okolje.
Končno obstajajo velika podjetniška podjetja, v katerih ena skupina razvijalcev sploh ne ve za obstoj drugih skupin. Takšno podjetje lahko na splošno najame razvijalce tretjih oseb, ki z njim sodelujejo prek dobro dokumentiranih API-jev. Vsaka taka skupina vsebuje več ekip in več mikrostoritev. V tem primeru morate uporabiti vsa orodja, o katerih sem govoril prej.
Programerji ne bi smeli ročno uvajati storitev in ne bi smeli imeti dostopa do imenskih prostorov, ki jih ne zadevajo. Na tej stopnji je priporočljivo imeti več gruč, da zmanjšamo "radij eksplozije" slabo konfiguriranih aplikacij, da poenostavimo postopke zaračunavanja in upravljanje virov.
Tako vam pravilna uporaba imenskih prostorov v vaši organizaciji omogoča, da naredite Kubernetes bolj obvladljiv, nadzorovan, varen in prilagodljiv.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com