Kubernetes Administration: kubectl, RBAC, Namespaces, and Resource Quotas

kubectl is the command-line client for the Kubernetes API. Every command you type - kubectl get pods, kubectl apply, kubectl delete - is translated into an HTTPS request to the kube-apiserver. kubectl never connects to nodes, the kubelet, or etcd directly; the API server authenticates the request, checks authorization (RBAC), validates it, and acts on the cluster state. This single-entry-point design is why access control, auditing, and validation can all live in one place.

kubectl finds the cluster through a kubeconfig file, by default at ~/.kube/config. A kubeconfig holds three kinds of entries: clusters (API server addresses and certificate data), users (credentials), and contexts, which pair a cluster with a user and optionally a default namespace. Switching contexts with kubectl config use-context is how one workstation manages several clusters, and it is the answer the exam expects when a question mentions working with multiple clusters from one machine.

The everyday verbs are worth recognizing on sight: kubectl get lists objects, kubectl describe shows detailed state plus recent events (the first stop when debugging), kubectl logs prints a container's output, kubectl exec runs a command inside a running container, and kubectl explain documents the fields of any resource type. Flags follow a consistent pattern: -n selects a namespace, -A spans all namespaces, -l filters by label selector, and -o yaml or -o wide change the output format. You will not be asked to compose complex commands on the KCNA, but you will be asked what a given command does.

You have met the components as architecture; an administrator meets them as failure domains. Each component owns one job, so each has a characteristic symptom when it is unhealthy, and exam questions often describe the symptom and ask for the component.

Two administrative facts round this out. First, cluster state lives in etcd, so backing up etcd is the canonical way to back up a cluster, and etcd should run with an odd number of members so it can keep quorum. Second, in managed clusters (EKS, AKS, GKE) the provider runs the control plane, so an administrator's hands-on scope narrows to worker nodes, workloads, and the API - one reason the exam favors conceptual questions over operational ones.

A quick health picture comes from commands like kubectl get nodes, kubectl get pods -n kube-system, and kubectl describe node NODE_NAME - reading conditions and events rather than logging into machines.

There are two styles of driving the API, and KCNA expects you to tell them apart. Imperative commands state an action: kubectl create deployment web --image=nginx, kubectl run tmp --image=busybox, kubectl scale deployment web --replicas=5, kubectl expose deployment web --port=80. They are quick for experiments, but the resulting configuration exists only in the live cluster - there is no file to review, version, or reapply.

Declarative management states a destination: you keep manifests in files and run kubectl apply -f manifest.yaml (or -f a whole directory). Apply creates the object if it is missing and updates it if it drifted, so the same command is safe to run repeatedly - it is idempotent. Because the manifests are plain files, they can live in Git, go through code review, and be applied by automation; this is the foundation of the GitOps pattern of cluster management.

A common exam stem describes a team storing YAML in a repository and asks which command keeps the cluster matching it: the answer is kubectl apply. Another gives kubectl create failing with an already-exists error and asks why apply would not: because apply computes and patches the difference instead of insisting on creating something new. Imperative commands still have one declarative trick worth knowing: --dry-run=client -o yaml prints the manifest an imperative command would create, which is a fast way to scaffold a file you then manage with apply.

Role-Based Access Control (RBAC) is how Kubernetes decides who may do what. It is built from exactly four API objects, in two pairs. A Role is a named list of permissions that applies within a single namespace. A ClusterRole is the same idea without the namespace boundary: it can grant access across all namespaces, or to cluster-scoped resources such as nodes and PersistentVolumes that no namespaced Role could ever cover. Neither object names any people - roles define what can be done, not who can do it.

Bindings supply the who. A RoleBinding grants the permissions of a role to a set of subjects within one namespace; a ClusterRoleBinding grants a ClusterRole's permissions across the entire cluster. One combination surprises people and is beloved by exam writers: a RoleBinding may reference a ClusterRole, which grants that ClusterRole's permissions only inside the binding's namespace. This lets administrators define a permission set once (say, a generic developer ClusterRole) and bind it per namespace, instead of copying identical Roles everywhere.

