С нарастанием количества сервисов в Kubernetes, задачи, которые изначально кажутся простыми, начинают усложняться. Например, команды разработчиков сталкиваются с проблемой, когда не могут создавать службы или развертывания с одинаковыми именами. Если у вас есть тысячи подов, то простое их перечисление займёт много времени, не говоря уже о нормальном управлении. И это только верхушка айсберга.
Давайте рассмотрим, как пространства имен (namespace) упрощают управление ресурсами в Kubernetes. Итак, что такое пространство имен? Можно рассматривать namespace как виртуальный кластер внутри вашего кластера Kubernetes. Вы можете иметь несколько изолированных пространств имен в одном кластере Kubernetes. Они действительно могут помочь вам и вашим командам с организацией, безопасностью и даже производительностью системы.
В большинстве дистрибутивов Kubernetes кластер «приходит» с предустановленным пространством имен, называемым «default». На самом деле существует три пространства имен, с которыми взаимодействует Kubernetes: default, kube-system и kube-public. В настоящее время kube-public используется достаточно редко.
Не рекомендуется изменять пространство имен kube, особенно в такой управляемой системе, как Google Kubernetes Engine. Она использует пространство имен «default» как место для создания ваших сервисов и приложений. В нем нет ничего особенного, кроме того, что Kubernetes по умолчанию настроен на его использование, и вы не можете его удалить. Это отличный старт для простых систем с низкой нагрузкой, но я бы не рекомендовал использовать пространство имен default в крупных продакшн-системах. В последнем случае одна команда разработчиков может легко изменить код другого, не осознавая этого.
Поэтому стоит создать несколько пространств имен и использовать их для сегментации ваших услуг в управляемые звенья. Пространство имен можно создать с помощью одной команды. Если вы хотите создать пространство имен с именем 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.
По този начин пространствата за имената са скрити един от друг, но не са изолирани. Сервиз от едно пространство за имената може доста лесно да комуникира със сервиз в друго пространство за имената, което често е много полезно. Възможността за комуникация между различни пространства за имената означава, че сервизът на вашите разработчици може да взаимодейства със сервиз на друга dev-отбор в друго пространство за имената.
Обикновено, когато вашето приложение иска достъп до сервиз на Kubernetes, вие използвате вградената система за откриване на DNS и просто указвате на вашето приложение името на сервиза. Въпреки това, можете да създадете сервиз с едно и също име в няколко пространства за имената, което е недопустимо.
За щастие, това е лесно да се заобиколи, като се използва разширената форма на DNS адреса. Сервизите в Kubernetes предлагат своите крайни точки, използвайки общ шаблон за DNS. Това изглежда приблизително така:
Обикновено, просто ви е необходимо името на сервиза и DNS автоматично ще определи пълния адрес.
Но ако трябва да получите достъп до сервиз в друго пространство за имената, просто използвайте името на сервиза плюс името на пространството за имената:
Например, ако искате да се свържете с базата данни на сервиза в тестовото пространство за имената, можете да използвате адреса database.test
Ако искате да се свържете с базата данни на сервиза в пространството за имената prod, използвайте database.prod.
Ако наистина искате да изолирате и ограничите достъпа до пространството за имената, Kubernetes позволява да направите това с помощта на мрежови политики на Kubernetes Network Policies. За това ще говоря в следващата серия.
Често ми задават въпрос, колко пространства за имената трябва да се създадат и за какви цели? Какво представлява управляваната фрагментна информация?
Ако създадете твърде много пространства имена, те просто ще ви пречат. Ако пък съществуват твърде малко, ще загубите всички предимства на това решение. Смятам, че има четири основни етапа, през които преминава всяка компания в процеса на създаване на своята организационна структура. В зависимост от етапа на развитие, на който се намира вашият проект или компания, можете да възприемете съответната стратегия за изграждане на пространство имена.
Представете си, че сте част от малък екип, който работи по разработката на 5-10 микросервиза и можете лесно да съберете всичките разработчици в една стая. В тази ситуация има смисъл да стартирате всички прод-сервизи в пространството имена default. Разбира се, за по-голяма свобода на действие можете да използвате две пространства имена — отделно за прод и dev. И вероятно тествате своята разработка на локалния компютър с нещо подобно на Minikube.
Да предположим, че условията са се променили и сега имате бързо растящ екип, който едновременно работи над повече от 10 микросервиза. Настъпва момент, в който е необходимо да използвате няколко клъстера или пространства имена, отделно за прод и dev. Можете да разделите екипа на няколко подгрупи, така че всяка от тях да има свои собствени микросервизи и всяка от тези команди да може да избере свое собствено пространство имена, за да улесни процеса на управление на разработката и издаването на софтуер.
С напредването на времето, когато всеки член на екипа получава представа за начина, по който работи системата като цяло, координирането на всяка промяна с всички останали разработчици става все по-трудно. Опитът да стартирате цялостния стек на вашия локален компютър става все по-сложен с всеки изминал ден.
В големи компании разработчиците изобщо не знаят кой конкретно работи по какво. Екипите комуникират чрез сервисни договори или използват технологията Service mesh, която добавя абстракционен слой над мрежата, подобен на конфигурационния инструмент Istio. Опитът да стартирате целия стек локално е просто невъзможен. Настоятелно препоръчвам да се използва платформа за непрекъсната доставка (CD) като Spinnaker в Kubernetes. И така, настъпва момент, когато всеки екип определено се нуждае от собствено пространство за имена. Всеки екип може дори да избере няколко пространства за имена за средата 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
