namespace kubernetes что это
Знакомство с Kubernetes. Часть 10: Неймспейсы (namespaces)
Jul 2, 2018 07:02 · 515 words · 3 minute read kubernetes
Kubernetes поддерживает несколько виртуальных кластеров, работающих в одном и том же физическом кластере. Эти виртуальные кластеры называются пространствами имен или неймспейсами (namespaces). Давайте разберемся!
Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.
Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:
и выполним команду:
Для второго неймспейса создадим файл с тем же содержимым, но заменим слова “development” на “production” и применим его:
Убедимся, что неймспейсы успешно создались:
Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:
Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):
После выполнения этих двух команд к конфигурационном файле
/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:
Kubernetes блог
Пространства имен (namespaces) в Kubernetes
Kubernetes поддерживает несколько виртуальных кластеров, поддерживаемых одним физическим кластером. Эти виртуальные кластеры называются пространствами имен.
Когда использовать несколько пространств имен
Пространства имен предназначены для использования в средах с множеством пользователей, распределенных по нескольким командам или проектам. Для кластеров с несколькими десятками пользователей вам вообще не нужно создавать или думать о пространствах имен. Начните использовать пространства имен, когда вам понадобятся функции, которые они предоставляют.
Пространства имен обеспечивают область для имен. Имена ресурсов должны быть уникальными в пространстве имен, но не во всех пространствах имен. Пространства имен не могут быть вложены друг в друга, и каждый ресурс Kubernetes может находиться только в одном пространстве имен.
В будущих версиях Kubernetes объекты в одном и том же пространстве имен будут иметь одинаковые политики контроля доступа по умолчанию.
Нет необходимости использовать несколько пространств имен только для того, чтобы разделить немного разные ресурсы, такие как разные версии одного и того же программного обеспечения: используйте метки (labels), чтобы различать ресурсы в одном и том же пространстве имен.
Работа с пространствами имен
Просмотр пространств имен
Вы можете перечислить текущие пространства имен в кластере, используя:
Kubernetes стартует с трех начальных пространств имен:
Настройка пространства имен для запроса
Чтобы установить пространство имен для текущего запроса, используйте флаг —namespace.
Установка настроек пространства имен
Вы можете надолго сохранить пространство имен для всех последующих команд kubectl в этом контексте.
Пространства имен и DNS
Не все объекты находятся в пространстве имен
Большинство ресурсов Kubernetes (например, модули (pods), службы (services), контроллеры репликации (replication controllers) и другие) находятся в некоторых пространствах имен. Однако ресурсы пространства имен сами по себе не находятся в пространстве имен. А низкоуровневые ресурсы, такие как узлы (nodes) и persistentVolumes, не находятся ни в одном пространстве имен.
Чтобы увидеть, какие ресурсы Kubernetes есть и нет в пространстве имен:
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
По мере того как вы начинаете создавать все больше и больше сервисов Kubernetes, простые по началу задачи начинают усложняться. Например, команды разработчиков не могут создавать службы или развертывания под одним и тем же именем. Если у вас тысячи подов, их простое перечисление займет кучу времени, не говоря о том, чтобы обеспечить им нормальное управление. И это только верхушка айсберга.
Давайте рассмотрим, как пространство имен namespace облегчает управление ресурсами Kubernetes. Итак, что же такое пространство имен? Namespace можно рассматривать как виртуальный кластер внутри вашего кластера Kubernetes. Вы можете иметь несколько изолированных друг от друга пространств имен внутри одного кластера Kubernetes. Они реально могут помочь вам и вашим командам с организацией, безопасностью и даже производительностью системы.
В большинстве дистрибутивов Kubernetes кластер «выходит из коробки» с пространством имен, имеющим название «default». На самом деле существует три пространства имен, с которыми Kubernetes имеет дело: default, kube-system и kube-public. В настоящее время Kube- public используется не так уж часто.
Не трогать пространство имен kube – хорошая идея, особенно в такой управляемой системе, как Google Kubernetes Engine. Она использует пространство имен «default» как место, в котором создаются ваши сервисы и приложения. В нем нет абсолютно ничего особенного, за исключением того, что Kubernetes «из коробки» настроен на его использование, и вы не можете его удалить. Это отлично подходит для начала работы и систем с небольшой производительностью, но я бы не рекомендовал использовать default namespace в больших prod-системах. В последнем случае одна команда разработчиков может легко переписать чужой код и нарушить работу другой команды, даже не осознавая этого.
После ее выполнения вы увидите три встроенных пространства имен и новое пространство имен под названием «test». Давайте рассмотрим простой YAML-файл, предназначенный для создания pod. Можно заметить, что в нем нет никакого упоминания о пространстве имен.
Если примените kubectl для запуска этого файла, он создаст модуль mypod в текущем активном пространстве имен. Это будет пространство имен по умолчанию, пока вы его не измените. Существует 2 способа сообщить Kubernetes, в каком пространстве имен вы хотите создать свой ресурс. Первый способ — это использование флага пространства имен при создании ресурса.
Второй способ заключается в указании пространства имен в декларации YAML.
Если вы укажете пространство имен в YAML, то ресурс всегда будет создаваться в этом пространстве. Если вы попытаетесь использовать другое пространство имен при использовании флага пространства имен, то команда завершится ошибкой. Теперь, если вы попытаетесь найти свой pod, то не сможете этого сделать.
Это происходит потому, что все команды выполняются вне текущего активного пространства имен. Чтобы найти свой pod, вам нужно использовать флаг пространства имен, однако это быстро надоедает, особенно если вы работаете разработчиком в группе, которая использует свое собственное пространство имен и не хочет и использовать такой флаг для каждой отдельной команды. Давайте посмотрим, как это можно исправить.
Из коробки ваше активное пространство имен носит название default. Если вы не уточните пространство имен в YAML ресурса, то все команды Kubernetes будут использовать это активное default namespace. К сожалению, попытка управлять активным пространством имен с помощью kubectl может окончиться неудачей. Однако существует очень хороший инструмент под названием Kubens, который намного упрощает этот процесс. Когда вы запускаете команду kubens, то видите все пространства имен с подсвеченным активным пространством имен.
Это означает, что вам не нужен флаг пространства имен, чтобы увидеть pod в пространстве имен test.
Таким образом пространства имен скрыты друг от друга, но не изолированы друг от друга. Сервис из одного namespace может довольно легко общаться с сервисом в другом пространстве имен, что часто бывает очень полезно. Возможность коммуникации между разными пространствами имен означает, что сервис ваших разработчиков может взаимодействовать с сервисом другой dev-команды в другом пространстве имен.
Обычно, когда ваше приложение хочет получить доступ к сервису Kubernetes, вы используете встроенную службу обнаружения DNS и просто указываете своему приложению имя сервиса. Однако при этом вы можете создать сервис под одним и тем же именем в нескольких пространствах имен, что является недопустимым.
К счастью, это легко обойти, используя развернутую форму DNS-адреса. Сервисы в Kubernetes выставляют свои конечные точки, используя общий шаблон DNS. Это выглядит примерно так:
Как правило, вам просто нужно имя сервиса, и DNS автоматически определит полный адрес.
Однако если вам нужно получить доступ к сервису в другом пространстве имен, просто используйте имя службы плюс имя пространства имен:
Например, если вы хотите подключиться к базе данных сервиса в тестовом пространстве имен, вы можете использовать базу адресов database.test
Если же вы хотите подключиться к базе данных сервиса в пространстве имен prod, вы используете database.prod.
Если вы действительно хотите изолировать и ограничить доступ к пространству имен, Kubernetes позволяет сделать это с помощью сетевых политик Kubernetes Network Policies. Об этом я расскажу в следующей серии.
Мне часто задают вопрос, сколько пространств имен нужно создавать и для каких целей? Что же представляет собой управляемый фрагмент данных?
Если вы создадите слишком много пространств имен, они просто встанут у вас на пути. Если же их будет слишком мало, вы потеряете все преимущества подобного решения. Я думаю, что существует четыре основных этапа, которые проходит каждая компания в процессе создания своей организационной структуры. В зависимости от этапа развития, на котором находится ваш проект или компания, вы можете принять на вооружение соответствующую стратегию создания пространства имен.
Представьте, что вы являетесь частью небольшой команды, которая работает над разработкой 5-10 микросервисов и вы легко можете собрать всех разработчиков в одной комнате. В данной ситуации имеет смысл запускать все prod-сервисы в пространстве имен default. Конечно, для большего простора действий вы можете использовать 2 пространства имен — отдельно для prod и dev. И вероятнее всего, вы тестируете свою разработку на локальном компьютере с помощью чего-то наподобие Minikube.
Предположим, что условия поменялись и теперь у вас имеется быстро растущая команда, которая одновременно работает над более чем 10 микросервисами. Наступает момент, когда необходимо использовать несколько кластеров или пространств имен, отдельно для prod и dev. Можно разбить команду на несколько подгрупп так, чтобы у каждой из них были свои собственные микросервисы и каждая из этих команд могла бы выбрать свое собственное пространство имен для облегчения процесса управления разработкой и выпуском ПО.
По мере того, как каждый из членов команды получает представление о том, как работает система в целом, координировать каждое изменение со всеми остальными разработчиками становится все труднее и труднее. Попытка раскрутить полный стек на вашем локальном компьютере с каждым днем становится сложнее.
В крупных компаниях разработчики вообще не знают, кто конкретно над чем работает. Команды общаются с помощью сервисных контрактов или используют технологию Service mesh, которая добавляет над сетью уровень абстракции, типа инструмента конфигурации Istio. Попытка запустить весь стек локально просто невозможна.Я настоятельно рекомендую использовать в Kubernetes такую платформу непрерывной доставки (CD), как Spinnaker. Итак, наступает момент, когда каждой команде определенно нужно собственное пространство имен. Каждая команда даже может выбрать несколько пространств имен для среды dev и среды prod.
Наконец, существуют крупные предпринимательские компании, в которых одна группа разработчиков даже не знает о существовании других групп. Такая компания может вообще нанять сторонних разработчиков, которые взаимодействуют с через хорошо документированные API. В каждой такой группе имеется несколько команд и несколько микросервисов. В этом случае необходимо использовать все инструменты, о которых я говорил ранее.
Программисты не должны развертывать сервисы вручную и не должны иметь доступа к пространствам имен, которые их не касаются. На данном этапе целесообразно иметь несколько кластеров для уменьшения «радиуса взрыва» плохо настроенных приложений, для упрощения процессов биллинга и управления ресурсами.
Таким образом, правильное использование пространств имен вашей организацией позволяют сделать Kubernetes более управляемым, контролируемым, безопасным и гибким.
Немного рекламы 🙂
Kubernetes: знакомство, часть 1 – архитектура и основные компоненты, обзор
На текущем проекте у нас имеется API-бекенд для мобильных приложений на PHP Yii-фреймворке, который работает на стандартном LEMP – Linux/NGINX/PHP-FPM/MySQL.
Пришла пора и нам разбивать этот монолит на микросервисы, для управления которыми будет использоваться Kubernetes (AWS EKS).
В этом и последующих постах серии – знакомство с основными компонентами и архитектурой Kubernetes, ручное создание кластера и работа с AWS EKS.
Ниже достаточно кратко рассматривается общая архитектура, основные компоненты и понятия Kubernetes, а в следующих – перейдём к более практическим примерам, понемногу углубляюсь в детали и расширяя кругозор экосистемы Kubernetes.
В посте добавлено достаточно много ссылок до материалы, но основная проблема при поиске документации/примеров по Kubernetes – это то, что изменения появляются часто и быстро, а потому любые примеры и документация быстро устаревают – имейте это ввиду.
Архитектура – обзор
Общая схема K8s кластера выглядит так:
Или более простая схема:
Кластер состоит из одной или более Master Node, и одной или более Worker Node.
Master Node
Сервисы, работающие на Master-ноде называются “Kubernetes Control Plane” (кроме etcd ), при этом сам Master используется только для административных задач, тогда как реальные контейнеры с вашими сервисами будут запущены на Worker Node.
Kubernetes core services aka Kubernetes Control Plane
На Master Node работают три основных компонента, которые обеспечивают работу всех компонентов системы:
Key:value хранилище, используемое Kubernetes для управления конфигурациями и service discovery.
Кроме того, в нём хранится текущее (current) состояние системы, и желаемое (desired), например – после деплоймента.
Если K8s находит отличия в etcd между состояниями current и desired – он выполняет необходимые изменения.
Worker Node
Worker Node (ранее – minion) – виртуальная или физическая машина, на которой имеются компоненты Kubernetes для запуска Pod (см. Pod).
На Worker Node-ах работают два компонента:
Взаимодействие компонтентов
Например, при создании нового pod-а – процесс выглядит так:
Абстракции Kubernetes
Выше мы говорили о более-менее “осязаемых” вещах, таких как виртуальные машины, сети, IP-адреса и прочее.
Но сам Kubernetes являет собой один большой кусок… абстракции, “накладываемой” на виртуальную или физическую инфрастуктуру.
Соответственно, в K8s имеется множество собственных объектов, являющихся абстрактными, или логическими, компонентами Kubernetes.
Pod – основная логическая единица Kubernetes.
По сути своей, под является такой себе абстракцией виртуальной машины внутри Kunbernetes-кластера: у него есть свой приватный IP, имя хоста, общие данные на дисках (см. Volumes).
Pod является юнитом деплоймента (см. Deployment), и “внутри” этой “машины” запускаются один или более контейнеров, связанных общим назначением, и представляющих собой логическое приложение (состоящее из одного или более процессов/контейнеров).
Каждый под предзначен для запуска и обслуживания единственного экземпляра приложения: если вы хотите выполнить горизонтальное масштабирование приложения – вы должны использовать различные поды, по одному на каждый инстанс приложения.
Такая группа нод (Replicated Pods) управляется контроллером (см. Controllers).
При этом сами контейнеры не являются объектами Kubernetes и не управляются им: Kubernetes управляет подами, но контейнеры внутри этого пода используют общее сетевое пространство имён, включая IP адреса и порты, и могут обращаться друг к другу через localhost (потому как под == логическая виртуальная машина).
Пример шаблона для создания пода может выглядеть так:
Services
Сервисы – это, в первую очередь, про сеть внутри кластера и обеспечение доступа к подам из мира – они позволяют выполнять коммуникацию между различными компонентами внутри и снаружи приложения.
По сути, сервисы – точно такие же объекты Kubernetes, как Pod, ReplicaSets, DaemonSet, при этом вы можете представлять себе сервис как ещё один виртуальный сервер в ноде.
Например, сервисы можно условно обозначить так:
Тут пользователь приходит к приложению через один сервис, и попадает на фронтенд, затем сам фронтенд через два других сервиса взаимодействует с двумя сервисами бекенда, которые, в свою очередь, через ещё один сервис – общаются с серверов баз данных.
ClusterIP
Открывает доступ к сервису через внутренний IP кластера. Таким образом – сервис будет доступен только внутри самого класетра.
Является типом по-умолчанию.
NodePort
Увидеть подсети можно с помощью kubeadm config view :
Анонс иерархических пространств имен для Kubernetes
Прим. перев.: недавно в блоге Kubernetes был представлен проект «иерархических пространств имён». Формально он существует с конца прошлого года, но именно теперь авторы сочли уместным анонсировать свой Hierarchical Namespace Controller (HNC) для массовой аудитории. О предназначении и деталях реализации — читайте в этом материале, который мы также дополнили переводом дорожной карты HNC.
Безопасно разместить большое число пользователей в одном кластере Kubernetes всегда было непросто. Главная причина в том, что все организации используют Kubernetes по-разному, поэтому единая мультипользовательская модель вряд ли всем подойдет. Вместо этого Kubernetes предлагает компоненты для создания собственного решения, такие как управление доступом на основе ролей (RBAC) и NetworkPolicies; чем лучше эти компоненты, тем легче построить безопасный многопользовательский кластер.
Namespace’ы спешат на помощь
Безусловно, наиболее важными из этих компонентов являются пространства имен. Они выступают основой практически всех политик безопасности и совместного использования control plane в Kubernetes. Например, RBAC, NetworkPolicies и ResourceQuotas по умолчанию поддерживают пространства имен, а объекты вроде Secret, ServiceAccount и Ingress свободно доступны в рамках одного пространства, но полностью изолированы от других.
У namespace’ов есть пара ключевых особенностей, благодаря которым они идеально подходят для применения политик. Во-первых, их можно использовать для представления собственности. Большинство объектов Kubernetes должны входить в какое-либо пространство имен. Используя namespace’ы для представления собственности, вы всегда можете рассчитывать на то, что у этих объектов имеется владелец.
Во-вторых, создавать и использовать пространства имен могут только пользователи с соответствующим правами. Для создания namespace’ов нужны расширенные привилегии, а остальным пользователям требуется явное разрешение на работу с ними — то есть на создание, просмотр или изменение объектов в этих пространствах имен. Таким образом, сначала создается namespace с тщательно продуманным набором политик, и только после этого непривилегированные пользователи имеют возможность создавать «обычные» объекты вроде pod’ов и сервисов.
Ограничения namespace’ов
Увы, на практике пространства имен недостаточно гибки и плохо вписываются в некоторые распространенные сценарии использования. Например, некая команда владеет несколькими микросервисами с разными секретами и квотами. В идеале им следовало бы разнести эти сервисы по отдельным пространствам имен, чтобы изолировать их друг от друга, но тут возникают две проблемы.
Во-первых, у этих namespace’ов отсутствует единая концепция владения, хотя ими обоими владеет одна команда. Это означает, что не только Kubernetes ничего не знает о том, что у этих namespace’ов один владелец, но и отсутствует возможность применять глобальные политики сразу ко всем подконтрольным namespace’ам.
Во-вторых, как известно, автономность — залог эффективной работы команд. Поскольку создание namespace’ов требует расширенных привилегий, маловероятно, что эти привилегии окажутся у кого-либо из команды разработчиков. Другими словами, всякий раз, когда команда решает создать новое пространство имен, ей приходится обращаться к администратору кластера. Это может быть вполне приемлемо для небольшой компании, однако по мере роста все сильнее проявляется негативный эффект от подобной организации.
Представляем иерархические пространства имен
Иерархические namespace’ы — новая концепция, разработанная рабочей группой Kubernetes по multi-tenancy (wg-multitenancy), чтобы решить эти проблемы. В упрощенном виде иерархический namespace представляет собой обычное пространство имен Kubernetes со включением небольшого custom-ресурса, который указывает на одно (необязательное) родительское пространство имен. Тем самым концепция владения расширяется на сами пространства имен, а не только на объекты внутри их.
Концепция владения также реализует два дополнительных типа отношений:
Немного практики
Иерархические namespace’ы реализованы с помощью расширения Kubernetes под названием Hierarchical Namespace Controller или HNC. HNC состоит из двух компонентов:
Давайте посмотрим на работу HNC. Предположим, у меня нет привилегий на создание namespace’ов, но я могут просматривать пространство имен team-a и создавать subnamespace’ы в нем*. Плагин позволяет мне ввести следующую команду:
* Технически говоря, вы создаете небольшой объект под названием «subnamespace anchor» («подпространственный якорь») в родительском пространстве и затем HNC создает subnamespace.
Просмотреть получившуюся структуру можно с помощью команды tree :
* По умолчанию распространяются только Roles и RoleBindings в RBAC, но можно настроить HNC на распространение любого объекта Kubernetes.
Наконец, HNC добавляет к этим пространствам имен метки с полезной информацией об иерархии. Их можно использовать для применения других политик. Например, можно создать следующую NetworkPolicy:
Подробности о функционале HNC можно получить в руководстве пользователя.
Дальнейшие шаги и участие в процессе
Если вы считаете, что иерархические namespace’ы пригодятся в вашей организации, версия HNC v0.5.1 доступна на GitHub (с 28 августа доступен релиз v0.5.2 — прим. перев.). Мы бы хотели узнать, что вы думаете о ней, какие проблемы решаете с ее помощью и какие функции хотели бы в нее добавить. Как и в случае с любым ПО на начальных этапах разработки, необходимо соблюдать осторожность при использовании HNC в production. При этом чем больше обратной связи мы получим, тем быстрее сможем прийти к HNC 1.0.
Мы также приветствуем вклад сторонних contributor’ов, будь то исправление ошибок/информация о них или помощь в создании прототипов новых функций, таких как исключения, улучшенный мониторинг, иерархическое квотирование ресурсов или оптимизация конфигурации.
Связаться с нами можно в репозитории, рассылке или в Slack. С нетерпением ждем ваших комментариев!
Автор оригинального анонса — Adrian Ludwin, инженер-программист и технический руководитель Hierarchical Namespace Controller.
Бонус! Дорожная карта и issues
Пожалуйста, создавайте issues — чем больше, тем веселее! Баги будут анализироваться в первую очередь, а для feature request’ов будет определяться приоритет, после чего их включат в план работ или в бэклог.
HNC пока еще не получил статус GA, поэтому будьте осторожны при его использовании в кластерах с конфигурационными объектами, которые не можете позволить себе потерять (например, с теми, которые не хранятся в репозитории Git).
Все issues HNC включаются в соответствующий план работ. На данный момент реализованы или намечены следующие основные этапы этого плана: