Для чего нужен Namespace в Kubernetes?

Основное назначение Namespace в Kubernetes

Namespace (пространство имён) в Kubernetes — это ключевой механизм виртуального разделения одного физического кластера на несколько изолированных логических единиц. Он представляет собой фундаментальный инструмент для организации, управления доступом и распределения ресурсов в рамках единой инфраструктуры.

Решаемые задачи и ключевые функции

1. Логическая изоляция и организация

Namespaces позволяют сегментировать кластер на отдельные "виртуальные кластеры", что критически важно в мультитенантных средах:

• Разделение по командам/проектам: Разные отделы (dev, QA, production) работают в своих пространствах, не мешая друг другу.
• Разделение по окружениям: development, staging, production могут быть разными неймспейсами в одном кластере.
• Разделение по клиентам или приложениям: В моделях SaaS или при обслуживании множества продуктов.

apiVersion: v1
kind: Namespace
metadata:
  name: production-backend
  labels:
    environment: production
    team: platform

2. Управление доступом на основе RBAC

Namespaces являются основной областью действия для политик RBAC (Role-Based Access Control). Позволяют детально контролировать, кто и что может делать в каждой зоне кластера.

# Role, действующая ТОЛЬКО в namespace "monitoring"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

3. Квотирование и лимитирование ресурсов

Через ResourceQuota администраторы могут устанавливать жёсткие лимиты на потребление ресурсов (CPU, память, количество Pod'ов и т.д.) для каждого namespace, предотвращая "захват" всех ресурсов одним проектом.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "10"

4. Изоляция имён ресурсов

В рамках одного namespace имена ресурсов (Pods, Services, Deployments) должны быть уникальны, но эти же имена могут повторно использоваться в других namespace. Это позволяет использовать стандартные конфигурации (например, frontend, backend, redis) в разных изолированных средах.

# Сервис "app-service" в namespace "dev" и в namespace "prod" — это РАЗНЫЕ сервисы
kubectl get svc app-service -n dev
kubectl get svc app-service -n prod

5. Управление сетевыми политиками (Network Policies)

С помощью NetworkPolicy можно определять правила входящего/исходящего трафика между Pod'ами с привязкой к namespace, реализуя микросегментацию сети.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-namespace
  namespace: protected-app
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: trusted-namespace

6. Упрощение администрирования и навигации

Namespaces позволяют структурировать ресурсы и выполнять операции в определённом контексте, используя флаг -n в kubectl. Без указания namespace команды применяются к default-пространству.

# Все операции ниже касаются только namespace 'staging'
kubectl config set-context --current --namespace=staging
kubectl get pods
kubectl apply -f deployment.yaml

Важные технические аспекты и ограничения

• Не полная изоляция: Важно понимать, что namespace не обеспечивает полной изоляции на уровне ядра или runtime (это задача для RuntimeClass, securityContext). Pod'ы из разных namespace по умолчанию могут взаимодействовать по сети, если нет ограничивающих NetworkPolicy.
• Глобальные ресурсы кластера: Некоторые ресурсы являются кластерными (ClusterRole, PersistentVolume, CustomResourceDefinition) и находятся вне scope какого-либо namespace.
• Служебные namespaces: В кластере по умолчанию существуют системные namespaces, такие как kube-system (компоненты управления), kube-public, kube-node-lease. Не рекомендуется размещать в них пользовательские workloads.

Практические рекомендации по использованию

1. Избегайте создания большого количества namespace без необходимости. Каждый добавляет накладные расходы на управление (роли, квоты, политики).
2. Используйте labeling для namespace так же, как и для других ресурсов, для удобной селекции и управления.
3. Для очень маленьких команд или простых проектов можно обойтись namespace по умолчанию (default), но даже тогда рекомендуется выделять отдельное пространство для production.
4. Инструменты вроде Helm хорошо работают с namespaces, позволяя устанавливать чарты в определённый изолированный контекст.

Итог: Namespace — это не контейнер виртуализации, а мощный организационно-административный примитив для логического разделения, управления доступом и ресурсами внутри единого Kubernetes-кластера. Его правильное использование — основа безопасной, эффективной и структурированной работы в production-средах.