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