A cluster without organization becomes a condominium without rules: anyone occupies the hall, nobody knows whose door is whose, and on maintenance day, nobody can evacuate the building without knocking everyone down.

Namespaces, labels, quotas, and PDB are the condominium rules. They are not bureaucracy: they are what allows operating with predictability.

Course seal: tested on Kubernetes 1.35.

Namespaces

A namespace is a logical scope. It separates names, RBAC, quotas, and network policies. It is not security isolation by itself — but it is the foundation for organization.

Namespaces you already have:

• default: where everything falls if you don't choose.
• kube-system: cluster components.
• kube-public, kube-node-lease: internal use.
• monitoring, ingress-nginx, argocd, velero: operators and platform.

For an application, create something like:

kubectl create namespace portal
kubectl config set-context --current --namespace=portal

Caution: kubectl delete namespace deletes everything inside. Treat namespace as a lifecycle unit.

Labels, annotations and selectors

Labels are for selecting. Annotations are for metadata that do not select (owner, link, changelog, checksum).

Recommended labels:

metadata:
  labels:
    app.kubernetes.io/name: portal
    app.kubernetes.io/instance: prod
    app.kubernetes.io/version: "1.4.2"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: itsm
    app.kubernetes.io/managed-by: helm

Selectors use labels:

kubectl get pods -l app.kubernetes.io/name=portal
kubectl delete pods -l app.kubernetes.io/component=backend

The classic mistake: the selector of the Deployment does not match template.metadata.labels. The Deployment cannot find the pods and the rollout gets weird.

ResourceQuota: the namespace ceiling

Without quota, a team can create 200 pods and bring down the cluster. With quota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: portal-quota
  namespace: portal
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"
    services: "10"
    persistentvolumeclaims: "10"

Check:

kubectl -n portal describe resourcequota portal-quota

If the sum of pods exceeds the quota, new pods are rejected. That's good: it fails early, in the namespace, instead of taking down the node.

LimitRange: the default of each pod

Quota is the namespace ceiling. LimitRange defines defaults and limits per pod:

apiVersion: v1
kind: LimitRange
metadata:
  name: portal-limits
  namespace: portal
spec:
  limits:
    - type: Container
      default:
        cpu: 200m
        memory: 256Mi
      defaultRequest:
        cpu: 50m
        memory: 64Mi
      max:
        cpu: "2"
        memory: 2Gi
      min:
        cpu: 10m
        memory: 32Mi

Without requests/limits, the pod is BestEffort and is the first to be evicted under pressure. With equal requests/limits, it becomes Guaranteed. The middle ground is Burstable.

QoS	When it happens	Risk
Guaranteed	requests = limits for all containers	lowest eviction risk
Burstable	requests < limits	moderate risk
BestEffort	without requests/limits	first to be evicted

PDB: protecting maintenance

PodDisruptionBudget limits voluntary disruptions (drain, eviction), not node failures.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: portal-backend-pdb
  namespace: portal
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: portal
      app.kubernetes.io/component: backend

With 3 replicas and minAvailable: 2, the drain can remove 1 at a time. With minAvailable: 3, the drain blocks forever — and you discover that at the worst possible time.

Alternative:

spec:
  maxUnavailable: 1

maxUnavailable is usually easier to reason about when you scale.

What the PDB does not do

• Does not prevent kubectl delete pod (it is not an eviction).
• Does not prevent node failure (it is not a voluntary disruption).
• Does not create replicas.
• Does not save an application with 1 replica: minAvailable: 1 blocks any drain.

Laboratory

kubectl create ns demo
kubectl -n demo create deployment web --image=nginx:1.27 --replicas=3
kubectl -n demo get pods -l app=web

Apply quota/limitrange (above) and try to create 40 pods:

kubectl -n demo scale deployment/web --replicas=40
kubectl -n demo get pods
kubectl -n demo describe resourcequota

Create the PDB and simulate a drain on a lab node:

kubectl drain <worker> --ignore-daemonsets --delete-emptydir-data

With minAvailable: 2 and 3 replicas on different nodes, it evacuates one at a time. If all 3 are on the same node, the drain blocks — and the lesson is: PDB without anti-affinity is half protection.

Common errors

Symptom	Cause
exceeded quota	sum of requests/limits exceeded the ceiling
Pod rejected by LimitRange	request below min or above max
Drain stuck	PDB minAvailable equal to number of replicas
Unexpected eviction	BestEffort pod under pressure
Selector does not find pods	different labels between selector and template

Checklist

• [ ] Dedicated namespace per application/environment.
• [ ] Standardized labels (app.kubernetes.io/*).
• [ ] ResourceQuota and LimitRange defined.
• [ ] Requests/limits on all containers.
• [ ] PDB on critical workloads.
• [ ] Anti-affinity/topology spread for the PDB to make sense.
• [ ] I know that PDB does not protect against node failure.

Glossary

• namespace: logical scope of names and policies.
• label: key/value pair used by selectors.
• annotation: non-selectable metadata.
• ResourceQuota: aggregate namespace ceiling.
• LimitRange: defaults/limits per pod.
• PDB: budget for voluntary disruptions.

Next

Now that the cluster is organized, let's choose the right workload: Deployment, StatefulSet, DaemonSet, Job, or CronJob.

Next: Kubernetes Course 08 — Deployments, StatefulSets, DaemonSets, and Jobs