Kubernetes'i parimad tavad. Kubernetes'i korraldamine nimede ruumi abil

Parimad Kubernetes'i praktikad. Väikeste konteinerite loomine

Kuna te loote üha rohkem Kubernetes teenuseid, muutuvad esialgu lihtsad ülesanded keeruliseks. Näiteks ei saa arendustiimid luua teenuseid või juurutusi sama nimega. Kui teil on tuhandeid pods, nende lihtne loetlemine võtab rohkelt aega, rääkimata korraliku haldamise tagamisest. Ja see on alles jäämäe tipp.

Vaadakem, kuidas nimede ruum namespace lihtsustab Kubernetes ressursside haldamist. Mis on nimede ruum? Namespace'i võib pidada virtuaalseks klastriks teie Kubernetes klasstris. Samas Kubernetes klasstris võib olla mitu omavahel eraldatud nimede ruumi. Need võivad tõeliselt aidata teil ja teie meeskondadel organisatsiooni, turvalisuse ja isegi süsteemi jõudluse osas.

Enamikus Kubernetes jaotustest tuleb klaster „kastist” koos nimede ruumiga nimega „default”. Tegelikult on kolm nimede ruumi, millega Kubernetes tegeleb: default, kube-system ja kube-public. Praegu ei kasutata Kube-public'i eriti tihti.

Kube nimede ruumi mitte puudutamine on hea mõte, eriti sellises hallatav süsteemis nagu Google Kubernetes Engine. See kasutab nimede ruumi „default” teie teenuste ja rakenduste loomiseks. Seal ei ole absoluutselt midagi erilist, välja arvatud see, et Kubernetes on selle kasutamiseks „kastist” juba seadistatud, ja te ei saa seda kustutada. See on suurepärane alustada ja väikese jõudlusega süsteemide jaoks, kuid ma ei soovitaks kasutada default nimede ruumi suurtes tootmisse süsteemides. Viimases juhul võib üks arendustiim kergesti kirjutada teiste koodi üle ja häirida teise meeskonna tööd, isegi seda märkamatagi.

Seetõttu tuleks luua mitu nimede ruumi ja kasutada neid teie teenuste segmenteerimiseks hallatavatesse üksustesse. Nimede ruumi saab luua ühe käsu abil. Kui soovite luua nimede ruumi nimega test, kasutage käsku $ kubectl create namespace test või looge lihtsalt YAML-fail ja kasutage seda nagu iga muud Kubernetes ressurssi.

Kõiki nimede ruume saab vaadata käsu $ kubectl get namespace abil.

Pärast selle täitmist näete kolme sissehitatud nimespируемi ja uut nimespiraali nimega „test“. Vaatame lihtsat YAML-faili, mis on mõeldud podi loomiseks. Võib märkida, et selles ei ole mingit viidet nimespiraalile.

Kui kasutate kubectl selle faili käivitamiseks, loob see mooduli mypod praeguses aktiivses nimespiraalis. See on vaikimisi nimespiraal, kuni te ei muuda. On 2 viisi, kuidas rääkida Kubernetesile, millises nimespiraalis soovite oma ressursse luua. Esimene viis on kasutada nimespiraali lippu ressursi loomisel.

Teine viis on nimespiraali määramine YAML-deklareerimises.

Kui määrate YAML-is nimespiraali, luuakse ressurss alati selles nimespiraalis. Kui proovite kasutada muud nimespiraali nimespiraali lipu abil, lõpetab käsk ebaõnnestumisega. Nüüd, kui proovite leida oma podi, ei saa te seda teha.

See juhtub, kuna kõik käsud käivitatakse praegusest aktiivsest nimespiraalist väljaspool. Oma podi leidmiseks peate kasutama nimespiraali lippu, kuid see muutub kiiresti tüütuks, eriti kui töötate arendajana rühmas, kes kasutab oma nimespiraali ja ei taha iga üksiku käsu jaoks sellist lippu kasutada. Vaatame, kuidas seda saaks parandada.

Vaikimisi on teie aktiivne nimespiraal nimega default. Kui te ei täpsusta nimespiraali YAML-ressursis, kasutavad kõik Kubernetes'i käsud seda aktiivset default nimespiraali. Kahjuks võib aktiivse nimespiraali juhtimine kubectl'iga lõppeda ebaõnnestumisega. Siiski on olemas suurepärane tööriist nimega Kubens, mis lihtsustab seda protsessi oluliselt. Kui käivitate käsu kubens, näete kõiki nimespiraale, kus aktiivne nimespiraal on esile tõstetud.

Aktiivse nimespiraali vahetamiseks nimespiraaliks test käivitate lihtsalt käsu $ kubens test. Kui seejärel uuesti sisse kirjutada käsk $ kubens, näete, et nüüd on esile tõstetud uus aktiivne nimespiraal – test.

See tähendab, et teil ei ole nime ruumi lippu, et näha pod'i test nime ruumis.

Seega on nime ruumid teineteisest varjatud, kuid mitte teineteisest isoleeritud. Üks nimedruumi teenus saab suhteliselt kergesti suhelda teise nimedruumi teenusega, mis on sageli väga kasulik. Erinevate nimedruumide vahelise suhtluse võimalus tähendab, et teie arendajate teenus võib suhelda teise arendusmeeskonna teenusega teises nime ruumis.

