Kubernetes Namespace Strategy Prompt

You are a senior Kubernetes platform engineer who has organized clusters for multiple teams, multiple environments, multiple apps. You know the namespace patterns and the trade-offs.

I will provide:
- The org structure (teams, envs, apps)
- Current state (single namespace? per-team? per-app?)
- Multi-cluster vs single cluster
- Goal: design / migrate / debug

Your job:

1. **Common patterns**:
   - **Per-team** — `team-platform`, `team-payments`
   - **Per-environment** — `production`, `staging`, `dev` (often combined with team)
   - **Per-app** — `myapp-prod`, `myapp-staging`
   - **Hybrid** — most common: `<team>-<env>` or `<env>-<app>`
2. **For multi-tenant isolation**:
   - Namespace alone doesn't isolate network — need NetworkPolicy
   - RBAC by namespace
   - ResourceQuota per namespace
   - Pod Security Admission level per namespace
3. **For hierarchical namespaces (HNC)**:
   - Parent/child namespaces
   - Inherited RBAC, ResourceQuota
   - Useful for org hierarchies
4. **For per-env separation**:
   - **Same cluster, different namespaces** — cheaper, shared infra
   - **Different clusters per env** — true isolation; more cost
   - Most orgs: same cluster for dev/staging, separate for prod
5. **For naming convention**:
   - Consistent + parseable
   - DNS-compatible (lowercase, hyphens)
   - Include owner / purpose in name
6. **For namespace lifecycle**:
   - Create with required labels (team, owner, env)
   - Templates / GitOps for creation
   - Cleanup unused (decommissioned projects)
7. **For cross-namespace access**:
   - Services accessible via FQDN
   - NetworkPolicy needed for traffic
   - RBAC for API access
8. **For namespace defaults**:
   - LimitRange auto-applied
   - ResourceQuota
   - PSA labels
   - NetworkPolicy defaults (deny ingress, allow egress)

Mark DESTRUCTIVE: deleting namespace (all contents lost), renaming namespace (not supported; recreate + migrate), changing PSA label on running namespace (may block new pods).

---

Org structure: [DESCRIBE]
Current state: [DESCRIBE]
Goal: [design / migrate / debug]

Why this prompt works

Namespace strategy is foundational. Bad strategy is expensive to fix. This prompt walks the patterns.

How to use it

1. Pick consistent pattern.
2. Encode in templates / GitOps.
3. Apply governance per namespace.
4. Document for team onboarding.

Useful commands

# Inventory
kubectl get namespaces --show-labels

# Per-namespace summary
for NS in $(kubectl get ns -o name | cut -d/ -f2); do
    echo "=== $NS ==="
    kubectl get all -n "$NS" --no-headers | wc -l
done

# Find empty namespaces
for NS in $(kubectl get ns -o name | cut -d/ -f2); do
    COUNT=$(kubectl get all -n "$NS" --no-headers 2>/dev/null | wc -l)
    [ "$COUNT" -eq 0 ] && echo "$NS"
done

# HNC (if installed)
kubectl-hns tree
kubectl-hns describe <namespace>

Patterns

Standard namespace creation template

apiVersion: v1
kind: Namespace
metadata:
  name: payments-prod
  labels:
    team: payments
    environment: production
    owner: payments-team@example.com
    cost-center: "12345"
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: payments-prod
spec:
  limits:
  - type: Container
    defaultRequest: { cpu: "100m", memory: "128Mi" }
    default: { cpu: "500m", memory: "512Mi" }
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: payments-prod
spec:
  hard:
    requests.cpu: "50"
    requests.memory: 100Gi
    pods: "100"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments-prod
spec:
  podSelector: {}
  policyTypes: [Ingress]

HNC example

root
├── tenant-a
│   ├── tenant-a-prod
│   └── tenant-a-staging
└── tenant-b
    ├── tenant-b-prod
    └── tenant-b-staging

GitOps-managed namespaces

# In deploy repo: namespaces/payments-prod.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: payments-prod
  labels: { ... }
---
# defaults/limit-ranges.yaml
# (auto-applied via ArgoCD / Flux)

Common findings this catches

• Namespace sprawl (200+ namespaces) → consolidate or HNC.
• Default namespace overloaded → migrate workloads.
• No isolation between teams → NetworkPolicy + RBAC missing.
• Empty namespaces accumulating → cleanup process.
• Inconsistent naming → enforce via admission webhook.
• PSA label tightening blocks deploys → staged rollout.
• Cross-namespace dependencies undocumented → audit.

When to escalate

• Major reorg / migration — stakeholder coordination.
• Multi-cluster vs multi-namespace decision — strategic.
• Compliance / audit requirements — security team.