Ahogy egyre több Kubernetes szolgáltatást kezdesz el létrehozni, a kezdetben egyszerű feladatok bonyolultabbá válnak. Például a fejlesztői csapatok nem tudják ugyanazzal a névvel létrehozni a szolgáltatásokat vagy a telepítéseket. Ha ezer podod van, az egyszerű felsorolás rengeteg időt vesz igénybe, nem is beszélve arról, hogy megfelelően kezeld őket. És ez csak a jéghegy csúcsa.
Nézzük meg, hogyan könnyíti meg a névsorral való kezelés a Kubernetes erőforrásait. Tehát mi az a névsor? A névsor virtuális klaszterként tekinthető a Kubernetes klaszteredben. Több elkülönített, egymástól független névsor is létezhet egy Kubernetes klaszteren belül. Valóban segíthetnek neked és csapatodnak a szervezésben, biztonságban és akár a rendszer teljesítményében is.
A Kubernetes legtöbb disztribúciója alapértelmezés szerint egy "default" névsorral érkezik. Valójában három névsor létezik, amellyel a Kubernetes foglalkozik: default, kube-system és kube-public. Jelenleg a kube-public nem annyira gyakran használt.
A kube névsor megérintése jó ötlet, különösen egy olyan menedzselt rendszerben, mint a Google Kubernetes Engine. Ez a "default" névsor használatára van beállítva, ahol a szolgáltatásaidat és alkalmazásaidat létrehozzák. Nincs benne semmi különös, kivéve, hogy a Kubernetes alapértelmezés szerint az ő használatára van beállítva, és nem tudod törölni. Ez nagyszerű a kezdéshez és alacsony teljesítményű rendszerekhez, de nem javaslom a default névsor használatát nagyobb prod rendszerekben. Utóbbi esetben egy fejlesztőcsapat könnyedén felülírhatja mások kódját, és ezzel megzavarhatja egy másik csapat munkáját anélkül, hogy ezt tudnák.
Ezért érdemes több névsor létrehozása és azok használata a szolgáltatásaid szegmentálására. A névsor egy parancs segítségével létrehozható. Ha egy "test" nevű névsorot szeretnél létrehozni, akkor használd a $ kubectl create namespace test parancsot, vagy egyszerűen hozz létre egy YAML fájlt, és használd úgy, mint bármely más Kubernetes erőforrást.
A névtér megtekintéséhez használja a $ kubectl get namespace parancsot.
A parancs végrehajtása után három beépített névteret és egy új "test" nevű névteret fog látni. Nézzünk meg egy egyszerű YAML-fájlt, amelyet a pod létrehozására szántak. Érdemes észrevenni, hogy nem tartalmaznak említést a névről.
Ha a kubectl-t használja ennek a fájlnak a futtatására, akkor létrehoz egy mypod modult az aktuális aktív névtérben. Ez az alapértelmezett névtér lesz, amíg meg nem változtatja. Két módja van annak, hogy megmondja a Kubernetesnek, melyik névtérben szeretné létrehozni az erőforrást. Az első mód a névtér zászlójának használata az erőforrás létrehozásakor.
A második mód az, hogy a névtér megadásával a YAML-deklarációban történik.
Ha megadja a névteret a YAML-ben, az erőforrás mindig ebben a névtérben jön létre. Ha más névteret próbál meg használni a névtér zászlójával, a parancs hibaüzenettel fog végződni. Most, ha megpróbálja megkeresni a pod-ját, nem fogja tudni.
Ez azért van, mert minden parancs a jelenlegi aktív névterven kívül hajtódik végre. Ahhoz, hogy megtalálja a podját, használnia kell a névtér zászlaját, de ez hamar unalmassá válik, különösen, ha egy fejlesztőként dolgozik egy olyan csoportban, amely saját névteret használ, és nem szeretné ezt a zászlót minden egyes parancsnál használni. Nézzük meg, hogyan lehet ezt megoldani.
Alapértelmezés szerint az aktív névtér neve default. Ha nem határozza meg a névteret a YAML erőforrásban, akkor minden Kubernetes parancs ezt az aktív default névteret fogja használni. Sajnos a kubectl-lel való aktív névtér kezelése gyakran meghiúsulhat. Van azonban egy nagyon jó eszköz, a Kubens, amely sokkal egyszerűbbé teszi ezt a folyamatot. Amikor kiadja a kubens parancsot, látni fogja az összes névteret, megjelölve az aktív névteret.
Az aktív névtér teszt névtérre való váltásához egyszerűen futtassa a $ kubens test parancsot. Ha ezután újra beírja a $ kubens parancsot, láthatja, hogy most már egy új aktív névtér, a test van kiemelve.
Ez azt jelenti, hogy nincs szüksége névtér zászlóra, hogy láthassa a pod-ot a test névtérben.
Így a neveket elválasztják egymástól, de nem izolálják. Az egyik névtér szolgáltatása könnyen kommunikálhat egy másik névtér szolgáltatásával, ami gyakran nagyon hasznos. A különböző névterek közötti kommunikáció lehetősége azt jelenti, hogy a fejlesztői szolgáltatás kapcsolatba léphet egy másik fejlesztőcsapat szolgáltatásával egy másik névtérben.
Általában, amikor az alkalmazása hozzá akar férni a Kubernetes szolgáltatáshoz, a beépített DNS felfedező szolgáltatást használja, és egyszerűen megadja az alkalmazásának a szolgáltatás nevét. De ezzel lehetőséget ad arra, hogy több névtérben is létrehozhasson szolgáltatást ugyanazzal a névvel, ami nem elfogadható.
Szerencsére ezt könnyen megkerülheti a DNS-cím kibővített formájának használatával. A Kubernetes szolgáltatások a végpontjaikat egy közös DNS-minta alapján állítják ki. Ez körülbelül így néz ki:
Általában csak a szolgáltatás neve szükséges, és a DNS automatikusan meghatározza a teljes címet.
Ha azonban egy másik névtérben lévő szolgáltatáshoz szeretne hozzáférni, egyszerűen használja a szolgáltatás nevét plusz a névtér nevét:
Például, ha csatlakozni szeretne a teszt névtérbeli adatbázis szolgáltatáshoz, használhatja a database.test címet.
Ha viszont a prod névtérben lévő adatbázis szolgáltatáshoz szeretne csatlakozni, akkor a database.prod címet használja.
Ha valóban izolálni és korlátozni kívánja a névtérhez való hozzáférést, a Kubernetes lehetővé teszi ezt a Kubernetes Hálózati Politika segítségével. Erről a következő részben mesélek.
Gyakran felteszik nekem a kérdést, hogy hány névteret kell létrehozni és milyen célokra? Mi is az a kezelhető adatfragmentum?
Ha túl sok névteret hozol létre, az csak útban lesz neked. Ha viszont túl kevés lesz, elveszíted mindazokat az előnyöket, amelyeket ez a megoldás kínál. Úgy gondolom, hogy négy fő szakasz létezik, amelyeken minden cég keresztülmegy, amikor megalkotja a szervezeti felépítését. A projekted vagy céged fejlődési szakaszától függően alkalmazhatsz megfelelő névtér-képzési stratégiát.
Képzeld el, hogy egy kis csapat része vagy, amely 5-10 mikroszolgáltatáson dolgozik, és könnyedén összegyűjtheted az összes fejlesztőt egy szobában. Ebben a helyzetben értelme van annak, hogy az összes prod-szolgáltatást a default névtérben futtassuk. Természetesen, ha nagyobb mozgástérre van szükséged, használhatsz 2 névteret – külön a prod és dev számára. Valószínűleg a fejlesztésedet a helyi számítógépeden teszteled valamilyen Minikube-szerű eszköz segítségével.
Tegyük fel, hogy a körülmények megváltoztak, és most egy gyorsan növekvő csapatod van, amely egyszerre több mint 10 mikroszolgáltatáson dolgozik. Elérkezik az a pillanat, amikor több klasztert vagy névteret kell használnod, külön a prod és dev számára. A csapatot több alcsoportba lehet osztani, így mindegyiknek saját mikroszolgáltatásai lesznek, és minden egyes csapat kiválaszthatja a saját névterét, hogy megkönnyítse a fejlesztési és szoftverkiadási folyamatok kezelését.
Ahogy a csapat minden tagja egyre jobban megismeri a rendszer működését, egyre nehezebb és nehezebb koordinálni minden változást a többi fejlesztővel. A teljes technológiai stack helyi gépen való futtatásának próbálkozása napról napra egyre bonyolultabbá válik.
Nagyvállalatoknál a fejlesztők általában nem tudják, ki dolgozik pontosan min. A csapatok szolgáltatási szerződésekkel kommunikálnak, vagy Service mesh technológiát használnak, amely egy absztrakciós szintet ad a hálózat fölé, mint az Istio konfigurációs eszköz. Az egész stack helyi futtatásának megkísérlése egyszerűen lehetetlen. Határozottan javaslom, hogy a Kubernetesben használjon olyan folyamatos szállítási (CD) platformot, mint a Spinnaker. Itt az a pillanat következik, amikor minden csapatnak határozottan szüksége van saját névtérre. Minden csapat akár több névteret is választhat a dev és a prod környezethez.
Végül vannak nagyvállalati cégek, ahol az egyik fejlesztőcsapat még csak nem is tud a másik csoport létezéséről. Az ilyen cégek akár külső fejlesztőket is felvehetnek, akik jól dokumentált API-kon keresztül lépnek kapcsolatba. Minden ilyen csapatban több csapat és több mikroszolgáltatás található. Ilyen esetben mindezek az eszközök szükségesek, amelyeket korábban említettem.
A programozóknak nem szabad kézzel telepíteniük a szolgáltatásokat, és nem szabad hozzáférésük legyen az őket nem érintő névterekhez. Ezen a ponton érdemes több klasztert fenntartani a nem megfelelően beállított alkalmazások "robbanási sugarának" csökkentése végett, valamint a számlázási folyamatok és az erőforrás-kezelés egyszerűsítése érdekében.
Így a szervezete által helyesen használt névterek a Kubernetes-t kezelhetőbbé, ellenőrizhetőbbé, biztonságosabbá és rugalmasabbá teszik.
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
