Что такое Namespace

Namespace в Kubernetes — это логическая (именованная) область в кластере, которая группирует ресурсы (Pod, Service, Deployment, Secret и т.д.). По факту namespace даёт пространственную область видимости имён: объекты с одинаковыми именами могут существовать в разных namespace, а большинство ресурсов по умолчанию — namespace-scoped.

Для чего используется (основные цели)

• Разделение областей видимости — каждый namespace содержит свой набор объектов; позволяет избежать конфликтов имён (svcA в team-a ≠ svcA в team-b).

• Многоарендность/логическая изоляция — удобен для разделения команд, проектов, окружений (dev/stage/prod) внутри одного кластера.

• Разграничение прав доступа (RBAC) — Role/RoleBinding действуют в контексте namespace; даёт мелкую гранулярность прав.

• Ограничение ресурсов — ResourceQuota и LimitRange применяются на namespace и предотвращают перерасход CPU/memory/storage.

• Сетевая сегментация — NetworkPolicy может контролировать ingress/egress между namespace.

• Организация и управление — структурирование окружений, автоматизация onboarding, привязка billing/monitoring.

Важные практики и поведение

• Системные namespace: default, kube-system, kube-public, kube-node-lease. Не ломайте их; создавайте свои для приложений.

• DNS-имена: сервис доступен через my-svc.my-namespace.svc.cluster.local. Это позволяет вызывать сервисы из других namespace по полному имени.

• RBAC: Role/RoleBinding — namespace-scoped; ClusterRole/ClusterRoleBinding — глобальные. Для изоляции давайте ролям доступ только к нужному namespace.

• Ресурсы секьюрити: Secret, ConfigMap, ServiceAccount, PersistentVolumeClaim — имеют область видимости namespace; нельзя напрямую ссылаться на Secret из другого namespace.

• ResourceQuota / LimitRange — пример: ограничить CPU/memory, количество подов, PVC в namespace.

apiVersion: v1
kind: Namespace
metadata:
name: dev
\---
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
pods: "20"
requests.cpu: "10"
requests.memory: 20Gi
persistentvolumeclaims: "5"

• Политики сети (пример): запретить входящий трафик в namespace, кроме от приложений того же namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-from-others
namespace: dev
spec:
podSelector: {}
policyTypes: \["Ingress"\]
ingress:
\- from:
\- podSelector: {} # только из этого же namespace

Практические команды

• Создать namespace: kubectl create namespace team-a или манифестом.

• Работать в namespace: kubectl -n team-a get pods или установить дефолт в контексте: kubectl config set-context --current --namespace=team-a.

• Привязать роль: kubectl create rolebinding view-team-a --role=view --namespace=team-a --user=alice@example.com.

Ограничения и советы по дизайну

• Namespace — логическая, а не безопасная изоляция уровня «железо». Для строгой мультиарендности (полная изоляция, отдельный сетевой/учётный boundary) лучше отдельные кластеры.

• Не злоупотребляйте: слишком много мелких namespace усложняет управление; слишком мало — мешает разделению ответственности. Подходы: окружения (prod/dev/stage) или по командам/проектам.

• Комбинируйте namespace с ResourceQuota, NetworkPolicy и RBAC для реальной многопользовательской дисциплины.

• Используйте метки (labels) на namespace для автоматизации (CI/CD, billing, политики) и единых правил через OPA/Gatekeeper.

Жизненный цикл

• Удаление namespace — операция, которая удаляет все входящие в него ресурсы; удаление может занимать время из-за finalizers. Планируйте осторожно и имейте бэкапы/истории IaC.

Используйте namespace как основной инструмент логической сегментации кластера, но проектируйте политику доступа и квоты, комбинируя с сетевыми и RBAC-механизмами; при требованиях строгой изоляции рассматривайте отдельные кластеры.