Kubernetes Namespace Lifecycle Management

Kubernetes Namespace Lifecycle Management is the end-to-end operational process surrounding a namespace's existence within an organization — provisioning it with its full complement of governance objects when a new team or application onboards, maintaining it through active use, and deliberately decommissioning it when it is no longer needed — treated as a repeatable workflow rather than a single ad hoc kubectl create namespace command. Where namespace object management covers the mechanics of the Namespace API object itself, lifecycle management covers the surrounding process: what else needs to happen alongside namespace creation for it to be genuinely ready for use, and what disciplined decommissioning looks like once a namespace has served its purpose.

Because a bare namespace provides only name-uniqueness scoping without any of the governance guarantees (RBAC, quota, network policy) that make it safe and useful in a shared cluster, lifecycle management is largely about ensuring these accompanying objects are provisioned and retired consistently, not left to individual, ad hoc judgment each time.

Onboarding: Provisioning a New Namespace

Bundling Namespace Creation with Required Governance Objects

Rather than creating a bare namespace and adding governance objects piecemeal afterward, mature lifecycle processes provision a namespace together with its ResourceQuota, LimitRange, default NetworkPolicy, and initial RBAC RoleBindings as a single, atomic bundle — commonly implemented as a Helm chart, a Kustomize base, or a dedicated internal tool/operator that takes minimal input (team name, environment, initial quota size) and generates the complete set of objects.

# A representative bundle, applied together
apiVersion: v1
kind: Namespace
metadata:
  name: codartium-new-team
  labels:
    team: new-team
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: default-quota
  namespace: codartium-new-team
spec:
  hard:
    requests.cpu: "5"
    requests.memory: "10Gi"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-access
  namespace: codartium-new-team
subjects:
  - kind: Group
    name: new-team-members
roleRef:
  kind: ClusterRole
  name: edit

GitOps-Driven Provisioning

Many organizations manage the full namespace-provisioning bundle through a GitOps workflow — a pull request adding a new namespace directory to a repository, reviewed and merged before a GitOps controller (Argo CD, Flux) applies it to the cluster — giving an auditable history of exactly when and why each namespace was created, and what governance configuration accompanied it from day one.

Active Lifecycle: Ongoing Maintenance

Periodic Governance Review

As covered in resource review practice, an active namespace's quota, LimitRange, and RBAC bindings warrant periodic revisiting as the team or application's needs evolve — lifecycle management treats this as an expected, recurring part of a namespace's active existence, not a one-time setup step.

Tracking Ownership Over Time

Namespace metadata (labels, annotations) recording the current owning team or contact should be kept up to date as organizational changes occur (team reorganizations, ownership transfers) — a namespace whose recorded owner no longer matches reality complicates both governance review and incident response.

metadata:
  annotations:
    codartium.io/owner-team: "new-team"
    codartium.io/last-reviewed: "2026-06-01"

Decommissioning: Retiring a Namespace

Confirming No Active Dependencies Before Deletion

Because namespace deletion cascades to remove every contained resource, a deliberate decommissioning process confirms no other namespace or system still depends on resources within the target namespace (a Service other workloads call, a Secret referenced cross-namespace via some non-standard mechanism) before proceeding.

kubectl get pods -n codartium-old-team
kubectl get networkpolicy -n codartium-old-team

Archiving Before Deletion

For namespaces whose contents have any lasting value (configuration worth preserving as a historical record, logs not yet fully exported), exporting a snapshot of key manifests before deletion is a common safeguard, since namespace deletion is not easily reversible.

kubectl get all,configmaps,secrets -n codartium-old-team -o yaml > codartium-old-team-archive.yaml

Executing Deletion Through the Same Governed Process

Just as provisioning is typically routed through a reviewed, auditable process (a GitOps pull request), decommissioning is best handled the same way — removing the namespace's directory from the GitOps repository and letting the controller reconcile its deletion, rather than an out-of-band manual kubectl delete namespace that bypasses the review and audit trail applied to creation.

Example

# Onboarding
kubectl apply -f namespace-bundle/codartium-new-team/

# Periodic review
kubectl describe resourcequota -n codartium-new-team

# Decommissioning
kubectl get all -n codartium-old-team -o yaml > archive.yaml
kubectl delete namespace codartium-old-team