What Are Namespace Best Practices?

Detailed Answer

Namespaces are a cornerstone of Kubernetes cluster organization. Well-designed namespace strategies simplify access control, resource management, and operational visibility.

1. Do Not Use the Default Namespace

The default namespace catches all resources created without a namespace. This leads to:

• No RBAC isolation
• No ResourceQuota enforcement
• Unclear ownership
• Cluttered kubectl output

# Bad: deploying without a namespace
kubectl apply -f deployment.yaml

# Good: always specify a namespace
kubectl apply -f deployment.yaml -n team-backend

Set your context to avoid accidentally deploying to default:

kubectl config set-context --current --namespace=team-backend

2. Label All Namespaces

Labels enable Network Policies, admission webhooks, and monitoring to target specific namespaces:

apiVersion: v1
kind: Namespace
metadata:
  name: team-backend
  labels:
    team: backend
    environment: production
    cost-center: engineering
    pod-security.kubernetes.io/enforce: restricted

3. Apply ResourceQuotas to Every Namespace

Prevent any namespace from consuming all cluster resources:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: standard-quota
  namespace: team-backend
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "100"
    services.loadbalancers: "3"
    persistentvolumeclaims: "20"

4. Set Default Resource Limits with LimitRange

Ensure every container has resource constraints:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-backend
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "256Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      max:
        cpu: "4"
        memory: "8Gi"

5. Apply RBAC Per Namespace

Give teams access only to their namespace:

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

6. Apply Network Policies

Implement default-deny and explicit allow rules:

# Default deny all ingress and egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: team-backend
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Allow ingress from the frontend namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: team-backend
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: frontend

7. Namespace Naming Conventions

Use consistent, descriptive names:

# Good
team-backend
team-frontend
monitoring
ingress-system

# Bad
backend         # Too generic, could conflict
team1           # Not descriptive
my-namespace    # Meaningless
Test-NS         # Avoid uppercase and special characters

8. Automate Namespace Provisioning

Use a namespace provisioner or controller to apply standard policies when namespaces are created:

# Using a Kyverno policy to auto-create quotas
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-quota-to-namespaces
spec:
  rules:
    - name: generate-quota
      match:
        resources:
          kinds:
            - Namespace
          selector:
            matchLabels:
              type: team
      generate:
        kind: ResourceQuota
        name: standard-quota
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            hard:
              requests.cpu: "20"
              requests.memory: "40Gi"
              pods: "100"

Namespace Strategy Decision Matrix

| Factor | Per Team | Per Environment | Per Application | |---|---|---|---| | RBAC alignment | Strong | Moderate | Weak | | Operational overhead | Low | Low | High | | Resource isolation | Good | Good | Granular | | Number of namespaces | Low (5-20) | Low (3-5) | High (50+) | | Best for | Multi-team clusters | Small organizations | Platform teams |

Common Mistakes

1. No quotas on namespaces: One namespace can starve the entire cluster
2. Overly granular namespaces: One namespace per microservice creates management overhead
3. Missing network policies: Namespaces are not network boundaries by default
4. Sharing the default namespace: Makes RBAC and auditing impossible
5. No namespace labels: Prevents policy enforcement and monitoring segmentation