Pe măsură ce începeți să creați tot mai multe servicii Kubernetes, sarcinile inițial simple devin mai complexe. De exemplu, echipele de dezvoltare nu pot crea servicii sau desfășurări cu același nume. Dacă aveți mii de poduri, enumerarea acestora va dura mult timp, fără a menționa gestionarea corectă a acestora. Și aceasta este doar vârful aisbergului.
Să analizăm cum spațiul de nume facilitează gestionarea resurselor Kubernetes. Așadar, ce este un spațiu de nume? Un spațiu de nume poate fi considerat un cluster virtual în cadrul cluster-ului dvs. Kubernetes. Puteți avea mai multe spații de nume izolate unul de celălalt într-un singur cluster Kubernetes. Acestea pot ajuta cu adevărat pe dvs. și echipele dvs. în organizare, securitate și chiar performanță a sistemului.
În majoritatea distribuțiilor Kubernetes, cluster-ul vine „din fabrică” cu un spațiu de nume numit „default”. De fapt, există trei spații de nume cu care Kubernetes interacționează: default, kube-system și kube-public. În prezent, Kube-public nu este utilizat foarte des.
E bine să nu modificați spațiul de nume kube, mai ales într-un sistem gestionat, cum ar fi Google Kubernetes Engine. Acesta folosește spațiul de nume „default” ca loc pentru a crea serviciile și aplicațiile dvs. Nu are absolut nimic special, în afară de faptul că Kubernetes este configurat „din fabrică” să-l utilizeze, și nu puteți să-l ștergeți. Este ideal pentru a începe și pentru sistemele cu performanță mică, dar nu aș recomanda utilizarea spațiului de nume default în sistemele mari de producție. În acest ultim caz, o echipă de dezvoltatori ar putea scrie ușor codul altcuiva și ar putea afecta munca altei echipe, fără să conștientizeze acest lucru.
De aceea ar trebui să creați mai multe spații de nume și să le folosiți pentru a segmenta serviciile în link-uri gestionate. Un spațiu de nume poate fi creat cu o singură comandă. Dacă doriți să creați un spațiu de nume numit test, folosiți comanda $ kubectl create namespace test sau creați pur și simplu un fișier YAML și folosiți-l ca pe orice alt resurs Kubernetes.
Puteți vizualiza toate spațiile de nume utilizând comanda $ kubectl get namespace.
După finalizarea acesteia, veți vedea trei spații de nume integrate și un nou spațiu de nume numit „test”. Să examinăm un fișier YAML simplu, destinat să creeze un pod. Se poate observa că nu există nicio mențiune a spațiului de nume.
Dacă utilizați kubectl pentru a rula acest fișier, va crea modulul mypod în spațiul de nume activ actual. Acesta va fi spațiul de nume implicit, până când îl schimbați. Există două moduri de a informa Kubernetes în ce spațiu de nume doriți să creați resursa dvs. Primul mod este de a folosi flag-ul de spațiu de nume atunci când creați resursa.
Al doilea mod constă în a specifica spațiul de nume în declarația YAML.
Dacă specificați spațiul de nume în YAML, atunci resursa va fi întotdeauna creată în acest spațiu. Dacă încercați să folosiți un alt spațiu de nume când folosiți flag-ul de spațiu de nume, comanda va eșua. Acum, dacă încercați să găsiți podul dvs., nu veți putea face acest lucru.
Acest lucru se întâmplă deoarece toate comenzile sunt executate în afara spațiului de nume activ curent. Pentru a găsi podul dvs., trebuie să folosiți flag-ul de spațiu de nume, însă acest lucru devine rapid plictisitor, mai ales dacă lucrați ca dezvoltator într-un grup care folosește propriul spațiu de nume și nu vrea să folosească un astfel de flag pentru fiecare comandă. Să vedem cum putem rezolva această problemă.
Din fabricație, spațiul de nume activ se numește default. Dacă nu específicați spațiul de nume în YAML-ul resursei, toate comenzile Kubernetes vor folosi acest spațiu de nume activ default. Din păcate, încercarea de a gestiona spațiul de nume activ cu kubectl poate eșua. Totuși, există un instrument excelent numit Kubens care simplifică mult acest proces. Când rulați comanda kubens, vedeți toate spațiile de nume cu spațiul de nume activ evidențiat.
Pentru a schimba spațiul de nume activ în spațiul de nume test, trebuie doar să rulați comanda $ kubens test. Dacă, după aceasta, introduceți din nou comanda $ kubens, puteți observa că acum este evidențiat un nou spațiu de nume activ – test.
Aceasta înseamnă că nu aveți nevoie de un steag de spațiu de nume pentru a vedea pod-ul în spațiul de nume test.
Astfel, spațiile de nume sunt ascunse una de cealaltă, dar nu sunt izolate. Un serviciu dintr-un spațiu de nume poate comunica destul de ușor cu un serviciu din alt spațiu de nume, ceea ce este adesea foarte util. Posibilitatea de comunicare între diferite spații de nume înseamnă că serviciul dezvoltatorilor dumneavoastră poate interacționa cu serviciul unei alte echipe de dezvoltare într-un alt spațiu de nume.
De obicei, atunci când aplicația dvs. dorește să acceseze un serviciu Kubernetes, folosiți serviciul de descoperire DNS încorporat și pur și simplu indicați aplicației numele serviciului. Cu toate acestea, puteți crea un serviciu cu același nume în mai multe spații de nume, ceea ce este inacceptabil.
Din fericire, acest lucru este ușor de ocolit, folosind forma extinsă a adresei DNS. Serviciile din Kubernetes își expun punctele finale folosind un șablon comun DNS. Acesta arată cam așa:
În general, trebuie doar să furnizați numele serviciului, iar DNS va determina automat adresa completă.
Cu toate acestea, dacă trebuie să accesați un serviciu dintr-un alt spațiu de nume, folosiți pur și simplu numele serviciului plus numele spațiului de nume:
De exemplu, dacă doriți să vă conectați la baza de date a serviciului din spațiul de nume de testare, puteți folosi adresa database.test.
Dacă doriți să vă conectați la baza de date a serviciului din spațiul de nume prod, utilizați database.prod.
Dacă doriți cu adevărat să izolați și să restricționați accesul la un spațiu de nume, Kubernetes vă permite să faceți acest lucru prin intermediul politicilor de rețea Kubernetes Network Policies. Voi discuta despre asta în următoarea serie.
Mi se pune adesea întrebarea câte spații de nume ar trebui să creați și în ce scopuri? Ce reprezintă un fragment de date gestionat?
Dacă creați prea multe namespace-uri, acestea vor deveni o piedică. Dar dacă sunt prea puține, veți pierde toate avantajele unei astfel de soluții. Cred că există patru etape principale prin care trece fiecare companie în procesul de creare a structurii sale organizaționale. În funcție de etapa de dezvoltare în care se află proiectul sau compania dumneavoastră, puteți adopta strategia corespunzătoare pentru crearea namespace-urilor.
Imaginați-vă că faceți parte dintr-o echipă mică care lucrează la dezvoltarea a 5-10 microservicii și că puteți aduna ușor toți dezvoltatorii într-o cameră. În această situație, are sens să rulați toate serviciile prod în namespace-ul default. Desigur, pentru mai multă libertate de acțiune, puteți utiliza 2 namespace-uri – câte unul pentru prod și dev. Cel mai probabil, testați dezvoltarea pe computerul local folosind ceva de genul Minikube.
Să presupunem că condițiile s-au schimbat și acum aveți o echipă în rapidă expansiune care lucrează simultan la mai mult de 10 microservicii. Vine un moment când este necesar să folosiți mai multe clustere sau namespace-uri, separate pentru prod și dev. Puteți împărți echipa în mai multe subgrupuri, astfel încât fiecare să aibă propriile microservicii și fiecare dintre aceste echipe să poată alege propriul namespace pentru a facilita procesul de gestionare a dezvoltării și lansării software-ului.
Pe măsură ce fiecare membru al echipei obține o înțelegere a modului în care funcționează sistemul în ansamblu, coordonarea fiecărei modificări cu toți ceilalți dezvoltatori devine din ce în ce mai dificilă. Încercarea de a rula stack-ul complet pe computerul local devine mai complicată cu fiecare zi.
În companiile mari, dezvoltatorii nu știu deloc cine lucrează la ce. Echipele comunică prin intermediul contractelor de servicii sau folosesc tehnologia Service mesh, care adaugă un nivel de abstracție deasupra rețelei, similar cu instrumentul de configurare Istio. Încercarea de a rula întregul stivă local este pur și simplu imposibilă. Recomand cu tărie utilizarea unei platforme de livrare continuă (CD) în Kubernetes, cum ar fi Spinnaker. Iată că vine momentul în care fiecare echipă are nevoie de propriul spațiu de nume. Fiecare echipă poate alege chiar și câteva spații de nume pentru mediu dev și mediu prod.
În cele din urmă, există mari companii antreprenoriale în care un grup de dezvoltatori nu știe nici măcar de existența altor grupuri. O astfel de companie poate angaja chiar dezvoltatori externi care interacționează prin intermediul unor API-uri bine documentate. În fiecare astfel de grup există câteva echipe și câteva microservicii. În acest caz, este necesar să se folosească toate instrumentele despre care am vorbit mai devreme.
Programatorii nu ar trebui să desfășoare servicii manual și nu ar trebui să aibă acces la spațiile de nume care nu îi privesc. În această etapă, este prudent să se aibă mai multe clustere pentru a reduce „raza de explozie” a aplicațiilor prost configurate, pentru a simplifica procesele de facturare și gestionare a resurselor.
Astfel, utilizarea corectă a spațiilor de nume de către organizația dumneavoastră face Kubernetes mai gestionabil, controlabil, sigur și flexibil.
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
