Namespaces and Resource Limits (Requests/Limits) on One Node

On a single node, a runaway workload has nowhere to go — it competes directly against everything else for the same CPU and memory. Two tools keep the node stable and predictable: namespaces, which separate and organize workloads, and resource requests/limits, which tell the scheduler how much CPU and memory each pod needs or may use. Together they prevent one noisy app from taking the cluster down.

Namespaces: logical separation

Namespaces partition a cluster into virtual clusters. Resources like Deployments and Services are namespaced — they exist inside one namespace and cannot collide with same-named objects elsewhere. This keeps teams and environments tidy on shared infrastructure.

apiVersion: v1
kind: Namespace
metadata:
  name: staging
---
apiVersion: v1
kind: Namespace
metadata:
  name: production

Apply these, then create workloads inside them with the namespace field or the -n flag.

Requests and limits

Requests declare how much CPU and memory a pod is guaranteed (the scheduler uses this for placement). Limits cap how much it may use. On a single node, requests are what prevent overcommit; limits are the safety valve that stops one pod from exhausting memory.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myapi:1.4
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

Enforcing with ResourceQuota

Give the whole namespace a budget so aggregate usage cannot exceed the node.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: prod-quota
  namespace: production
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 2Gi
    limits.cpu: "4"
    limits.memory: 4Gi
    pods: "10"

Once the quota exists, creating a pod that would exceed it is rejected at the API server.

How requests drive scheduling

Inspecting usage and quota

Check what is actually consuming resources and whether anything is near its limit.

kubectl -n production get namespaces
kubectl -n production describe quota prod-quota
kubectl -n production top pods
kubectl -n production get pods --show-labels

The top command requires the metrics server (covered in the observability post); quota and describe work regardless.

Takeaway

Namespaces keep workloads isolated and organized; requests, limits, and ResourceQuota keep them from exhausting the node and each other. On a single-node cluster these are not nice-to-haves — they are the difference between one leaky pod and a downed node. Apply both patterns on a small k3s cluster at Netbay and watch the scheduler refuse overcommit for you — netbayhosts.in.