Kako počnete stvarati sve više i više Kubernetes servisa, zadaci koji su u početku jednostavni počinju da postaju složeniji. Na primjer, razvojni timovi ne mogu kreirati usluge ili implementacije pod istim imenom. Ako imate hiljade mahuna, jednostavno njihovo navođenje će oduzeti mnogo vremena, a kamoli pravilno upravljanje njima. A ovo je samo vrh ledenog brega.
Pogledajmo kako prostor imena olakšava upravljanje Kubernetes resursima. Dakle, šta je imenski prostor? Imenski prostor se može smatrati virtuelnim klasterom unutar vašeg Kubernetes klastera. Možete imati više prostora imena izolovanih jedan od drugog unutar jednog Kubernetes klastera. Oni zaista mogu pomoći vama i vašim timovima u organizaciji, sigurnosti, pa čak i performansama sistema.
Na većini Kubernetes distribucija, klaster izlazi iz kutije sa prostorom imena koji se naziva "default". U stvari, postoje tri prostora imena kojima se Kubernetes bavi: default, kube-system i kube-public. Trenutno se Kube-public ne koristi često.
Ostavljanje kube imenskog prostora na miru je dobra ideja, posebno na upravljanom sistemu kao što je Google Kubernetes Engine. Koristi "podrazumevani" imenski prostor kao mjesto gdje se kreiraju vaše usluge i aplikacije. Nema apsolutno ništa posebno u vezi sa tim, osim što je Kubernetes konfigurisan da ga koristi i ne možete ga ukloniti. Ovo je odlično za početak rada i sisteme niskih performansi, ali ne bih preporučio korištenje zadanog prostora imena na velikim prod sistemima. U drugom slučaju, jedan razvojni tim može lako prepisati tuđi kod i pokvariti rad drugog tima, a da toga nije ni svjesno.
Stoga biste trebali kreirati više prostora imena i koristiti ih za segmentiranje vaših usluga u jedinice kojima se može upravljati. Imenski prostor se može kreirati jednom naredbom. Ako želite da kreirate prostor imena pod nazivom test, onda koristite naredbu $ kubectl create namespace test ili jednostavno kreirajte YAML datoteku i koristite je kao bilo koji drugi Kubernetes resurs.
Možete vidjeti sve prostore imena koristeći naredbu $ kubectl get namespace.
Kada se to završi, vidjet ćete tri ugrađena imenska prostora i novi prostor imena pod nazivom "test". Pogledajmo jednostavnu YAML datoteku za kreiranje pod. Primijetit ćete da se ne spominje prostor imena.
Ako koristite kubectl za pokretanje ove datoteke, kreirat će mypod modul u trenutno aktivnom imenskom prostoru. Ovo će biti zadani prostor imena dok ga ne promijenite. Postoje 2 načina da kažete Kubernetesu u kojem imenskom prostoru želite da kreirate svoj resurs. Prvi način je korištenje oznake prostora imena prilikom kreiranja resursa.
Drugi način je da navedete prostor imena u YAML deklaraciji.
Ako navedete imenski prostor u YAML-u, resurs će uvijek biti kreiran u tom imenskom prostoru. Ako pokušate koristiti drugi imenski prostor dok koristite oznaku prostora imena, naredba neće uspjeti. Sada, ako pokušate pronaći svoju kapsulu, nećete to moći učiniti.
Ovo se događa zato što se sve naredbe izvršavaju izvan trenutno aktivnog imenskog prostora. Da biste pronašli svoj pod, morate koristiti oznaku prostora imena, ali ovo brzo postaje dosadno, posebno ako ste programer u timu koji koristi svoj vlastiti imenski prostor i ne želi koristiti tu zastavicu za svaku pojedinu naredbu. Hajde da vidimo kako to možemo popraviti.
Izvan kutije, vaš aktivni prostor imena naziva se default. Ako ne navedete imenski prostor u resursu YAML, tada će sve Kubernetes komande koristiti ovaj aktivni zadani prostor imena. Nažalost, pokušaj upravljanja aktivnim prostorom imena pomoću kubectl-a može propasti. Međutim, postoji vrlo dobar alat pod nazivom Kubens koji uvelike olakšava ovaj proces. Kada pokrenete naredbu kubens, vidite sve prostore imena sa istaknutim aktivnim prostorom imena.
Da biste prebacili aktivni imenski prostor u prostor testa, jednostavno pokrenite naredbu $kubens test. Ako zatim ponovo pokrenete naredbu $kubens, vidjet ćete da je sada dodijeljen novi aktivni prostor imena - test.
To znači da vam nije potrebna oznaka prostora imena da biste vidjeli pod u testnom imenskom prostoru.
Na ovaj način su imenski prostori skriveni jedan od drugog, ali nisu izolovani jedan od drugog. Usluga u jednom imenskom prostoru može prilično lako komunicirati sa uslugom u drugom imenskom prostoru, što je često vrlo korisno. Mogućnost komuniciranja u različitim imenskim prostorima znači da usluga vašeg programera može komunicirati sa uslugom drugog razvojnog tima u drugom imenskom prostoru.
Obično, kada vaša aplikacija želi pristupiti servisu Kubernetes, koristite ugrađenu uslugu otkrivanja DNS-a i jednostavno svojoj aplikaciji date naziv usluge. Međutim, na taj način možete kreirati uslugu pod istim imenom u više imenskih prostora, što nije prihvatljivo.
Srećom, ovo je lako zaobići korištenjem proširenog oblika DNS adrese. Usluge u Kubernetesu izlažu svoje krajnje tačke koristeći zajednički DNS šablon. To izgleda otprilike ovako:
Obično vam je potrebno samo ime usluge i DNS će automatski odrediti punu adresu.
Međutim, ako trebate pristupiti servisu u drugom imenskom prostoru, jednostavno koristite ime usluge plus ime imenskog prostora:
Na primjer, ako želite da se povežete na servisnu bazu podataka u testnom imenskom prostoru, možete koristiti bazu podataka adresa baze podataka.test
Ako se želite povezati na servisnu bazu podataka u prod imenskom prostoru, koristite database.prod.
Ako zaista želite da izolujete i ograničite pristup prostoru imena, Kubernetes vam dozvoljava da to uradite pomoću Kubernetes mrežnih smernica. O tome ću govoriti u sljedećoj epizodi.
Često mi se postavlja pitanje koliko imenskih prostora treba da kreiram i u koju svrhu? Šta je upravljani dio podataka?
Ako kreirate previše imenskih prostora, oni će vam samo stati na put. Ako ih je premalo, izgubit ćete sve prednosti takvog rješenja. Mislim da postoje četiri glavne faze kroz koje svaka kompanija prolazi prilikom kreiranja svoje organizacione strukture. U zavisnosti od faze razvoja u kojoj se nalazi vaš projekat ili kompanija, možda ćete želeti da usvojite odgovarajuću strategiju imenskog prostora.
Zamislite da ste dio malog tima koji radi na razvoju 5-10 mikroservisa i lako možete okupiti sve programere u jednoj prostoriji. U ovoj situaciji, ima smisla pokrenuti sve prod servise u zadanom imenskom prostoru. Naravno, za veću fleksibilnost, možete koristiti 2 prostora imena - odvojeno za prod i dev. I najvjerovatnije, testirate svoj razvoj na svom lokalnom računaru koristeći nešto poput Minikubea.
Recimo da se stvari mijenjaju i da sada imate brzo rastući tim koji istovremeno radi na više od 10 mikroservisa. Dođe vrijeme kada je potrebno koristiti nekoliko klastera ili imenskih prostora, odvojeno za prod i dev. Možete podijeliti tim u nekoliko pod-timova tako da svaki od njih ima svoje mikroservise i svaki od tih timova može odabrati svoj vlastiti prostor imena kako bi olakšao proces upravljanja razvojem i izdavanjem softvera.
Kako svaki član tima stječe uvid u to kako sistem u cjelini funkcionira, postaje sve teže koordinirati svaku promjenu sa svim ostalim programerima. Svakim danom sve je teže pokušavati da dobijete pun stack na vašoj lokalnoj mašini.
U velikim kompanijama programeri uglavnom ne znaju ko tačno na čemu radi. Timovi komuniciraju koristeći ugovore o uslugama ili koriste tehnologiju servisne mreže, koja dodaje sloj apstrakcije preko mreže, kao što je Istio alat za konfiguraciju. Pokušaj lokalnog pokretanja cijelog steka jednostavno nije moguć. Toplo preporučujem korištenje platforme za kontinuiranu isporuku (CD) kao što je Spinnaker na Kubernetesu. Dakle, dolazi do tačke u kojoj svaka naredba definitivno treba svoj vlastiti imenski prostor. Svaki tim čak može izabrati više prostora imena za dev okruženje i prod okruženje.
Konačno, postoje velike preduzetničke kompanije u kojima jedna grupa programera i ne zna za postojanje drugih grupa. Takva kompanija općenito može unajmiti programere treće strane koji s njom komuniciraju putem dobro dokumentiranih API-ja. Svaka takva grupa sadrži nekoliko timova i nekoliko mikroservisa. U ovom slučaju morate koristiti sve alate o kojima sam ranije govorio.
Programeri ne bi trebali ručno postavljati usluge i ne bi trebali imati pristup imenskim prostorima koji ih se ne tiču. U ovoj fazi, preporučljivo je imati nekoliko klastera kako bi se smanjio „radijus eksplozije“ loše konfiguriranih aplikacija, kako bi se pojednostavili procesi naplate i upravljanje resursima.
Dakle, pravilna upotreba prostora imena od strane vaše organizacije omogućava vam da Kubernetes učinite upravljivijim, pod kojim se može kontrolirati, sigurnijim i fleksibilnijim.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com