Thank you for reading this post, don't forget to subscribe!
Kubernetes поддерживает несколько виртуальных кластеров, работающих в одном и том же физическом кластере. Эти виртуальные кластеры называются пространствами имен или неймспейсами (namespaces)..
Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.
Неймспейсы, как можно догадаться с названия, предоставляют набор (или область) имен для ресурсов. Имена ресурсов должны быть уникальными в пределах одного неймспейса, но не в пределах всего кластера. Кроме того, неймспейсы - это способ разделить ресурсы кластера между пользователями (с использованием квот).
ПРИМЕЧАНИЕ: нет необходимости использовать разные неймспейсы для разделения нескольких разных ресурсов, например, разных версий одного и того же ПО - здесь лучше воспользоваться метками и селекторами (для выделения ресурсов) в одном и том же пространстве имен.
По умолчанию в кластере Kubernetes будет создан неймспейс default, в котором и будут размещаться запускаемые объекты (поды, сервисы, развертывания и т.д.). Неймспейсы kube-public и kube-system используются для запуска служебных объектов Kubernetes, необходимых для корректной работы кластера.
Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:
|
1 2 3 4 5 6 |
kubectl get namespaces NAME STATUS AGE default Active 46d kube-public Active 46d kube-system Active 46d |
Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:
|
1 2 3 4 5 6 7 8 9 10 11 |
{ <span class="hljs-attr">"kind"</span>: <span class="hljs-string">"Namespace"</span>, <span class="hljs-attr">"apiVersion"</span>: <span class="hljs-string">"v1"</span>, <span class="hljs-attr">"metadata"</span>: { <span class="hljs-attr">"name"</span>: <span class="hljs-string">"development"</span>, <span class="hljs-attr">"labels"</span>: { <span class="hljs-attr">"name"</span>: <span class="hljs-string">"development"</span> } } } |
и выполним команду:
|
1 2 |
kubectl apply <span class="hljs-_">-f</span> namespace-dev.json |
Для второго неймспейса создадим файл с тем же содержимым, но заменим слова “development” на “production” и применим его:
|
1 2 |
kubectl apply <span class="hljs-_">-f</span> namespace-prod.json |
Убедимся, что неймспейсы успешно создались:
|
1 2 3 4 5 6 7 8 |
kubectl get namespaces --show-labels NAME STATUS AGE LABELS default Active 46d <none> development Active 2m name=development kube-public Active 46d <none> kube-system Active 46d <none> production Active 2m name=production |
Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
kubectl config view apiVersion: v1 clusters: - cluster: insecure-skip-tls-verify: <span class="hljs-literal">true</span> server: https://localhost:6443 name: docker-for-desktop-cluster contexts: - context: cluster: docker-for-desktop-cluster user: docker-for-desktop name: docker-for-desktop current-context: docker-for-desktop kind: Config preferences: {} users: - name: docker-for-desktop user: client-certificate-data: REDACTED client-key-data: REDACTED |
|
1 2 3 |
kubectl config current-context docker-for-desktop |
Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):
|
1 2 3 4 5 6 7 |
kubectl config <span class="hljs-built_in">set</span>-context dev --namespace=development \ --cluster=docker-for-desktop-cluster \ --user=docker-for-desktop kubectl config <span class="hljs-built_in">set</span>-context prod --namespace=production \ --cluster=docker-for-desktop-cluster \ --user=docker-for-desktop |
После выполнения этих двух команд к конфигурационном файле ~/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:
|
1 2 |
kubectl config use-context dev |
и
|
1 2 |
kubectl config use-context prod |
Кроме того, выполнять команды с конкретным неймспейсом можно даже не переключая контекст - достаточно использовать дополнительный параметр --namespace=, например:
|
1 2 |
kubectl --namespace=dev run nginx --image=nginx |
или
|
1 2 |
kubectl --namespace=prod get pods |
Напоследок стоит сказать, что при создании сервиса (service) в кластере Kubernetes создается соответствующая DNS-запись. Запись создается в формате <service-name>.<namespace-name>.svc.cluster.local, а это означает, что если вы используете только часть <service-name> то это позволит “достучаться” до сервиса только в пределах неймспейса. Если вам необходимо взаимодействовать с сервисом, запущенным в другом неймспейсе, следует использовать полное доменное имя (FQDN).