Когато започнете да създавате все повече и повече услуги на Kubernetes, задачите, които първоначално са прости, започват да стават по-сложни. Например екипите за разработка не могат да създават услуги или внедрявания под едно и също име. Ако имате хиляди подове, простото им изброяване ще отнеме много време, да не говорим за правилното им управление. И това е само върхът на айсберга.
Нека да разгледаме как пространството от имена улеснява управлението на ресурсите на Kubernetes. И така, какво е пространство от имена? Пространството от имена може да се разглежда като виртуален клъстер във вашия клъстер Kubernetes. Можете да имате множество пространства от имена, изолирани едно от друго в рамките на един Kubernetes клъстер. Те наистина могат да помогнат на вас и вашите екипи с организация, сигурност и дори производителност на системата.
При повечето дистрибуции на Kubernetes, клъстерът излиза от кутията с пространство от имена, наречено „по подразбиране“. Всъщност има три пространства от имена, с които Kubernetes работи: по подразбиране, kube-system и kube-public. В момента Kube-public не се използва много често.
Оставянето само на пространството от имена на kube е добра идея, особено в управлявана система като Google Kubernetes Engine. Той използва пространството от имена "по подразбиране" като място, където се създават вашите услуги и приложения. Няма абсолютно нищо особено в него, освен че Kubernetes е конфигуриран от кутията да го използва и не можете да го премахнете. Това е страхотно за стартиране и системи с ниска производителност, но не бих препоръчал използването на пространството от имена по подразбиране на големи производствени системи. В последния случай един екип за разработка може лесно да пренапише кода на някой друг и да наруши работата на друг екип, без дори да го осъзнава.
Следователно трябва да създадете множество пространства от имена и да ги използвате, за да сегментирате услугите си в управляеми единици. Пространство от имена може да бъде създадено с една команда. Ако искате да създадете пространство от имена с име test, използвайте командата $ kubectl create namespace test или просто създайте YAML файл и го използвайте като всеки друг ресурс на Kubernetes.
Можете да видите всички пространства от имена, като използвате командата $ kubectl get namespace.
След като приключите, ще видите три вградени пространства от имена и ново пространство от имена, наречено „test“. Нека да разгледаме прост YAML файл за създаване на pod. Ще забележите, че не се споменава пространство от имена.
Ако използвате kubectl, за да стартирате този файл, той ще създаде модула mypod в текущо активното пространство от имена. Това ще бъде пространството от имена по подразбиране, докато не го промените. Има 2 начина да кажете на Kubernetes в какво пространство от имена искате да създадете своя ресурс. Първият начин е да използвате флаг за пространство от имена, когато създавате ресурс.
Вторият начин е да посочите пространството от имена в YAML декларацията.
Ако посочите пространство от имена в YAML, ресурсът винаги ще се създава в това пространство от имена. Ако се опитате да използвате различно пространство от имена, докато използвате флага за пространство от имена, командата ще се провали. Сега, ако се опитате да намерите своята капсула, няма да можете да го направите.
Това се случва, защото всички команди се изпълняват извън текущо активното пространство от имена. За да намерите своя pod, трябва да използвате флаг за пространство от имена, но това бързо омръзва, особено ако сте разработчик в екип, който използва собствено пространство от имена и не иска да използва този флаг за всяка отделна команда. Нека да видим как можем да поправим това.
Извън кутията вашето активно пространство от имена се нарича подразбиране. Ако не посочите пространство от имена в ресурса YAML, тогава всички команди на Kubernetes ще използват това активно пространство от имена по подразбиране. За съжаление опитът за управление на активното пространство от имена с помощта на kubectl може да се провали. Въпреки това има много добър инструмент, наречен Kubens, който прави този процес много по-лесен. Когато изпълните командата kubens, виждате всички пространства от имена с подчертано активно пространство от имена.
За да превключите активното пространство на имената към тестовото пространство на имената, просто изпълнете командата $kubens test. Ако след това изпълните отново командата $kubens, ще видите, че вече е разпределено ново активно пространство от имена - тест.
Това означава, че не се нуждаете от флага за пространство от имена, за да видите pod в пространството от имена на теста.
По този начин пространствата от имена са скрити едно от друго, но не изолирани едно от друго. Услуга в едно пространство от имена може да комуникира доста лесно с услуга в друго пространство от имена, което често е много полезно. Възможността за комуникация в различни пространства от имена означава, че услугата на вашите разработчици може да комуникира с услугата на друг екип от разработчици в различно пространство от имена.
Обикновено, когато вашето приложение иска достъп до услуга на Kubernetes, вие използвате вградената услуга за откриване на DNS и просто давате на приложението името на услугата. По този начин обаче можете да създадете услуга под едно и също име в множество пространства от имена, което не е приемливо.
За щастие, това е лесно да се заобиколи с помощта на разширената форма на DNS адреса. Услугите в Kubernetes разкриват своите крайни точки с помощта на общ DNS шаблон. Изглежда нещо подобно:
Обикновено ви трябва само името на услугата и DNS автоматично ще определи пълния адрес.
Въпреки това, ако имате нужда от достъп до услуга в различно пространство от имена, просто използвайте името на услугата плюс името на пространството от имена:
Например, ако искате да се свържете към сервизна база данни в тестово пространство от имена, можете да използвате адресната база данни database.test
Ако искате да се свържете с базата данни на услугата в пространството от имена на prod, използвайте database.prod.
Ако наистина искате да изолирате и ограничите достъпа до пространството от имена, Kubernetes ви позволява да направите това с помощта на мрежовите правила на Kubernetes. Ще говоря за това в следващия епизод.
Често ми задават въпроса колко пространства от имена трябва да създам и за какви цели? Какво е управлявана част от данните?
Ако създадете твърде много пространства от имена, те просто ще ви пречат. Ако има твърде малко от тях, ще загубите всички предимства на такова решение. Мисля, че има четири основни етапа, през които преминава всяка компания, когато създава своята организационна структура. В зависимост от етапа на развитие, в който се намира вашият проект или компания, може да искате да приемете подходяща стратегия за пространство от имена.
Представете си, че сте част от малък екип, който работи върху разработването на 5-10 микроуслуги и можете лесно да съберете всички разработчици в една стая. В тази ситуация има смисъл да стартирате всички прод услуги в пространството на имената по подразбиране. Разбира се, за повече гъвкавост можете да използвате 2 пространства от имена - отделно за prod и dev. И най-вероятно тествате разработката си на вашия локален компютър, като използвате нещо като Minikube.
Да приемем, че нещата се променят и сега имате бързо разрастващ се екип, работещ върху повече от 10 микроуслуги наведнъж. Идва момент, когато е необходимо да се използват няколко клъстера или пространства от имена, отделно за prod и dev. Можете да разделите екипа на няколко подекипа, така че всеки от тях да има свои собствени микроуслуги и всеки от тези екипи да може да избере свое собствено пространство от имена, за да улесни процеса на управление на разработката и пускането на софтуер.
Тъй като всеки член на екипа придобива представа за това как работи системата като цяло, става все по-трудно да се координира всяка промяна с всички останали разработчици. Опитът да завъртите пълен стек на вашата локална машина става все по-труден всеки ден.
В големите компании разработчиците обикновено не знаят кой точно върху какво работи. Екипите комуникират чрез договори за услуги или използват мрежова технология за услуги, която добавя абстракционен слой в мрежата, като инструмента за конфигуриране Istio. Опитът да стартирате цял стек локално е просто невъзможен. Силно препоръчвам да използвате платформа за непрекъснато доставяне (CD), като Spinnaker на Kubernetes. И така, идва момент, в който всяка команда определено се нуждае от собствено пространство от имена. Всеки екип може дори да избере множество пространства от имена за средата за разработка и средата за производство.
И накрая, има големи предприемачески компании, в които една група разработчици дори не знае, че другите групи съществуват. Такава компания обикновено може да наеме разработчици на трети страни, които взаимодействат с нея чрез добре документирани API. Всяка такава група съдържа няколко екипа и няколко микроуслуги. В този случай трябва да използвате всички инструменти, за които говорих по-рано.
Програмистите не трябва ръчно да внедряват услуги и не трябва да имат достъп до пространства от имена, които не ги засягат. На този етап е препоръчително да имате няколко клъстера, за да намалите „радиуса на взрив“ на лошо конфигурирани приложения, да опростите процесите на таксуване и управление на ресурсите.
По този начин правилното използване на пространства от имена от вашата организация ви позволява да направите Kubernetes по-управляем, контролируем, сигурен и гъвкав.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com