4. Kubernetes: NAMESPACE (Пространства имен)

Пространства имен (Namespaces) в Kubernetes

Namespaces в Kubernetes предоставляют механизм для изоляции групп ресурсов внутри одного кластера. Это полезный инструмент, позволяющий разделять рабочие нагрузки, организовывать ресурсы и управлять доступом в кластере.

Основные особенности namespaces

1. Изоляция ресурсов:
   В рамках одного пространства имен названия ресурсов должны быть уникальными, но одинаковые имена можно использовать в разных namespaces. Например, в каждом namespace можно создать под с именем nginx, и они не будут конфликтовать друг с другом.
2. Ограничения:
   • Пространства имен не могут быть вложенными.
   • Один ресурс может принадлежать только одному namespace.
3. Применение:
   Namespace-ориентированное управление относится только к объектам, которые поддерживают namespaces (например, поды, сервисы, деплойменты). Кластерные объекты, такие как Nodes, StorageClass и PersistentVolumes, работают вне контекста namespaces.
4. Разделение пользователей:
   Используя namespaces совместно с квотами ресурсов (ResourceQuota), можно распределить ресурсы кластера между различными пользователями или командами.

Когда использовать несколько namespaces?

Namespaces подходят для крупных кластеров с большим количеством пользователей, проектов или рабочих нагрузок. Однако в небольших кластерах (до десятков пользователей) их использование может быть излишним.

Примеры случаев для использования namespaces:

• Разделение окружений (например, Development, Staging, Production).
• Изоляция ресурсов для разных команд или проектов.
• Управление доступом к ресурсам через RBAC.

Важно:
Для продакшн-систем рекомендуется избегать использования default namespace. Лучше создать и использовать свои namespaces для большей организации и безопасности.

Стандартные namespaces в Kubernetes

Kubernetes включает четыре начальных пространства имен:

Примечание:
Избегайте создания namespaces с префиксом kube-, так как он зарезервирован для системных целей.

Работа с namespaces

Просмотр доступных namespaces:

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

Создание и удаление namespaces:

Создание namespace через манифест:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

Применение:

kubectl apply -f namespace.yaml

Удаление:

kubectl delete namespace my-namespace

Установка namespace для текущих запросов:

Используйте флаг --namespace:

kubectl get pods --namespace=my-namespace

Постоянная установка namespace:

kubectl config set-context --current --namespace=my-namespace
# Проверка настройки
kubectl config view --minify | grep namespace:

Namespaces и DNS

При создании сервиса в Kubernetes для него автоматически создается DNS-запись вида:

<service-name>.<namespace-name>.svc.cluster.local

Это позволяет использовать один и тот же конфигурационный файл в нескольких namespaces, например, для окружений Development, Staging и Production. Чтобы обратиться к сервису из другого namespace, используйте полный доменный адрес (FQDN).

Примечание:
Названия namespaces должны соответствовать требованиям RFC 1123 для DNS-меток.

Автоматическое присвоение меток

С Kubernetes версии 1.22 каждое namespace получает неизменяемую метку kubernetes.io/metadata.name, значение которой совпадает с названием namespace. Это упрощает управление и поиск объектов.

Пример:

kubectl get namespace my-namespace --show-labels

Какие ресурсы относятся к namespaces?

Большинство объектов Kubernetes, таких как поды, сервисы, деплойменты и контроллеры, работают в рамках namespaces. Однако существуют объекты, которые не принадлежат namespace, например:

• Nodes
• PersistentVolumes
• ClusterRole

Чтобы увидеть список ресурсов в namespaces:

kubectl api-resources --namespaced=true

И объектов вне namespaces:

kubectl api-resources --namespaced=false

Предостережения

• Избегайте создания namespaces с названиями, совпадающими с публичными доменными именами. Это может привести к конфликтам в DNS и перенаправлению трафика внутри кластера.
• Ограничивайте возможность создания namespaces для пользователей через RBAC или другие политики.