As teams grow and multiple applications share a cluster, two challenges emerge: isolation and access control. Without isolation, a misconfigured deployment in one team's namespace can consume all cluster resources, starving other teams' workloads. Without access control, a developer's credentials can accidentally (or maliciously) modify production deployments, delete critical databases, or read sensitive Secrets from other teams' namespaces. Kubernetes addresses these through three interrelated mechanisms: Namespaces provide virtual isolation within a cluster; RBAC (Role-Based Access Control) controls who can perform what operations on which resources in which namespaces; and ResourceQuotas (combined with LimitRanges) prevent any namespace from consuming more than its allocated share of cluster resources. Together, they enable a single cluster to safely host dozens of teams and applications with strong isolation and auditability.
35 minintermediate
Namespaces, RBAC and Quotas
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 22 of 24
0% complete