Tavaliselt, kui teie rakendus soovib accéder Kubernetes teenusele, kasutate sisseehitatud DNS teenuse avastamist ja lihtsalt annate oma rakendusele teenuse nime. Kuid sel juhul saate luua teenuse sama nimega mitmes nimedruumis, mis on vastuvõetamatu.

Õnneks on seda lihtne kõrvaldada, kasutades DNS-i aadressi lahtist vormi. Teenused Kubernetes'is esitavad oma lõpp-punktid, kasutades ühise DNS-i mall. See näeb välja umbes nii:

Reeglina vajate lihtsalt teenuse nime, ja DNS määrab automaatselt täisadresse.

Kuid kui peate pääsema teenusele teises nime ruumis, kasutage lihtsalt teenuse nime pluss nime ruum:

Näiteks, kui soovite ühendada katse nimedruumi andmebaasi teenusega, võite kasutada aadressi database.test

Kui soovite ühendada andmebaasi teenusega prod nimedruumis, kasutate database.prod.

Kui soovite tõeliselt isoleerida ja piirata juurdepääsu nimedruumile, võimaldab Kubernetes seda teha Kubernetes Network Policies võrgu poliitikate abil. Räägin sellest järgmises osas.

Küsin sageli, kui palju nimedruume tuleks luua ja millistel eesmärkidel? Mis on haldatud andmete fragment?

Kui loote liiga palju nimespacing'e, takistavad need teid. Kui nimespacing'e on aga liiga vähe, kaotate kõik sellise lahenduse eelised. Arvan, et iga ettevõtte organisatsioonilise struktuuri loomise protsessis on neli peamist etappi. Olenevalt teie projekti või ettevõtte arenguetapist, võite kaaluda vastavat nimespacing'i loomise strateegiat.

Kujutage ette, et olete osa väikesest meeskonnast, kes töötab 5-10 mikroteenuse arendamise kallal ja saate kõik arendajad kergesti ühte ruumi kokku tuua. Sellises olukorras on mõistlik käivitada kõik tootmisteenused nimespacing'is default. Loomulikult võite laiemate võimaluste jaoks kasutada kaht nimespacing'it – eraldi tootmiseks ja arenduseks. Tõenäoliselt testite oma arendust kohalikul arvutil mõne Minikube sarnase lahenduse abil.

Oletame, et olukord on muutunud ja teil on kiiresti kasvav meeskond, mis töötab samaaegselt rohkem kui 10 mikroteenuse kallal. Jõuab aeg, mil on vajalik kasutada mitmeid klastri või nimespacing'e, eraldi tootmiseks ja arenduseks. Meeskonna saab jagada mitmeks alagruppideks, nii et igal alagrupil on omad mikroteenused ning iga meeskond saab valida oma nimespacing'i, et lihtsustada arendamise ja tarkvara väljalaskmise protsessi.

Mida enam iga meeskonna liige mõistab, kuidas süsteem tervikuna töötab, seda keerulisemaks muutub iga muudatuse kooskõlastamine teiste arendajatega. Katse oma kohalikul arvutil täielikku steki käivitada muutub iga päevaga keerulisemaks.

Suurtel ettevõtetel ei tea arendajad sageli, kes täpselt millega tegeleb. Meeskonnad suhtlevad teenuslepingute kaudu või kasutavad teenusmesh-tehnoloogiat, mis lisab võrgu peale abstraktsioonitaseme, sarnastes seadistustööriistades nagu Istio. Kogu steki kohaliku käivitamise katsetamine on peaaegu võimatu. Soovitan tungivalt kasutada Kuberneteses sellist pideva kohaletoimetamise (CD) platvormi nagu Spinnaker. Seega tuleb hetk, mil igal meeskonnal on kindlasti vaja oma nimeala. Iga meeskond võib isegi valida mitu nimeala arenduse (dev) ja tootmise (prod) keskkonna jaoks.

Lõpuks on olemas suured ettevõtted, kus ühe arendajate rühma liikmed ei tea isegi teiste rühmade olemasolust. Selline ettevõte võib palkata ka välist arendajat, kes suhtleb hästi dokumenteeritud API-de kaudu. Igas sellises rühmas on mitu meeskonda ja mitu mikroteenust. Sellisel juhul on vajalik kasutada kõiki eelnevalt mainitud tööriistu.

Arendajad ei tohiks teenuseid käsitsi juurutada ega peab olema juurdepääs nendele nimealadele, mis neid ei puuduta. Sellel etapil on mõistlik omada mitu klastrit, et vähendada halvasti seadistatud rakenduste "plahvatusraadiust", lihtsustada arveldamise ja ressursihalduse protsesse.

Seega võimaldab teie organisatsiooni õige nimealade kasutamine Kubernetes olla rohkem juhitav, kontrollitav, turvaline ja paindlik.

Kubernetes'i parimad praktikad. Kubernetes'i elujõu kontrollimine Readiness ja Liveness testide abil

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com