As jo begjinne mei it meitsjen fan mear en mear Kubernetes-tsjinsten, begjinne taken dy't yn earste ynstânsje ienfâldich binne komplekser te wurden. Bygelyks kinne ûntwikkelingsteams gjin tsjinsten of ynset meitsje ûnder deselde namme. As jo tûzenen pods hawwe, sil it gewoan opjaan fan se in protte tiid nimme, lit stean se goed beheare. En dit is mar it tip fan 'e iisberch.
Litte wy sjen nei hoe't de nammeromte it makliker makket om Kubernetes-boarnen te behearjen. Dus wat is in nammeromte? Nammeromte kin beskôge wurde as in firtuele kluster binnen jo Kubernetes-kluster. Jo kinne meardere nammeromten hawwe isolearre fan elkoar binnen ien Kubernetes-kluster. Se kinne jo en jo teams wirklik helpe mei organisaasje, feiligens, en sels systeemprestaasjes.
Op de measte Kubernetes-distribúsjes komt it kluster út it fak mei in nammeromte neamd "standert". D'r binne eins trije nammeromten wêrmei Kubernetes omgiet: standert, kube-systeem en kube-publyk. Op it stuit wurdt Kube-publyk net heul faak brûkt.
It ferlitten fan de kube nammeromte allinnich is in goed idee, benammen op in beheard systeem lykas Google Kubernetes Engine. It brûkt de "standert" nammeromte as it plak dêr't jo tsjinsten en applikaasjes wurde makke. Der is hielendal neat spesjaal oer it, útsein dat Kubernetes is konfigurearre út it fak foar in gebrûk it, en do kinst net fuortsmite it. Dit is geweldich om te begjinnen en systemen mei lege prestaasjes, mar ik soe de standert nammeromte net oanrikkemandearje op grutte prodsystemen. Yn it lêste gefal kin ien ûntwikkelteam de koade fan in oar maklik oerskriuwe en it wurk fan in oar team brekke sûnder it sels te realisearjen.
Dêrom moatte jo meardere nammeromten oanmeitsje en se brûke om jo tsjinsten te segmentearjen yn behearbere ienheden. In nammeromte kin makke wurde mei ien kommando. As jo in nammeromte mei de namme test wolle oanmeitsje, brûk dan it kommando $ kubectl meitsje nammeromte test of meitsje gewoan in YAML-bestân en brûk it lykas elke oare Kubernetes-boarne.
Jo kinne alle nammeromten besjen mei it kommando $ kubectl get namespace.
As it klear is, sille jo trije ynboude nammeromten sjen en in nije nammeromte mei de namme "test". Litte wy nei in ienfâldich YAML-bestân sjen om in pod te meitsjen. Jo sille merke dat der gjin sprake is fan nammeromte.
As jo kubectl brûke om dit bestân út te fieren, sil it de mypod-module meitsje yn 'e op it stuit aktive nammeromte. Dit sil de standert nammeromte wêze oant jo it wizigje. D'r binne 2 manieren om Kubernetes te fertellen yn hokker nammeromte jo jo boarne wolle oanmeitsje. De earste manier is om in nammeromteflagge te brûken by it meitsjen fan in boarne.
De twadde manier is om de nammeromte oan te jaan yn 'e YAML-deklaraasje.
As jo in nammeromte yn YAML oantsjutte, sil de boarne altyd yn dy nammeromte oanmakke wurde. As jo besykje in oare nammeromte te brûken by it brûken fan de nammeromteflagge, sil it kommando mislearje. No as jo besykje jo pod te finen, kinne jo dat net dwaan.
Dit bart omdat alle kommando's wurde útfierd bûten de op it stuit aktive nammeromte. Om jo pod te finen, moatte jo in nammeromteflagge brûke, mar dit wurdt rap saai, foaral as jo in ûntwikkelder binne yn in team dat syn eigen nammeromte brûkt en dy flagge net foar elk inkeld kommando brûke wol. Litte wy sjen hoe't wy dit kinne reparearje.
Ut it fak wurdt jo aktive nammeromte standert neamd. As jo gjin nammeromte yn 'e boarne YAML spesifisearje, dan sille alle Kubernetes-kommando's dizze aktive standertnammeromte brûke. Spitigernôch kin it besykjen om de aktive nammeromte te behearjen mei kubectl mislearje. D'r is lykwols in heul goed ark neamd Kubens dat dit proses folle makliker makket. As jo it kommando kubens útfiere, sjogge jo alle nammeromten mei de aktive nammeromte markearre.
Om de aktive nammeromte te wikseljen nei de testnammeromte, kinne jo gewoan it testkommando $kubens útfiere. As jo dan it kommando $kubens nochris útfiere, sille jo sjen dat der no in nije aktive nammeromte is tawiisd - test.
Dit betsjut dat jo de nammeromteflagge net nedich hawwe om de pod yn 'e testnammeromte te sjen.
Sa wurde de nammeromten fan inoar ferburgen, mar net fan inoar isolearre. In tsjinst yn ien nammeromte kin frij maklik kommunisearje mei in tsjinst yn in oare nammeromte, wat faaks tige nuttich is. De mooglikheid om te kommunisearjen oer ferskate nammeromten betsjut dat de tsjinst fan jo ûntwikkelders kin kommunisearje mei de tsjinst fan in oar dev-team yn in oare nammeromte.
Typysk, as jo applikaasje tagong wol ta in Kubernetes-tsjinst, brûke jo de ynboude DNS-ûntdekkingstsjinst en jou jo applikaasje gewoan de namme fan 'e tsjinst. Troch dit te dwaan kinne jo lykwols in tsjinst meitsje ûnder deselde namme yn meardere nammeromten, wat net akseptabel is.
Gelokkich is dit maklik om te kommen troch de útwreide foarm fan it DNS-adres te brûken. Tsjinsten yn Kubernetes bleatstelle har einpunten mei in mienskiplik DNS-sjabloan. It sjocht der sa út:
Typysk hawwe jo gewoan de tsjinstnamme nedich en DNS sil automatysk it folsleine adres bepale.
As jo lykwols tagong moatte ta in tsjinst yn in oare nammeromte, brûk dan gewoan de tsjinstnamme plus de nammeromte:
As jo bygelyks ferbine wolle mei in tsjinstdatabase yn in testnammeromte, kinne jo de adresdatabase database.test brûke
As jo wolle ferbine mei de tsjinst databank yn de prod nammeromte, Jo brûke database.prod.
As jo wirklik tagong ta nammeromte isolearje en beheine wolle, lit Kubernetes jo dit dwaan mei Kubernetes Network Policies. Ik sil it oer dit yn 'e folgjende ôflevering.
Ik wurd faak de fraach steld, hoefolle nammeromten moat ik meitsje en foar hokker doelen? Wat is in beheard stik gegevens?
As jo tefolle nammeromten oanmeitsje, sille se jo gewoan yn 'e wei komme. As d'r te min binne, sille jo alle foardielen fan sa'n oplossing ferlieze. Ik tink dat d'r fjouwer haadstadia binne dy't elk bedriuw trochgiet by it meitsjen fan har organisaasjestruktuer. Ofhinklik fan it stadium fan ûntwikkeling wêryn jo projekt of bedriuw is, wolle jo miskien in passende nammeromtestrategy oannimme.
Stel jo foar dat jo diel útmeitsje fan in lyts team dat wurket oan it ûntwikkeljen fan 5-10 mikrotsjinsten en jo kinne alle ûntwikkelders maklik yn ien keamer sammelje. Yn dizze situaasje makket it sin om alle prod-tsjinsten út te fieren yn 'e standert nammeromte. Fansels kinne jo foar mear fleksibiliteit 2 nammeromten brûke - apart foar prod en dev. En wierskynlik testje jo jo ûntwikkeling op jo lokale komputer mei soksoarte as Minikube.
Litte wy sizze dat dingen feroarje en jo hawwe no in rap groeiend team dat wurket oan mear dan 10 mikrotsjinsten tagelyk. Der komt in tiid dat it nedich is om ferskate klusters of nammeromten te brûken, apart foar prod en dev. Jo kinne it team yn ferskate sub-teams brekke, sadat elk fan har har eigen mikrotsjinsten hat en elk fan dizze teams kin har eigen nammeromte kieze om it proses fan it behearen fan softwareûntwikkeling en frijlitting te fasilitearjen.
As elk teamlid ynsjoch krijt yn hoe't it systeem as gehiel wurket, wurdt it hieltyd dreger om elke feroaring te koördinearjen mei alle oare ûntwikkelders. Besykje te spin up in folsleine steapel op jo lokale masine wurdt hieltyd dreger eltse dei.
Yn grutte bedriuwen witte ûntwikkelders oer it generaal net wa't krekt oan wat wurket. Teams kommunisearje mei tsjinstkontrakten of brûke tsjinstmesh-technology, dy't in abstraksjelaach tafoeget oer it netwurk, lykas it Istio-konfiguraasjeark. Besykje te rinnen in hiele stack lokaal is gewoan net mooglik. Ik riede tige oan in gebrûk in trochgeande levering (CD) platfoarm lykas Spinnaker op Kubernetes. Dat, d'r komt in punt wêr't elk kommando perfoarst syn eigen nammeromte nedich hat. Elk team kin sels meardere nammeromten kieze foar de dev-omjouwing en de prod-omjouwing.
Uteinlik binne d'r grutte ûndernimmende bedriuwen wêryn ien groep ûntwikkelders net iens wit oer it bestean fan oare groepen. Sa'n bedriuw kin oer it algemien ûntwikkelders fan tredden ynhiere dy't mei har ynteraksje fia goed dokuminteare API's. Elke sa'n groep befettet ferskate teams en ferskate mikrotsjinsten. Yn dit gefal moatte jo alle ark brûke wêr't ik earder oer praat.
Programmeurs moatte gjin tsjinsten mei de hân ynsette en moatte gjin tagong hawwe ta nammeromten dy't har net oangeane. Op dit stadium is it oan te rieden om ferskate klusters te hawwen om de "blastradius" fan min konfigureare applikaasjes te ferminderjen, om fakturearringprosessen en boarnebehear te ferienfâldigjen.
Sa, goed gebrûk fan nammeromten troch jo organisaasje kinne jo meitsje Kubernetes mear beheare, kontrolearber, feilich, en fleksibeler.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com