Skip to content

Kubernetes_namespaces

Chapter 24: Kubernetes Namespaces - Logical Isolation

Section titled “Chapter 24: Kubernetes Namespaces - Logical Isolation”
  1. Introduction to Namespaces
  2. Why Use Namespaces?
  3. Working with Namespaces
  4. Resource Quotas
  5. LimitRanges
  6. Namespace Isolation
  7. Best Practices
  8. Hands-on Lab
  9. Summary

Namespaces provide a mechanism for isolating groups of resources within a single cluster. They provide a way to divide cluster resources between multiple users or teams.

┌─────────────────────────────────────────────────────────────────────────────┐
│ KUBERNETES NAMESPACES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ KUBERNETES CLUSTER │ │
│ │ │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────┐ │ │
│ │ │ development │ │ staging │ │ production │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌──────────┐ │ │ │
│ │ │ │ Deployment │ │ │ │ Deployment │ │ │ │Deployment│ │ │ │
│ │ │ │ myapp │ │ │ │ myapp │ │ │ │ myapp │ │ │ │
│ │ │ └────────────┘ │ │ └────────────┘ │ │ └──────────┘ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌──────────┐ │ │ │
│ │ │ │ Service │ │ │ │ Service │ │ │ │ Service │ │ │ │
│ │ │ └────────────┘ │ │ └────────────┘ │ │ └──────────┘ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌──────────┐ │ │ │
│ │ │ │ ConfigMap│ │ │ │ ConfigMap │ │ │ │ ConfigMap│ │ │ │
│ │ │ └────────────┘ │ │ └────────────┘ │ │ └──────────┘ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ └──────────────────┘ └──────────────────┘ └──────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ │
│ Each namespace is logically isolated with its own: │
│ • Resources (Pods, Services, Deployments, etc.) │
│ • Policies (RBAC, Network Policies) │
│ • Quotas and Limits │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Terminal window
# List namespaces
kubectl get ns
# Output:
# NAME STATUS AGE
# default Active 24d
# kube-node-lease Active 24d
# kube-public Active 24d
# kube-system Active 24d
  • default - Default namespace for user resources
  • kube-system - System-created resources
  • kube-public - Publicly readable resources
  • kube-node-lease - Node heartbeat/lease objects

┌─────────────────────────────────────────────────────────────────────────────┐
│ WHY USE NAMESPACES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. MULTI-TENANT ISOLATION │
│ ────────────────────────── │
│ • Separate environments (dev, staging, prod) │
│ • Different teams or projects │
│ • Customer isolation │
│ │
│ 2. RESOURCE MANAGEMENT │
│ ────────────────────── │
│ • Apply quotas per namespace │
│ • Limit resources per team │
│ • Cost allocation │
│ │
│ 3. ACCESS CONTROL │
│ ───────────────── │
│ • Role-based access per namespace │
│ • Team-specific permissions │
│ • Security boundaries │
│ │
│ 4. ORGANIZATION │
│ ────────────── │
│ • Logical grouping of resources │
│ • Easy resource management │
│ • Clear separation of concerns │
│ │
│ 5. ENVIRONMENT ISOLATION │
│ ──────────────────────── │
│ • Different configs per environment │
│ • Separate database instances │
│ • Independent deployments │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

Terminal window
# Create namespace
kubectl create namespace development
# Or using YAML
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: development
EOF
Terminal window
# View current namespace
kubectl config view | grep namespace
# Switch namespace
kubectl config set-context --current --namespace=development
# Or use kubens (if installed)
kubens development
# Get resources in specific namespace
kubectl get pods -n development
# Get resources in all namespaces
kubectl get pods --all-namespaces
kubectl get pods -A
Terminal window
# Delete namespace (deletes all resources in namespace)
kubectl delete namespace development
# Delete all resources in namespace but keep namespace
kubectl delete all --all -n development

A ResourceQuota object provides constraints that limit aggregate resource consumption per namespace.

resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: development-quota
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
pods: "50"
services: "10"
secrets: "20"
configmaps: "30"
persistentvolumeclaims: "20"
┌─────────────────────────────────────────────────────────────────────────────┐
│ RESOURCE QUOTA ENFORCEMENT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ RESOURCEQUOTA │ │
│ │ name: team-quota │ │
│ │ │ │
│ │ hard: │ │
│ │ pods: "20" │ │
│ │ services: "10" │ │
│ │ secrets: "30" │ │
│ │ requests.cpu: "10" │ │
│ │ requests.memory: 20Gi │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ ENFORCEMENT │ │
│ │ │ │
│ │ User tries to create 21st pod │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ Error: pods "exceeds quota" │ │ │
│ │ │ │ │ │
│ │ │ Request rejected! │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ │
Terminal window
# Get quota
kubectl get resourcequota -n development
# Describe quota (shows usage)
kubectl describe resourcequota -n development

