The API server
The only front door, and the lifecycle of one request.
In plain terms
The API server is the front desk of a building. Everyone checks in there: they show ID (authentication), get told where they’re allowed to go (authorization), and only then are let in. Nothing reaches the vault (etcd) except through the desk.
Every other component talks to the API server, and nothing talks directly to etcd. It is the single front door, and every request runs the same four steps: authenticate, authorize, admit, persist. That pipeline is the key to both administration and troubleshooting.
The error names the gate: 401 is authentication, 403 is authorization, and a policy message is admission.
Because it is the only writer to etcd, the API server is also the only place to enforce policy — which is why admission controllers, the third gate, are where quotas, defaults, and security policy live.
terminal
$ kubectl get --raw='/livez?verbose'[+]ping ok[+]etcd ok[+]poststarthook/rbac/bootstrap-roles oklivez check passed# on a kubeadm node, the apiserver is a static pod:$ sudo grep -- --enable-admission-plugins \/etc/kubernetes/manifests/kube-apiserver.yaml
The API server is a static pod
A typo in kube-apiserver.yaml and it will not restart — and when it is down, kubectl is down. Back the file up before editing, and validate carefully.