Two properties define RBAC's character. It is additive and allow-only: there are no deny rules, permissions accumulate across bindings, and anything not explicitly granted is forbidden. And it defaults closed, which makes least privilege the natural practice: start from nothing and grant only the verbs and resources a subject genuinely needs.

Every RBAC rule answers three questions: who (the subject), may do what (the verbs), to which objects (the resources). Subjects come in three kinds: Users and Groups, which represent humans and are not Kubernetes API objects (they come from certificates or an external identity provider - there is no kubectl create user), and ServiceAccounts, which are API objects and represent workloads. Every namespace has a default ServiceAccount, every Pod runs as some ServiceAccount, and a Pod that needs to call the API should get its own ServiceAccount bound to a narrowly scoped Role.

Verbs are the actions the API server recognizes: get, list, and watch for reading; create, update, patch, and delete for writing. Resources are the object types the verbs act on - pods, deployments, services, secrets - optionally narrowed by API group. A Role that lets its holder read Pods in the dev namespace looks like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

A RoleBinding then attaches it to a subject - a user, a group, or a ServiceAccount such as system:serviceaccount:dev:ci-bot. To check the outcome, administrators use kubectl auth can-i, for example kubectl auth can-i list pods -n dev, or with --as to test another subject's permissions. For the exam, be ready to read a Role like the one above and state what it permits, and remember the human/workload split: ServiceAccounts for Pods, users and groups for people.

For an administrator, a namespace is the unit of tenancy: the boundary at which access is granted, quotas are enforced, and blast radius is contained. Object names must be unique only within their namespace, so multiple teams can use the same conventional names side by side. Policy objects attach at the same seam - a RoleBinding grants access within its namespace, and a ResourceQuota caps consumption within its namespace - so putting each team or environment in its own namespace gives each a private naming scope with tailored permissions and limits.

Not everything lives inside a namespace. Namespaced resources include Pods, Deployments, Services, ConfigMaps, Secrets, Roles, and RoleBindings. Cluster-scoped resources include Nodes, PersistentVolumes, ClusterRoles, ClusterRoleBindings, and namespaces themselves. You can ask the API which is which: kubectl api-resources --namespaced=true and --namespaced=false. This split is exactly why ClusterRoles exist - no namespaced Role could grant access to a Node.

Day to day, you select a namespace per command with -n, span all of them with -A, or set a default in your kubeconfig context with kubectl config set-context --current --namespace=dev. Deleting a namespace deletes everything in it, which makes namespaces convenient for disposable environments and dangerous to delete casually.

Know the limits of the boundary. Namespaces isolate names, access, and quota accounting - they do not isolate the network. By default any Pod can reach any Pod in any namespace; restricting that requires NetworkPolicies. Nor do namespaces isolate node resources: workloads from every namespace share the same machines, which is precisely the problem quotas address next.

A ResourceQuota caps the total consumption of a namespace. It can limit aggregate compute - the sum of CPU and memory requests and limits across all Pods - and object counts, such as the number of Pods, Services, or PersistentVolumeClaims. When creating an object would push the namespace past its quota, the API server rejects the request at admission time. A LimitRange works at the opposite altitude: it constrains individual containers or Pods in the namespace, setting default requests and limits for containers that do not declare their own, plus minimums and maximums for those that do.

The two are designed to work together, and a classic scenario shows why. An administrator gives the team-a namespace a ResourceQuota of 10 CPU and 20Gi of memory in total requests. Quotas on compute have a sharp edge: once a quota constrains CPU or memory, every new Pod must declare requests or limits for those resources, or the API server rejects it. A developer's minimal manifest with no resources section suddenly fails to create. The fix is a LimitRange in the same namespace that injects default requests and limits into any container that omits them - now plain manifests work again, every Pod is accounted against the quota, and no single container can request more than the LimitRange maximum.

Keep the division of labor straight, because the exam tests it directly: quota is the namespace's total budget, LimitRange is the per-container guardrail and default-setter. Both are namespaced objects enforced by the API server at admission, not at runtime - they shape what can be created, while the scheduler and kubelet deal with what actually runs. And remember what requests and limits themselves mean: a request is the amount the scheduler reserves when placing a Pod; a limit is the ceiling enforced on the running container.