Setting Up Development, Testing, and Production Namespaces in Kubernetes: A Practical Guide 2025

When you first start working with Kubernetes, it's tempting to deploy everything into the default namespace. While this works for learning and small projects, as your applications grow, proper namespace separation becomes crucial for security, resource management, and operational clarity.

Why Namespace Separation Matters

Imagine deploying a new feature that accidentally consumes all available resources, or worse, a security vulnerability that exposes production data. Without proper namespace isolation, these scenarios can impact your entire cluster. By separating your workloads into development, testing, and production namespaces, you create clear boundaries that help:

• Prevent resource conflicts between environments
• Isolate security concerns
• Simplify access control and permissions
• Enable environment-specific configurations
• Make monitoring and debugging easier

Basic Namespace Setup

kubectl create namespace development
kubectl create namespace testing
kubectl create namespace production

However, just creating namespaces isn't enough. We need to configure them properly.

Resource Quotas and Limits

One of the first things you should implement is resource quotas. This prevents any single namespace from consuming all cluster resources:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi

Network Policies: The Security Layer

Here's where things get interesting. Network Policies in Kubernetes act like a firewall between namespaces. By default, all pods can communicate with each other across namespace boundaries - probably not what you want in a production environment.

A common pattern is to:

• Allow testing to access development (for integration tests)
• Block all access to production except from specific sources
• Enable monitoring tools to access all namespaces Here's an example of a restrictive network policy for production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: production-lockdown
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090

Role-Based Access Control (RBAC)

RBAC is crucial for controlling who can do what in each namespace. A typical setup might look like:

• Developers get full access to development, read access to testing
• QA gets full access to testing, read access to development
• Only senior DevOps engineers get production access

Conclusion

Properly configured namespaces are a fundamental building block of a secure and manageable Kubernetes cluster. While the initial setup requires careful planning and implementation, the benefits in terms of security, resource management, and operational clarity are well worth the effort.

Please feel free to comment your tips for running a secure kubenettes system.