Kuna alustate järjest rohkem Kubernetes teenuste loomist, muutuvad alguses lihtsad ülesanded keeruliseks. Näiteks ei saa arendustiimid luua teenuseid või juurutusi sama nimega. Kui teil on tuhandeid pode, kulub nende lihtsalt loetlemiseks palju aega, rääkimata korraliku haldamise tagamisest. Ja see on alles jäämäe tipp.
Vaatame, kuidas namespace aitab Kubernetes ressursside haldamist lihtsustada. Mis on üldse namespace? Namespace'i võib pidada nagu virtuaalset klastrit teie Kubernetes klastris. Ühes Kubernetes klastris võib olla mitu omavahel isoleeritud namespace'i. Need võivad tõeliselt aidata teid ja teie meeskondi organisatsiooni, turvalisuse ja isegi süsteemi jõudluse osas.
Enamikus Kubernetesi distributsioonides on klaster "karbist välja" nimespetsiifilise nimega "default". Tegelikult on kolm namespace'i, millega Kubernetes tegeleb: default, kube-system ja kube-public. Praegu ei kasutata kube-public'i väga sageli.
Kube namespace'i muutmine ei ole hea idee, eriti niivõrd hallatavas süsteemis nagu Google Kubernetes Engine. See kasutab "default" namespace'i, et luua teie teenuseid ja rakendusi. Seal ei ole absoluutselt midagi erilist, välja arvatud see, et Kubernetes on „karbist välja“ selle kasutamiseks seadistatud ja te ei saa seda kustutada. See sobib hästi alustamiseks ja madala jõudlusega süsteemide jaoks, kuid ma ei soovitaks kasutada default namespace'i suuremates tootmisüsteemides. Viimases juhtumis võib üks arendustiim kergesti kirjutada ümber teise koodi ja häirida teise tiimi tööd, isegi aru saamata.
Seetõttu peaksite looma mitu namespace'i ja kasutama neid oma teenuste segmenteerimiseks hallatavatesse komponentidesse. Namespace'i saab luua ühe käsuga. Kui soovite luua namespace'i nimega test, kasutatakse käsku $ kubectl create namespace test või lihtsalt looge YAML-fail ja kasutage seda nagu mistahes muud Kubernetes ressurssi.
Kõiki namespace'e saab vaadata käsuga $ kubectl get namespace.
Käsku täitmisel näete kolme sisseehitatud namespace'i ja uut namespace'i nimega "test". Vaatame lihtsat YAML-faili, mis on mõeldud pod'i loomiseks. Võib märgata, et seal ei mainita mingit namespace'i.
Kui rakendate kubectl selle faili käitamiseks, loob see mooduli mypod hetkel aktiivses namespace'is. See on default namespace, kuni te seda ei muuda. On kaks viisi, kuidas öelda Kubernetesile, millises namespace'is soovite oma ressurssi luua. Esimene viis on kasutada namespace'i lippu ressurssi luues.
Teine viis on määrata namespace YAML deklaratsioonis.
Kui määrate namespace'i YAML-is, luuakse ressurss alati selles namespace'is. Kui proovite kasutada teist namespace'i namespace'i lipu kasutamisel, lõppeb käsk veaga. Nüüd, kui proovite oma pod'i leida, ei suuda te seda teha.
See juhtub, kuna kõik käsud täidetakse hetkel aktiivse namespace'i väljaspool. Oma pod'i leidmiseks peate kasutama namespace'i lippu, kuid see tüütab kiiresti ära, eriti kui olete arendaja rühmas, mis kasutab oma namespace'i ja ei soovi seda lippu iga käsu puhul kasutada. Vaatame, kuidas seda parandada.
Karbist välja on teie aktiivne namespace nimega default. Kui te ei täpsusta resource YAML-is namespace'i, siis kõik Kubernetes'i käsud kasutavad seda aktiivset default namespace'i. Kahjuks võib aktiivse namespace'i haldamine kubectliga ebaõnnestuda. Siiski on olemas väga hea tööriist nimega Kubens, mis lihtsustab seda protsessi oluliselt. Kui käitate käsku kubens, näete kõiki namespace'e, kus aktiivne namespace on esile tõstetud.
Aktiivse namespace'i muutmiseks namespace'iks test peate lihtsalt käivitama käsu $ kubens test. Kui seejärel uuesti sisestate käsu $ kubens, on näha, et nüüd on uus aktiivne namespace – test.
See tähendab, et te ei vaja namespace'i lippu, et näha pod'i namespace'is test.
Nii et nimespetsiifid on üksteisest varjatud, kuid mitte isoleeritud. Üks nimespetsiifiline teenus võib suhtlemiseks olla üsna hõlpsasti ühendatud teise nimespetsiifilise teenusega, mis on sageli väga kasulik. Erinevate nimespetsiifiliste teenuste vahelise suhtlemise võimalus tähendab, et teie arendajate teenus võib suhelda teise arendustiimi teenusega teises nimespetsiifilises keskkonnas.
Tavaliselt, kui teie rakendus soovib juurdepääsu Kubernetes teenusele, kasutate sisseehitatud DNS-teenuse avastamist ja lihtsalt ütlete oma rakendusele teenuse nime. Kuid samas võite luua mitmes nimespetsiifilises ruumis sama nimega teenuse, mis on vastuvõetamatu.
Õnneks on seda lihtne ümber käia, kasutades täielikku DNS-aadressi. Kuberneteses eksponeerivad teenused oma lõpp-punkte, kasutades üldist DNS-malli. See näeb välja umbes selline:
Reeglina vajate lihtsalt teenuse nime, ning DNS määrab automaatselt täpselt aadressi.
Kuid kui peate juurdepääsu saama teise nimespetsiifilise teenuse, kasutage lihtsalt teenuse nime koos nimespetsiifilise nimega:
Näiteks kui soovite ühenduda teenuse andmebaasiga test nimespetsiifilises ruumis, võite kasutada aadressi database.test.
Kui soovite aga ühenduda teenuse andmebaasiga prod nimespetsiifilises ruumis, kasutate database.prod.
Kui soovite tõeliselt isoleerida ja piirata juurdepääsu nimespetsiifilisele ruumile, võimaldab Kubernetes seda teha Kubernetes Network Policies’i kaudu. Selle kohta räägin järgmisel korral.
Küsin sageli, kui palju nimespetsiifilisi ruume peaks looma ja milliste eesmärkide jaoks? Mis on hallatav andmefragment?
Kui loote liiga palju nimespetsiifilisi ruume, takistavad need teid lihtsalt. Kui neid on aga liiga vähe, kaotate kõik sellise lahenduse eelised. Minu arvates on neli peamist etappi, mille iga ettevõte läbib oma organisatsiooni struktuuri loomisel. Sõltuvalt sellest, millises arenguastmes teie projekt või ettevõte on, võite rakendada vastavat nimespetsiifilise ruumi loomise strateegiat.
Kujutage ette, et olete väikese meeskonna osa, kes töötab 5-10 mikroteenuse arendamise kallal, ja te saate kõik arendajad erinevatesse ruumidesse hõlpsasti kokku tuua. Sellises olukorras on mõistlik käivitada kõik prod-teenused nimespetsiifilises ruumis default. Muidugi, et tagada rohkem ruumi, võite kasutada kahte nimespetsiifilist ruumi — eraldi prod ja dev jaoks. Ja tõenäoliselt testite oma arendust oma kohaliku arvuti abil, kasutades midagi sarnast Minikube’ ga.
Oletame, et olukord on muutunud ja nüüd on teil kiiresti kasvav meeskond, kes töötab samaaegselt rohkem kui 10 mikroteenuse kallal. Jõuab hetk, mil on vaja kasutada mitmeid klistre või nimespetsiifilisi ruume, eraldi prod ja dev jaoks. Võite jagada meeskonna mitmeks alamgrupiks, nii et igaühel neist on oma mikroteenused ja iga üks neist saab valida oma nimespetsiifilise ruumi, et hõlbustada arenduse ja tarkvara väljaandmise haldamist.
Kuna iga meeskonna liige saab järjest paremini aru, kuidas süsteem tervikuna töötab, muutub iga muudatuse koordineerimine kõigi teiste arendajatega järjest raskemaks. Proovida kogu tehnoloogia stacki oma kohaliku arvuti peal käitada on iga päev üha keerulisem.
Suurtes ettevõtetes ei tea arendajad üldse, kes täpselt millega töötab. Meeskonnad suhtlevad teenuse lepingute kaudu või kasutavad tehnoloogiat Service mesh, mis lisab võrgu kohal abstraktsiooni taseme, nagu konfigureerimistööriist Istio. Proovimine oma sisest hangete serveriv varud on lihtsalt võimatu. Soovitan soojalt kasutada Kuberneteses pideva kohaletoimetamise (CD) platvormi nagu Spinnaker. Nii et jõuab hetk, mil igal meeskonnal on kindlasti vaja oma nimespetsiifilist ruumi. Iga meeskond võib isegi valida mitmeid nimespetsiifilisi ruume keskkondade dev ja prod jaoks.
Lõpuks on olemas suured ettevõtted, kus üks arendajate rühm ei tea isegi teiste rühmade olemasolust. Tõenäoliselt võib selline ettevõte palgata ka välist arendajat, kes suhtleb hästi dokumenteeritud API-de kaudu. Igas sellises rühmas on mitu tiimi ja mitu mikroteenust. Sellisel juhul tuleb kasutada kõiki varem mainitud tööriistu.
Programmeerijatel ei tohi olla õigust teenuseid käsitsi juurutada ega pääseda nimesse, mis neid ei puuduta. Sel etapil on mõistlik omada mitmeid klastreid, et vähendada halvasti seadistatud rakenduste 'plahvatusraadiust', lihtsustada arveldamise ja ressursside halduse protsesse.
Seega võimaldab teie organisatsiooni õige nimestruktuuri kasutamine muuta Kubernetes'i paremini hallatavaks, kontrollitavaks, turvaliseks ja paindlikuks.
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. , ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).
Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas
Allikas: habr.com
