Kubernetes — пространство имен |

Kubernetes NAMESPACE — это виртуальный кластер для организации и структурирования объектов Kubernetes.

Не все объекты находятся в пространстве имен. Большинство ресурсов Kubernetes (например, модули, сервисы, контроллеры репликации) находятся в некоторых пространствах имен. Мы имеем в виду такой объект, как объект Kubernetes с пространством имен здесь. Однако сами ресурсы пространства имен не находятся в пространстве имен. а низкоуровневые ресурсы, такие как узлы и постоянные тома, не находятся ни в одном пространстве имен.

Kubernetes создал три предварительно настроенных пространства имен:

Пространство имен по умолчанию: Каждый объект Kubernetes с пространством имен, созданный без указания пространства имен, попадает в пространство имен по умолчанию.

В пространстве имен системы: Это пространство имен используется для системных процессов, таких как etcd, kube-scheduler и т. д. Не изменяйте и не создавайте какие-либо объекты в этом пространстве имен, так как оно не предназначено для пользователей.

Kube-общедоступное пространство имен: Это пространство имен содержит общедоступные данные, в том числе ConfigMap, в котором хранится информация о кластере, такая как общедоступный сертификат кластера для связи с API Kubernetes.

Создание новых пространств имен

kubectl create namespace ns-development

Просмотр пространств имен

kubectl get namespace
--or 
kubectl get ns

Установка пространства имен ns-development в качестве текущего пространства имен

kubectl config set-context --current --namespace=ns-development

Создание ресурсов в пространстве имен

Давайте взглянем на простой YAML для создания пода:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

Вы могли заметить, что нигде нет упоминания о пространствах имен. Если вы запустите kubectl apply в этом файле он создаст под в текущем активном пространстве имен. Это будет пространство имен «по умолчанию», если вы его не измените.

Есть два способа явно указать Kubernetes, в каком пространстве имен вы хотите создать свои ресурсы. Один из способов — установить флаг «namespace» при создании ресурса:

kubectl apply -f pod.yaml --namespace=test

Если вы укажете пространство имен в декларации YAML, ресурс всегда будет создаваться в этом пространстве имен. Если вы попытаетесь использовать флаг «пространство имен» для установки другого пространства имен, команда завершится ошибкой.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: test
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

Связь в пространствах имен

Объект Kubernetes может напрямую обращаться к другому объекту в том же пространстве имен, используя его имя. Например, Pod может получить доступ к Сервису в том же Пространстве имен, используя имя Сервиса.

Взаимодействие между пространствами имен

Пространства имен «скрыты» друг от друга, но по умолчанию они не полностью изолированы. Служба в одном пространстве имен может взаимодействовать со службой в другом пространстве имен. Часто это может быть очень полезно, например, чтобы служба вашей группы в вашем пространстве имен взаимодействовала со службой другой группы в другом пространстве имен.

Когда вашему приложению требуется доступ к службе Kubernetes, вы можете использовать встроенное обнаружение службы DNS и просто указать свое приложение на имя службы. Службы в Kubernetes предоставляют свою конечную точку, используя общий шаблон DNS. Это выглядит так:

<Service Aame>.<Namespace Name>.svc.cluster.local

Например, если вы хотите подключиться к сервису «база данных» в пространстве имен «test», вы можете использовать следующий адрес:

database.test

Если вы хотите подключиться к сервису «база данных» в пространстве имен «производство», вы можете использовать следующий адрес:

database.production

Примечание. Если вы хотите изолировать пространства имен, вам следует использовать Сетевые политики чтобы выполнить это.

Квота ресурсов пространств имен

Для каждого пространства имен можно настроить свою политику в отношении того, кто может изменять, создавать или редактировать объект в пространстве имен. Модель управления разрешениями, стоящая за этим, называется RBAC (управление доступом на основе ролей). Индивидуальные назначения ролей позволяют различным командам использовать пространства имен в общем кластере. Ограничения ресурсов также могут быть назначены пространству имен, которое будет контролировать запросы и операции памяти и ЦП.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-cpu-quota
  namespace: ns-development
spec:
  hard:
    requests.cpu: "100m"  
    limits.cpu: "200m"