A LimitRange provides constraints that can limit the resource consumption for individual Pods or Containers in a namespace.

limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: development-limits
spec:
limits:
# Default limits for containers
- max:
cpu: "2"
memory: 1Gi
min:
cpu: 100m
memory: 128Mi
default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 200m
memory: 256Mi
type: Container
# Default limits for pods
- max:
cpu: "4"
memory: 2Gi
min:
cpu: 100m
memory: 128Mi
type: Pod
┌─────────────────────────────────────────────────────────────────────────────┐
│ LIMITRANGE BEHAVIOR │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ LimitRange Rules: │
│ ───────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ If container has NO requests/limits specified: │ │
│ │ ──────────────────────────────────────────────────── │ │
│ │ │ │
│ │ Container Spec: Applied: │ │
│ │ containers: requests.cpu: 200m │ │
│ │ - name: app requests.memory: 256Mi │ │
│ │ image: nginx limits.cpu: 500m │ │
│ │ limits.memory: 512Mi │ │
│ │ │ │
│ │ DefaultRequest values are used! │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ If container requests MORE than max: │ │
│ │ ───────────────────────────────────── │ │
│ │ │ │
│ │ Container Spec: Error: │ │
│ │ resources: "Container exceeded maximum │ │
│ │ limits: cpu limit of 2" │ │
│ │ cpu: "4" │ │
│ │ │ │
│ │ Rejected! │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │

network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: developer
rules:
- apiGroups: [""]
resources: ["pods", "services", "configmaps"]
verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

┌─────────────────────────────────────────────────────────────────────────────┐
│ NAMESPACE BEST PRACTICES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ✓ DO: │
│ ───────────────────────────────────────────────────────────────────── │
│ • Create separate namespaces for each environment │
│ • Use consistent naming conventions │
│ • Set ResourceQuotas for all namespaces │
│ • Use LimitRanges to enforce resource limits │
│ • Apply RBAC policies per namespace │
│ • Use NetworkPolicies to restrict traffic │
│ │
│ ✗ DON'T: │
│ ───────────────────────────────────────────────────────────────────── │
│ • Don't use default namespace for production │
│ • Don't skip quotas - they prevent resource exhaustion │
│ • Don't allow all traffic between namespaces without consideration │
│ │
│ Recommended Namespace Structure: │
│ ──────────────────────────────── │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ kubernetes.io/metadata.name: default │ │
│ │ ├── production │ │
│ │ ├── staging │ │
│ │ ├── development │ │
│ │ ├── kube-system (system) │ │
│ │ └── monitoring (for monitoring tools) │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘

In this hands-on lab, we’ll create and manage namespaces.

  • A running Kubernetes cluster
Terminal window
# Step 1: Create namespaces
kubectl create namespace development
kubectl create namespace staging
# Step 2: List namespaces
kubectl get namespaces
# Step 3: Create a ResourceQuota
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: development
spec:
hard:
pods: "10"
requests.cpu: "2"
requests.memory: 4Gi
EOF
# Step 4: View quota
kubectl get resourcequota -n development
# Step 5: Create a LimitRange
kubectl apply -f - <<EOF
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
namespace: development
spec:
limits:
- default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 200m
memory: 256Mi
max:
cpu: "2"
memory: 2Gi
min:
cpu: 50m
memory: 64Mi
type: Container
EOF
# Step 6: Deploy to specific namespace
kubectl create deployment nginx --image=nginx -n development
# Step 7: Switch default namespace
kubectl config set-context --current --namespace=development
# Step 8: Clean up
kubectl delete namespace development staging

  1. Namespaces - Logical isolation for resources
  2. ResourceQuotas - Limit total resources per namespace
  3. LimitRanges - Set defaults and limits for containers
  4. RBAC - Access control per namespace
  5. NetworkPolicies - Traffic isolation
Terminal window
# Create namespace
kubectl create namespace my-namespace
# Get resources in namespace
kubectl get pods -n my-namespace
# Switch namespace
kubectl config set-context --current --namespace=my-namespace
# Apply quota
kubectl apply -f quota.yaml -n my-namespace
# Apply limit range
kubectl apply -f limitrange.yaml -n my-namespace

In the next chapter, we’ll explore Kubernetes Labels and Selectors (Chapter 25), covering:

  • Label syntax and usage
  • Label selectors
  • Annotations