Kubectl Demystified
Trace a command end to end — from kubeconfig to etcd and back
$ kubectl get podsGET /api/v1/namespaces/default/pods?limit=500Read path — admission and the etcd write are skipped. The list is served from cache or etcd.
Request inspector
What happens when you run kubectl?
kubectl looks like magic: you type a command and objects appear or change. Under the hood it is a thin REST client. Every command resolves your kubeconfig, builds an HTTPS request, and hands it to the API server, which runs it through a fixed pipeline before touching storage. Use the Play button above to watch a request flow through every stage — or click any stage to jump straight to it.
The whole trick: kubectl never talks to etcd, kubelet, or a node.
It only ever speaks HTTPS to one endpoint — the API server (`cluster.server` from your kubeconfig). Everything else (scheduling, starting containers, persistence) happens after the API server accepts your request and other components react to the change.
The seven stages
- 1
kubeconfig— kubectl finds your config, context, server URL and credentials - 2
Request + TLS— The command becomes a REST call over a mutually-authenticated TLS connection - 3
authn— The API server confirms who you are - 4
authz— RBAC decides whether you are allowed - 5
admission— Writes only: controllers mutate then validate the object - 6
etcd— Reads hit the watch cache; writes are committed to etcd - 7
response— The object comes back and kubectl prints it
Read · kubectl get pods
A read. Nothing is created — the API server returns existing objects.
GET /api/v1/namespaces/default/pods?limit=500
Write · kubectl run nginx --image=nginx
A write. The object is mutated by admission, validated, then persisted to etcd.
POST /api/v1/namespaces/default/pods
Toggle Read / Write at the top to switch the example. The write path adds the admission stage and turns the etcd step into a real persisted write — watch the pipeline change.