Kubernetes zerbitzu gehiago sortzen hasten zaren heinean, hasieran sinpleak diren zereginak konplexuagoak bihurtzen hasten dira. Esate baterako, garapen-taldeek ezin dute sortu zerbitzu edo inplementazio izen berarekin. Milaka lekak badituzu, horiek zerrendatzeak denbora asko beharko du, eta are gutxiago behar bezala kudeatzea. Eta hau icebergaren punta besterik ez da.
Ikus dezagun nola errazten duen izen-espazioak Kubernetes baliabideak kudeatzea. Beraz, zer da namespace bat? Namespace zure Kubernetes kluster barruan dagoen kluster birtual gisa har daiteke. Kubernetes kluster bakar baten barruan hainbat izen-espazio izan ditzakezu elkarrengandik isolatuta. Benetan lagunduko dizute zuri eta zure taldeei antolakuntzan, segurtasunean eta baita sistemaren errendimenduan ere.
Kubernetes-en banaketa gehienetan, klusterra "lehenetsia" izeneko izen-espazio batekin ateratzen da kutxatik. Izan ere, Kubernetes-ek jorratzen dituen hiru izen-espazio daude: default, kube-system eta kube-public. Gaur egun, Kube-public ez da askotan erabiltzen.
Kube izen-espazioa bakarrik uztea ideia ona da, batez ere Google Kubernetes Engine bezalako kudeatutako sistema batean. "Lehenetsitako" izen-espazioa erabiltzen du zure zerbitzuak eta aplikazioak sortzen diren leku gisa. Ez dago ezer berezirik, Kubernetes kutxatik kanpo konfiguratuta dagoela erabiltzeko, eta ezin duzula kendu. Hau oso ona da hasteko eta errendimendu baxuko sistemak, baina ez nuke gomendatuko izen-espazio lehenetsia produktu handien sistemak erabiltzea. Azken kasu honetan, garapen talde batek erraz berridatzi dezake beste norbaiten kodea eta beste talde baten lana hautsi ere egin dezake konturatu gabe.
Hori dela eta, hainbat izen-espazio sortu beharko zenuke eta erabili zure zerbitzuak unitate kudeagarrietan segmentatzeko. Komando bakar batekin izen-espazio bat sor daiteke. Test izeneko izen-espazio bat sortu nahi baduzu, erabili $ kubectl create namespace test komandoa edo, besterik gabe, sortu YAML fitxategi bat eta erabili Kubernetes-en beste edozein baliabide bezala.
$ kubectl get namespace komandoa erabiliz ikus ditzakezu izen-espazio guztiak.
Egindakoan, hiru izen-espazio integratu eta "test" izeneko izen-eremu berri bat ikusiko dituzu. Ikus dezagun YAML fitxategi soil bat pod bat sortzeko. Konturatuko zara ez dagoela izen-espazioaren aipamenik.
Fitxategi hau exekutatzeko kubectl erabiltzen baduzu, mypod modulua sortuko du une honetan aktibo dagoen izen-eremuan. Hau izango da izen-espazio lehenetsia aldatu arte. Kubernetesi zure baliabidea zein izen-espaziotan sortu nahi duzun esateko bi modu daude. Lehen modua baliabide bat sortzean izen-espazioaren bandera erabiltzea da.
Bigarren modua YAML deklarazioan izen-espazioa zehaztea da.
YAML-n izen-espazio bat zehazten baduzu, baliabidea beti sortuko da izen-espazio horretan. Izen-eremuaren bandera erabiltzen duzun bitartean beste izen-espazio bat erabiltzen saiatzen bazara, komandoak huts egingo du. Orain zure poda aurkitzen saiatzen bazara, ezin izango duzu egin.
Hau gertatzen da komando guztiak une honetan aktibo dagoen izen-espaziotik kanpo exekutatzen direlako. Zure poda aurkitzeko, izen-eremuaren bandera erabili behar duzu, baina hau azkar aspertzen da, batez ere bere izen-espazioa erabiltzen duen talde bateko garatzailea bazara eta ez baduzu bandera hori komando bakoitzerako erabili nahi. Ea nola konpondu dezakegun hau.
Kutxaz kanpo, zure izen-espazio aktibo lehenetsia deitzen da. Ez baduzu izen-espaziorik zehazten YAML baliabidean, Kubernetes-eko komando guztiek izen-espazio lehenetsi aktibo hau erabiliko dute. Zoritxarrez, kubectl erabiliz izen-espazio aktiboa kudeatzen saiatzeak huts egin dezake. Hala ere, badago Kubens izeneko tresna oso ona, prozesu hau askoz errazten duena. Kubens komandoa exekutatzen duzunean, izen-espazio aktiboa nabarmenduta duten izen-espazio guztiak ikusiko dituzu.
Izen-espazio aktiboa probako izen-espaziora aldatzeko, $kubens test komandoa exekutatu besterik ez duzu. $kubens komandoa berriro exekutatzen baduzu, izen-espazio aktibo berri bat esleituta dagoela ikusiko duzu - test.
Horrek esan nahi du ez duzula izen-espazioko bandera behar probako izen-eremuan poda ikusteko.
Horrela izen-espazioak elkarrengandik ezkutatzen dira, baina ez elkarrengandik isolatuta. Izen-espazio bateko zerbitzu bat nahiko erraz komunika daiteke beste izen-espazio bateko zerbitzu batekin, eta hori askotan oso erabilgarria da. Izen-espazio ezberdinetan komunikatzeko gaitasunak esan nahi du zure garatzaileen zerbitzua beste garatzaile-talde baten zerbitzuarekin beste izen-espazio batean komunika daitekeela.
Normalean, zure aplikazioak Kubernetes zerbitzu batera atzitu nahi duenean, integratutako DNS aurkikuntza zerbitzua erabiltzen duzu eta zure aplikazioari zerbitzuaren izena ematen diozu. Hala ere, hori eginez gero, izen bereko zerbitzu bat sor dezakezu hainbat izen-espaziotan, eta hori ez da onargarria.
Zorionez, hori erraza da DNS helbidearen forma zabaldua erabiliz. Kubernetes-eko zerbitzuek beren amaiera-puntuak erakusten dituzte DNS txantiloi arrunt bat erabiliz. Honela dirudi:
Normalean, zerbitzuaren izena besterik ez duzu behar eta DNS-k automatikoki zehaztuko du helbide osoa.
Hala ere, zerbitzu bat beste izen-espazio batean sartu behar baduzu, erabili zerbitzuaren izena gehi izen-eremuaren izena:
Adibidez, proba izen-espazio batean zerbitzu-datu-base batera konektatu nahi baduzu, helbide-datu-basea database.test erabil dezakezu
Prod izen-espazioko zerbitzuaren datu-basera konektatu nahi baduzu, database.prod erabiltzen duzu.
Benetan izen-espaziorako sarbidea isolatu eta mugatu nahi baduzu, Kubernetes-ek hau egiteko aukera ematen dizu Kubernetes sare-gidalerroak erabiliz. Hurrengo atalean hitz egingo dut honi buruz.
Askotan galdera egiten didate, zenbat izen-espazio sortu behar ditut eta zein helbururekin? Zer da kudeatutako datu bat?
Izen-espazio gehiegi sortzen badituzu, zure bidean jarriko dira. Horietako gutxiegi badaude, irtenbide horren onura guztiak galduko dituzu. Uste dut lau etapa nagusi daudela enpresa bakoitzak bere antolaketa-egitura sortzeko garaian. Zure proiektua edo enpresaren garapen-fasearen arabera, baliteke izen-espazioen estrategia egokia hartu nahi izatea.
Imajinatu 5-10 mikrozerbitzu garatzen ari den talde txiki baten parte zarela eta garatzaile guztiak gela batean erraz bil ditzakezula. Egoera honetan, zentzuzkoa da produktu-zerbitzu guztiak izen-espazio lehenetsian exekutatzeko. Jakina, malgutasun handiagoa lortzeko, 2 izen-espazio erabil ditzakezu - prod eta dev bereizita. Eta ziurrenik, zure garapena zure tokiko ordenagailuan probatuko duzu Minikube bezalako zerbait erabiliz.
Demagun gauzak aldatzen direla eta orain azkar hazten ari den talde bat duzula aldi berean 10 mikrozerbitzu baino gehiagotan lanean. Bada garaia non hainbat kluster edo izen-espazio erabiltzea beharrezkoa den, prod eta dev bereizita. Taldea hainbat azpitaldetan zati dezakezu, horietako bakoitzak bere mikrozerbitzuak izan ditzan eta talde horietako bakoitzak bere izen-espazioa aukeratu dezake softwarearen garapena eta kaleratzea kudeatzeko prozesua errazteko.
Taldekide bakoitzak sistema osoak nola funtzionatzen duen ulertzen duen heinean, gero eta zailagoa da aldaketa guztiak beste garatzaile guztiekin koordinatzea. Zure tokiko makinan pila osoa biratzen saiatzea gero eta zailagoa da egunero.
Enpresa handietan, garatzaileek, oro har, ez dakite nor ari den zehazki zertan lan egiten. Taldeak zerbitzu-kontratuak erabiliz komunikatzen dira edo zerbitzu sarearen teknologia erabiltzen dute, eta horrek abstrakzio-geruza bat gehitzen du sarean, hala nola Istio konfigurazio tresna. Pila osoa lokalean exekutatzen saiatzea ezinezkoa da. Biziki gomendatzen dut Kubernetes-en Spinnaker bezalako bidalketa jarraitua (CD) plataforma bat erabiltzea. Beraz, puntu bat iristen da non komando bakoitzak bere izen-espazio propioa behar du. Talde bakoitzak izen-espazio anitz aukeratu ditzake garapenerako ingurunerako eta produkturako ingurunerako.
Azkenik, badaude enpresa ekintzaile handiak garatzaile talde batek beste talde batzuen existentziaz ere ezagutzen ez duena. Konpainia horrek, oro har, ondo dokumentatutako APIen bidez elkarreragiten duten hirugarren garatzaileak kontratatu ditzake. Horrelako talde bakoitzak hainbat talde eta hainbat mikrozerbitzu ditu. Kasu honetan, lehen aipatu ditudan tresna guztiak erabili behar dituzu.
Programatzaileek ez dituzte eskuz zerbitzurik zabaldu behar eta ez lukete haiei dagozkien izen-espazioetarako sarbidea izan behar. Fase honetan, gomendagarria da hainbat kluster edukitzea gaizki konfiguratutako aplikazioen "eztanda-erradioa" murrizteko, fakturazio-prozesuak eta baliabideen kudeaketa errazteko.
Horrela, zure erakundeak izen-espazioen erabilera egokiak Kubernetes kudeagarriagoa, kontrolagarriagoa, seguruagoa eta malguagoa izatea ahalbidetzen du.
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com