Namespaces for ML Teams Intermediate

Namespaces provide logical isolation within a Kubernetes cluster. For ML platforms, namespaces enable multi-team resource sharing with clear boundaries for resource quotas, RBAC, network policies, and cost attribution.

Namespace Strategy for ML

YAML

# Create team namespaces
apiVersion: v1
kind: Namespace
metadata:
  name: ml-team-nlp
  labels:
    team: nlp
    environment: production
    cost-center: cc-nlp-4200
---
apiVersion: v1
kind: Namespace
metadata:
  name: ml-team-cv
  labels:
    team: computer-vision
    environment: production
    cost-center: cc-cv-4300

Namespace Design Patterns

Pattern	Namespaces	Best For
Per-team	ml-team-nlp, ml-team-cv, ml-team-rec	Team isolation with per-team quotas
Per-environment	ml-dev, ml-staging, ml-prod	Environment-based isolation
Hybrid	nlp-dev, nlp-prod, cv-dev, cv-prod	Team + environment isolation

RBAC per Namespace

YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: nlp-team-access
  namespace: ml-team-nlp
subjects:
- kind: Group
  name: nlp-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Network Policies

Isolate namespaces from each other while allowing access to shared services:

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: ml-team-nlp
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # Allow within same namespace only

Best Practice: Use the per-team namespace pattern for ML clusters. Each team gets their own namespace with dedicated resource quotas, RBAC roles, and network policies. Shared services (model registry, feature store) run in a separate shared-services namespace.

← Architecture Resource Quotas →