Soos jy meer en meer Kubernetes-dienste begin skep, begin take wat aanvanklik eenvoudig is, meer kompleks word. Ontwikkelingspanne kan byvoorbeeld nie dienste of ontplooiings onder dieselfde naam skep nie. As jy duisende peule het, sal dit baie tyd neem om hulle bloot te lys, wat nog te sê om hulle behoorlik te bestuur. En dit is net die punt van die ysberg.
Kom ons kyk hoe die naamruimte dit makliker maak om Kubernetes-hulpbronne te bestuur. So, wat is 'n naamruimte? Namespace kan beskou word as 'n virtuele groep binne jou Kubernetes-groepering. Jy kan veelvuldige naamruimtes van mekaar geïsoleer hê binne 'n enkele Kubernetes-kluster. Hulle kan jou en jou spanne regtig help met organisasie, sekuriteit en selfs stelselprestasie.
Op die meeste Kubernetes-verspreidings kom die groep uit die boks met 'n naamruimte genaamd "verstek". Daar is eintlik drie naamruimtes waarmee Kubernetes handel: verstek, kube-stelsel en kube-publiek. Tans word Kube-publiek nie baie gereeld gebruik nie.
Om die kube-naamruimte alleen te laat is 'n goeie idee, veral in 'n bestuurde stelsel soos Google Kubernetes Engine. Dit gebruik die "verstek" naamruimte as die plek waar jou dienste en toepassings geskep word. Daar is absoluut niks besonders daaraan nie, behalwe dat Kubernetes uit die boks gekonfigureer is om dit te gebruik, en jy kan dit nie verwyder nie. Dit is wonderlik om aan die gang te kom en stelsels met lae werkverrigting, maar ek sal nie aanbeveel om die standaard naamruimte op groot produkstelsels te gebruik nie. In laasgenoemde geval kan een ontwikkelingspan maklik iemand anders se kode herskryf en 'n ander span se werk breek sonder om dit eers te besef.
Daarom moet jy veelvuldige naamruimtes skep en dit gebruik om jou dienste in hanteerbare eenhede te segmenteer. 'n Naamspasie kan met 'n enkele opdrag geskep word. As jy 'n naamruimte met die naam toets wil skep, gebruik dan die opdrag $ kubectl skep naamruimtetoets of skep eenvoudig 'n YAML-lêer en gebruik dit soos enige ander Kubernetes-hulpbron.
Jy kan alle naamruimtes bekyk deur die $ kubectl get namespace-opdrag te gebruik.
Sodra dit klaar is, sal jy drie ingeboude naamruimtes en 'n nuwe naamruimte genaamd "toets" sien. Kom ons kyk na 'n eenvoudige YAML-lêer om 'n peul te skep. Jy sal agterkom dat daar geen melding van naamruimte is nie.
As jy kubectl gebruik om hierdie lêer te laat loop, sal dit die mypod-module in die huidige aktiewe naamruimte skep. Dit sal die verstek naamspasie wees totdat jy dit verander. Daar is 2 maniere om vir Kubernetes te vertel in watter naamruimte jy jou hulpbron wil skep. Die eerste manier is om 'n naamruimtevlag te gebruik wanneer 'n hulpbron geskep word.
Die tweede manier is om die naamruimte in die YAML-verklaring te spesifiseer.
As jy 'n naamruimte in YAML spesifiseer, sal die hulpbron altyd in daardie naamruimte geskep word. As jy probeer om 'n ander naamruimte te gebruik terwyl jy die naamruimtevlag gebruik, sal die opdrag misluk. As jy nou jou peul probeer vind, sal jy dit nie kan doen nie.
Dit gebeur omdat alle opdragte buite die huidige aktiewe naamruimte uitgevoer word. Om jou pod te vind, moet jy 'n naamruimtevlag gebruik, maar dit raak vinnig vervelig, veral as jy 'n ontwikkelaar is in 'n span wat sy eie naamruimte gebruik en nie daardie vlag vir elke enkele opdrag wil gebruik nie. Kom ons kyk hoe ons dit kan regmaak.
Uit die boks word jou aktiewe naamruimte verstek genoem. As jy nie 'n naamspasie in die hulpbron YAML spesifiseer nie, sal alle Kubernetes-opdragte hierdie aktiewe versteknaamspasie gebruik. Ongelukkig kan dit misluk om die aktiewe naamruimte met behulp van kubectl te probeer bestuur. Daar is egter 'n baie goeie hulpmiddel genaamd Kubens wat hierdie proses baie makliker maak. Wanneer jy die kubens-opdrag uitvoer, sien jy alle naamruimtes met die aktiewe naamspasie uitgelig.
Om die aktiewe naamruimte na die toetsnaamruimte oor te skakel, voer jy eenvoudig die $kubens-toetsopdrag uit. As jy dan weer die $kubens-opdrag uitvoer, sal jy sien dat 'n nuwe aktiewe naamruimte nou toegeken is - toets.
Dit beteken dat jy nie die naamruimtevlag nodig het om die pod in die toetsnaamruimte te sien nie.
Op hierdie manier word die naamruimtes vir mekaar versteek, maar nie van mekaar geïsoleer nie. 'n Diens in een naamruimte kan redelik maklik met 'n diens in 'n ander naamruimte kommunikeer, wat dikwels baie nuttig is. Die vermoë om oor verskillende naamruimtes te kommunikeer beteken dat jou ontwikkelaars se diens met 'n ander ontwikkelaarspan se diens in 'n ander naamruimte kan kommunikeer.
Tipies, wanneer jou toepassing toegang tot 'n Kubernetes-diens wil hê, gebruik jy die ingeboude DNS-ontdekkingsdiens en gee bloot vir jou toepassing die naam van die diens. Deur dit te doen, kan jy egter 'n diens onder dieselfde naam in verskeie naamruimtes skep, wat nie aanvaarbaar is nie.
Gelukkig is dit maklik om oor die weg te kom deur die uitgebreide vorm van die DNS-adres te gebruik. Dienste in Kubernetes stel hul eindpunte bloot deur 'n algemene DNS-sjabloon te gebruik. Dit lyk so iets:
Tipies het jy net die diensnaam nodig en DNS sal outomaties die volledige adres bepaal.
As jy egter toegang tot 'n diens in 'n ander naamruimte moet kry, gebruik eenvoudig die diensnaam plus die naamruimtenaam:
As jy byvoorbeeld aan 'n diensdatabasis in 'n toetsnaamruimte wil koppel, kan jy die adresdatabasis database.test gebruik
As jy wil koppel aan die diensdatabasis in die prod naamruimte, gebruik jy database.prod.
As jy werklik naamruimtetoegang wil isoleer en beperk, laat Kubernetes jou toe om dit te doen deur Kubernetes-netwerkbeleide te gebruik. Ek sal in die volgende episode hieroor praat.
Ek word gereeld die vraag gevra, hoeveel naamruimtes moet ek skep en vir watter doeleindes? Wat is 'n bestuurde stuk data?
As jy te veel naamruimtes skep, sal hulle net in jou pad kom. As daar te min van hulle is, sal jy al die voordele van so 'n oplossing verloor. Ek dink daar is vier hoofstadia waardeur elke maatskappy gaan wanneer hulle sy organisasiestruktuur skep. Afhangende van die stadium van ontwikkeling waarin jou projek of maatskappy is, wil jy dalk 'n toepaslike naamruimtestrategie aanneem.
Stel jou voor dat jy deel is van 'n klein span wat besig is om 5-10 mikrodienste te ontwikkel en jy kan maklik al die ontwikkelaars in een kamer versamel. In hierdie situasie is dit sinvol om alle prod-dienste in die versteknaamruimte uit te voer. Natuurlik, vir meer buigsaamheid, kan jy 2 naamruimtes gebruik - afsonderlik vir prod en dev. En heel waarskynlik toets jy jou ontwikkeling op jou plaaslike rekenaar met iets soos Minikube.
Kom ons sê dinge verander en jy het nou 'n vinnig groeiende span wat aan meer as 10 mikrodienste op 'n slag werk. Daar kom 'n tyd wanneer dit nodig is om verskeie groepe of naamruimtes te gebruik, afsonderlik vir prod en dev. Jy kan die span in verskeie sub-spanne verdeel sodat elkeen van hulle sy eie mikrodienste het en elkeen van hierdie spanne kan sy eie naamruimte kies om die proses van bestuur van sagteware-ontwikkeling en vrystelling te vergemaklik.
Soos elke spanlid insig kry in hoe die stelsel as geheel werk, word dit al hoe moeiliker om elke verandering met al die ander ontwikkelaars te koördineer. Om 'n volle stapel op jou plaaslike masjien te probeer optel, word elke dag moeiliker.
In groot maatskappye weet ontwikkelaars oor die algemeen nie wie presies aan wat werk nie. Spanne kommunikeer deur dienskontrakte te gebruik of gebruik diensnetwerktegnologie, wat 'n abstraksielaag oor die netwerk byvoeg, soos die Istio-konfigurasienutsding. Om 'n hele stapel plaaslik te probeer laat loop is eenvoudig nie moontlik nie. Ek beveel sterk aan om 'n platform vir deurlopende aflewering (CD) soos Spinnaker op Kubernetes te gebruik. So, daar kom 'n punt waar elke opdrag beslis sy eie naamruimte benodig. Elke span kan selfs veelvuldige naamruimtes kies vir die dev-omgewing en die prod-omgewing.
Laastens is daar groot entrepreneursmaatskappye waarin een groep ontwikkelaars nie eers weet van die bestaan van ander groepe nie. So 'n maatskappy kan oor die algemeen derdeparty-ontwikkelaars huur wat met hom interaksie het deur goed gedokumenteerde API's. Elke so 'n groep bevat verskeie spanne en verskeie mikrodienste. In hierdie geval moet u al die gereedskap gebruik waaroor ek vroeër gepraat het.
Programmeerders moet nie dienste handmatig ontplooi nie en moet nie toegang hê tot naamruimtes wat hulle nie aangaan nie. Op hierdie stadium is dit raadsaam om verskeie groepe te hê om die "ontploffingsradius" van swak gekonfigureerde toepassings te verminder, om faktuurprosesse en hulpbronbestuur te vereenvoudig.
Dus, behoorlike gebruik van naamruimtes deur jou organisasie stel jou in staat om Kubernetes meer hanteerbaar, beheerbaar, veilig en buigsaam te maak.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com