Kubectl Create Namespace 2026: Complete Guide to Kubernetes Namespaces

Kubectl create namespace is your first step in organizing Kubernetes resources. Namespaces provide logical isolation for workloads, enabling multi-tenancy, access control, and resource management. This guide covers everything you need to know about Kubernetes namespaces in 2026.

Quick Reference: Kubectl Namespace Commands

Command	Description
`kubectl create namespace dev`	Create namespace
`kubectl get namespaces`	List all namespaces
`kubectl delete namespace dev`	Delete namespace
`kubectl config set-context --current --namespace=dev`	Set default namespace
`kubectl get all -n dev`	Get resources in namespace
`kubectl apply -f ns.yaml`	Create from YAML

What Are Kubernetes Namespaces?

Namespaces are virtual clusters within a physical Kubernetes cluster. They provide:

Resource isolation - Separate environments (dev, staging, prod)
Access control - RBAC policies per namespace
Resource quotas - Limit CPU, memory, storage per team
Network policies - Control traffic between namespaces

Default Namespaces

Namespace	Purpose
`default`	Default for resources without namespace
`kube-system`	Kubernetes system components
`kube-public`	Publicly readable resources
`kube-node-lease`	Node heartbeat data

Creating Namespaces

Using kubectl create

# Create namespace
kubectl create namespace development

# Create with short form
kubectl create ns staging

# Create in dry-run mode (preview)
kubectl create namespace production --dry-run=client -o yaml

Using YAML Manifest

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: production
    team: platform

kubectl apply -f namespace.yaml

With Labels and Annotations

apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: dev
    team: backend
    cost-center: engineering
  annotations:
    description: "Development environment for backend team"
    owner: "backend-team@company.com"

Namespace Naming Conventions

Best Practices

# Good: descriptive, lowercase, hyphens
kubectl create namespace backend-services
kubectl create namespace frontend-prod
kubectl create namespace data-pipeline

# Bad: uppercase, underscores, generic
kubectl create namespace Backend_Services  # Invalid
kubectl create namespace myns              # Too generic

Naming Patterns

Pattern	Example	Use Case
`<team>-<env>`	`backend-prod`	Team-based isolation
`<app>-<env>`	`api-staging`	App-based isolation
`<project>-<component>`	`ecommerce-payments`	Project-based
`<env>`	`production`	Environment-based

Reserved Prefixes

Avoid kube- prefix (reserved for Kubernetes system):

# Don't do this
kubectl create namespace kube-custom  # May conflict

Working with Namespaces

List Namespaces

# List all namespaces
kubectl get namespaces
kubectl get ns

# With labels
kubectl get ns --show-labels

# JSON output
kubectl get ns -o json

Set Default Namespace

# Set default for current context
kubectl config set-context --current --namespace=development

# Verify current namespace
kubectl config view --minify | grep namespace

# Create alias for quick switching
alias kn='kubectl config set-context --current --namespace'
kn production

Delete Namespace

# Delete namespace (and all resources within!)
kubectl delete namespace development

# Force delete stuck namespace
kubectl delete namespace stuck-ns --force --grace-period=0

Warning: Deleting a namespace removes ALL resources within it permanently.

Resource Quotas

Limit resources per namespace to prevent overconsumption.

Create Resource Quota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    services: "10"
    secrets: "20"
    configmaps: "20"
    persistentvolumeclaims: "10"
    requests.storage: 100Gi

View Quota Usage

kubectl get resourcequota -n development
kubectl describe resourcequota team-quota -n development

Output:

Name:                   team-quota
Namespace:              development
Resource                Used   Hard
--------                ----   ----
limits.cpu              4      20
limits.memory           8Gi    40Gi
pods                    12     50
requests.cpu            2      10
requests.memory         4Gi    20Gi

Limit Ranges

Set default and maximum resource limits for containers.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: development
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      max:
        cpu: "2"
        memory: "4Gi"
      min:
        cpu: "50m"
        memory: "64Mi"
    - type: PersistentVolumeClaim
      max:
        storage: 50Gi
      min:
        storage: 1Gi

RBAC for Namespaces

Control access with Role-Based Access Control.

Namespace-Scoped Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: development
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]
  - apiGroups: [""]
    resources: ["pods/log", "pods/exec"]
    verbs: ["get", "create"]

Bind Role to User

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
  - kind: User
    name: jane@company.com
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

