Namespaces & Resource Management

Chapter 9 covered getting traffic into the cluster. This chapter turns inward: how a cluster's own resources — CPU, memory, and organizational structure — are shared fairly across many workloads sitting on the same physical hardware.

Namespaces, Properly Explained

Revisiting Chapter 4's brief mention in full: a namespace is a logical partition within one cluster — not a separate cluster. Used to separate teams, environments, or projects sharing infrastructure. Dev/staging/prod as three namespaces within one cluster is common, though many organizations use fully separate clusters per environment instead — both patterns genuinely exist in practice, echoing cloud1-1's own honest hybrid/multi-environment framing. Resource names must be unique within a namespace, not cluster-wide. RBAC (Course 2's k8s2-4 covers this fully) is commonly scoped per namespace, letting different teams have appropriately restricted access to only their own namespace's resources — a genuinely practical reason namespaces matter beyond simple tidiness.

Cluster-Scoped vs. Namespace-Scoped Resources

Most resources covered so far — Pods, Deployments, Services, ConfigMaps, Secrets, PVCs — are namespace-scoped. Some are cluster-scoped instead: Nodes, PersistentVolumes themselves (distinct from PVCs), and Namespaces themselves. Genuinely useful to know which is which: kubectl get pods needs a namespace context; kubectl get nodes doesn't, and never will, regardless of any namespace flag.

Why Resource Requests & Limits Matter

Multiple pods from different teams and applications share the same physical node's finite CPU and memory. Without any constraints, one poorly-behaved or unexpectedly busy pod could consume all available resources on a node, starving every other pod scheduled there — a genuinely real, common operational problem.

Requests — What the Scheduler Uses

A request is the amount of CPU/memory a container is guaranteed to get, and specifically what Chapter 2's scheduler uses when deciding which node has enough available capacity to place a pod on. Setting requests accurately matters: too low and the scheduler might overpack a node; too high and capacity — and cost — is wasted unnecessarily, echoing cloud1-9's own oversized-compute cost material, just at the container level rather than the whole-VM level.

Limits — The Hard Ceiling

A limit is the maximum a container is allowed to use, enforced by the container runtime. Exceeding a memory limit results in the container being OOM-killed — the same OOM-kill pattern briefly named in Cloud Platforms' own cloud2-5, explained properly here at the Kubernetes level. Exceeding a CPU limit doesn't kill the container — it's throttled instead.

A Concrete Example — Requests & Limits in a Pod Spec

CPU is measured in millicores — "500m" means half a CPU core. Memory uses Mi/Gi (mebibytes/gibibytes). The notation itself is a genuinely common source of confusion for newcomers, worth confirming explicitly rather than assuming.

Quality of Service (QoS) Classes, Briefly

Worth knowing this classification exists — it explains why some pods get evicted before others during real resource pressure, genuinely relevant troubleshooting knowledge for Course 2's k8s2-8.

ResourceQuotas — Limiting a Namespace as a Whole

A ResourceQuota object caps the total resource consumption (or object count) allowed within an entire namespace, regardless of individual pod-level requests/limits — a genuinely practical administrative tool for a multi-team cluster, preventing one team's namespace from consuming resources needed by others. Together with per-namespace RBAC, namespaces + quotas + RBAC are how a shared cluster stays fair and secure across multiple teams.

Hands-On Exercises