Kui hakkate looma üha uusi Kubernetese teenuseid, hakkavad algselt lihtsad ülesanded muutuma keerukamaks. Näiteks ei saa arendusmeeskonnad luua teenuseid ega juurutusi sama nime all. Kui teil on tuhandeid kaunasid, võtab nende lihtsalt loetlemine palju aega, rääkimata nende õigest haldamisest. Ja see on vaid jäämäe tipp.
Vaatame, kuidas nimeruum muudab Kubernetese ressursside haldamise lihtsamaks. Mis on siis nimeruum? Nimeruumi võib pidada teie Kubernetese klastri virtuaalseks klastriks. Ühes Kubernetese klastris võib olla mitu üksteisest eraldatud nimeruumi. Need võivad teid ja teie meeskondi tõesti aidata organisatsiooni, turvalisuse ja isegi süsteemi jõudlusega.
Enamiku Kubernetese distributsioonide puhul tuleb klaster välja koos nimeruumiga, mida nimetatakse vaikimisi. Kubernetes tegeleb tegelikult kolme nimeruumiga: vaikimisi, kube-süsteem ja kube-avalik. Praegu ei kasutata Kube-publicit kuigi sageli.
Kube nimeruumi üksi jätmine on hea mõte, eriti sellises hallatavas süsteemis nagu Google Kubernetes Engine. See kasutab teie teenuste ja rakenduste loomise kohana vaikenimeruumi. Selles pole absoluutselt midagi erilist, välja arvatud see, et Kubernetes on karbist välja konfigureeritud seda kasutama ja te ei saa seda eemaldada. See on suurepärane alustamiseks ja madala jõudlusega süsteemide jaoks, kuid ma ei soovitaks kasutada vaikenimeruumi suurtes tootmissüsteemides. Viimasel juhul võib üks arendusmeeskond hõlpsasti kellegi teise koodi ümber kirjutada ja teise meeskonna tööd rikkuda, ilma et sellest ise arugi saaks.
Seetõttu peaksite looma mitu nimeruumi ja kasutama neid oma teenuste hallatavateks üksusteks segmenteerimiseks. Nimeruumi saab luua ühe käsuga. Kui soovite luua nimeruumi nimega test, kasutage käsku $ kubectl create namespace test või looge lihtsalt YAML-fail ja kasutage seda nagu mis tahes muud Kubernetese ressurssi.
Saate vaadata kõiki nimeruume, kasutades käsku $ kubectl get nimeruumi.
Kui see on tehtud, näete kolme sisseehitatud nimeruumi ja uut nimeruumi nimega "test". Vaatame podi loomiseks lihtsat YAML-faili. Märkate, et nimeruumi pole mainitud.
Kui kasutate selle faili käivitamiseks kubectli, loob see hetkel aktiivses nimeruumis mypodi mooduli. See on vaikenimeruum, kuni te seda muudate. Kubernetesile saab öelda kahel viisil, millisesse nimeruumi soovite oma ressursi luua. Esimene võimalus on kasutada ressursi loomisel nimeruumi lippu.
Teine võimalus on määrata nimeruum YAML-i deklaratsioonis.
Kui määrate YAML-is nimeruumi, luuakse ressurss alati selles nimeruumis. Kui proovite nimeruumi lipu kasutamise ajal kasutada teist nimeruumi, siis käsk nurjub. Kui proovite nüüd oma kausta leida, ei saa te seda teha.
See juhtub seetõttu, et kõik käsud täidetakse väljaspool hetkel aktiivset nimeruumi. Podi leidmiseks peate kasutama nimeruumi lippu, kuid see muutub kiiresti igavaks, eriti kui olete arendaja meeskonnas, mis kasutab oma nimeruumi ega soovi seda lippu kasutada iga üksiku käsu jaoks. Vaatame, kuidas seda parandada.
Väljaspool kasti nimetatakse teie aktiivset nimeruumi vaikimisi. Kui te ressursis YAML nimeruumi ei määra, kasutavad kõik Kubernetese käsud seda aktiivset vaikenimeruumi. Kahjuks võib aktiivse nimeruumi haldamine kubectli abil ebaõnnestuda. Siiski on väga hea tööriist nimega Kubens, mis muudab selle protsessi palju lihtsamaks. Kui käivitate käsu kubens, näete kõiki nimeruume, mille aktiivne nimeruum on esile tõstetud.
Aktiivse nimeruumi lülitamiseks testnimeruumile käivitage lihtsalt testkäsk $kubens. Kui käivitate seejärel käsu $kubens uuesti, näete, et nüüd on eraldatud uus aktiivne nimeruum – test.
See tähendab, et testnimeruumis podi nägemiseks pole vaja nimeruumi lippu.
Nii on nimeruumid üksteise eest peidetud, kuid mitte isoleeritud. Ühes nimeruumis olev teenus suudab üsna hõlpsalt suhelda teises nimeruumis oleva teenusega, mis on sageli väga kasulik. Võimalus suhelda erinevates nimeruumides tähendab, et teie arendajate teenus saab suhelda teise arendusmeeskonna teenusega teises nimeruumis.
Tavaliselt, kui teie rakendus soovib juurdepääsu Kubernetese teenusele, kasutate sisseehitatud DNS-tuvastusteenust ja annate rakendusele lihtsalt teenuse nime. Kuid seda tehes saate luua sama nime all teenuse mitmes nimeruumis, mis pole vastuvõetav.
Õnneks on sellest DNS-aadressi laiendatud vormi kasutades lihtne mööda minna. Kubernetese teenused paljastavad oma lõpp-punktid ühise DNS-malli abil. See näeb välja umbes selline:
Tavaliselt vajate lihtsalt teenuse nime ja DNS määrab automaatselt täieliku aadressi.
Kui teil on vaja juurdepääsu teenusele teises nimeruumis, kasutage lihtsalt teenuse nime ja nimeruumi nime:
Näiteks kui soovite luua ühenduse teenuse andmebaasiga testnimeruumis, saate kasutada aadresside andmebaasi andmebaas.test
Kui soovite luua ühenduse teenuseandmebaasiga tootenimeruumis, kasutage andmebaasi.prod.
Kui soovite tõesti isoleerida ja piirata juurdepääsu nimeruumile, võimaldab Kubernetes seda teha Kubernetese võrgupoliitika abil. Ma räägin sellest järgmises osas.
Minult küsitakse sageli, kui palju nimeruume peaksin looma ja mis eesmärgil? Mis on hallatav andmeosa?
Kui loote liiga palju nimeruume, jäävad need lihtsalt teie teele. Kui neid on liiga vähe, kaotate kõik sellise lahenduse eelised. Ma arvan, et iga ettevõte oma organisatsioonilise struktuuri loomisel läbib neli peamist etappi. Sõltuvalt teie projekti või ettevõtte arenguetapist võite soovida võtta kasutusele sobiva nimeruumi strateegia.
Kujutage ette, et olete osa väikesest meeskonnast, mis töötab 5–10 mikroteenuse väljatöötamisega ja saate hõlpsalt koondada kõik arendajad ühte ruumi. Sellises olukorras on mõttekas käivitada kõik tooteteenused vaikenimeruumis. Muidugi saate suurema paindlikkuse huvides kasutada kahte nimeruumi – eraldi toote ja arendaja jaoks. Tõenäoliselt testite oma arendust kohalikus arvutis, kasutades midagi nagu Minikube.
Oletame, et asjad muutuvad ja teil on nüüd kiiresti kasvav meeskond, kes töötab korraga rohkem kui 10 mikroteenuse kallal. Tuleb aeg, mil on vaja kasutada mitut klastrit või nimeruumi, eraldi prod ja dev jaoks. Saate meeskonna jagada mitmeks alammeeskonnaks, nii et igal neist on oma mikroteenused ja igaüks neist saab valida oma nimeruumi, et hõlbustada tarkvara arendamise ja väljalaske haldamist.
Kuna iga meeskonnaliige saab ülevaate süsteemi kui terviku toimimisest, muutub iga muudatuse kooskõlastamine kõigi teiste arendajatega üha keerulisemaks. Püüdes oma kohalikus masinas täispakki kerida, muutub iga päevaga raskemaks.
Suurtes ettevõtetes ei tea arendajad üldiselt, kes täpselt mille kallal töötab. Meeskonnad suhtlevad teenuslepingute kaudu või kasutavad teenindusvõrgu tehnoloogiat, mis lisab võrgule abstraktsioonikihi, näiteks Istio konfiguratsioonitööriista. Terve pinu kohapeal käitamine pole lihtsalt võimalik. Soovitan kasutada pideva kohaletoimetamise (CD) platvormi nagu Spinnaker Kubernetesis. Niisiis, saabub hetk, kus iga käsk vajab kindlasti oma nimeruumi. Iga meeskond saab valida arenduskeskkonna ja tootmiskeskkonna jaoks isegi mitu nimeruumi.
Lõpuks on ka suuri ettevõtlikke ettevõtteid, kus üks arendajate rühm ei tea isegi teiste kontsernide olemasolust. Selline ettevõte võib üldjuhul palgata kolmanda osapoole arendajaid, kes suhtlevad sellega hästi dokumenteeritud API-de kaudu. Iga selline rühm sisaldab mitut meeskonda ja mitut mikroteenust. Sel juhul peate kasutama kõiki tööriistu, millest ma varem rääkisin.
Programmeerijad ei tohiks teenuseid käsitsi juurutada ja neil ei tohiks olla juurdepääsu nimeruumidele, mis neid ei puuduta. Praeguses etapis on soovitav omada mitut klastrit, et vähendada halvasti konfigureeritud rakenduste raadiust, lihtsustada arveldusprotsesse ja ressursside haldamist.
Seega võimaldab teie organisatsiooni nimeruumide õige kasutamine muuta Kubernetese hallatavamaks, juhitavamaks, turvalisemaks ja paindlikumaks.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com