View-Only Access

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: viewer
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["*"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["*"]
    verbs: ["get", "list", "watch"]

Network Policies

Control traffic between namespaces.

Default Deny All Traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Allow Traffic Within Namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
        - podSelector: {}

Allow Traffic from Specific Namespace

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

Multi-Tenancy Patterns

Pattern 1: Environment-Based

kubectl create namespace development
kubectl create namespace staging
kubectl create namespace production

Pattern 2: Team-Based

kubectl create namespace team-backend
kubectl create namespace team-frontend
kubectl create namespace team-data

Pattern 3: Application-Based

kubectl create namespace app-ecommerce
kubectl create namespace app-analytics
kubectl create namespace app-auth

Pattern 4: Combined

kubectl create namespace backend-prod
kubectl create namespace backend-staging
kubectl create namespace frontend-prod
kubectl create namespace frontend-staging

Complete Namespace Setup

Production Namespace with All Controls

---
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: production
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "100"
    requests.memory: 200Gi
    limits.cpu: "200"
    limits.memory: 400Gi
    pods: "200"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: production-limits
  namespace: production
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Best Practices

1. Avoid the Default Namespace

# Bad
kubectl apply -f deployment.yaml  # Goes to default

# Good
kubectl apply -f deployment.yaml -n production

2. Use Labels Consistently

metadata:
  labels:
    environment: production
    team: platform
    cost-center: infrastructure

3. Implement Resource Quotas

Always set quotas for shared clusters to prevent resource hogging.

4. Apply Network Policies

Start with default-deny and explicitly allow required traffic.

5. Use Pod Security Standards

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted

6. Document Namespace Ownership

metadata:
  annotations:
    owner: "platform-team@company.com"
    slack-channel: "#platform-alerts"

Troubleshooting

Namespace Stuck in Terminating

# Check finalizers
kubectl get namespace stuck-ns -o json | jq '.spec.finalizers'

# Remove finalizers
kubectl patch namespace stuck-ns -p '{"spec":{"finalizers":[]}}' --type=merge

Can’t Create Resources in Namespace

# Check quota
kubectl describe resourcequota -n development

# Check limit range
kubectl describe limitrange -n development

# Check RBAC
kubectl auth can-i create pods -n development

Conclusion

Kubectl create namespace is fundamental to organizing Kubernetes clusters in 2026. Key takeaways:

Use namespaces for logical isolation (environments, teams, apps)
Implement resource quotas to prevent overconsumption
Apply RBAC for access control
Use network policies for traffic isolation
Avoid the default namespace in production
Label namespaces consistently for organization

Master namespaces to build secure, organized, and scalable Kubernetes environments.

Need help with Kubernetes architecture? Book a free 30-minute consultation with our experts.

Quick Reference: Kubectl Namespace Commands

What Are Kubernetes Namespaces?

Default Namespaces

Creating Namespaces

Using kubectl create

Using YAML Manifest

With Labels and Annotations

Namespace Naming Conventions

Best Practices

Naming Patterns

Reserved Prefixes

Working with Namespaces

List Namespaces

Set Default Namespace

Delete Namespace

Resource Quotas

Create Resource Quota

View Quota Usage

Limit Ranges

RBAC for Namespaces

Namespace-Scoped Role

Bind Role to User

View-Only Access

Network Policies

Default Deny All Traffic

Allow Traffic Within Namespace

Allow Traffic from Specific Namespace

Multi-Tenancy Patterns

Pattern 1: Environment-Based

Pattern 2: Team-Based

Pattern 3: Application-Based

Pattern 4: Combined

Complete Namespace Setup

Production Namespace with All Controls

Best Practices

1. Avoid the Default Namespace

2. Use Labels Consistently

3. Implement Resource Quotas

4. Apply Network Policies

5. Use Pod Security Standards

6. Document Namespace Ownership

Troubleshooting

Namespace Stuck in Terminating

Can’t Create Resources in Namespace

Conclusion

Related Resources

Related Articles

Kubectl Restart Deployment 2026: Complete Guide to Restarting Kubernetes Deployments

Kubectl Restart Pod 2026: 5 Methods to Restart Kubernetes Pods

Kubectl Port Forward 2026: Complete Guide to Kubernetes Port Forwarding

Don't Miss Out on Expert DevOps Insights

Get Started

You're In!

Tasrie IT Support

Start a conversation