In Kubernetes, What Happens when an API Server or Admission Controller Receives a kubectl Command and Updates etcd?

Problem scenario
You know that an admission controller in the API server has various stages to process a kubectl command in Kubernetes. You want to know how the API server or relevant admission controller works in the correct sequence. The sequence starts with a request (HTTP POST from a kubectl command) and ends with updating etcd. How does this happen in detail?

The API server's process of handling a kubectl command is very similar to what are called "admission controller phases."*

It is not clear what is the difference (if there is any).

In pure text, the successful process is as follows:

1) a kubectl command is run
2) an HTTP POST request is made to the API server
3) the API server receives the request and handles it
4) an authentication plugin receives the request and passes it on
5) an authorization plugin receives the request and passes it on
6) an admission control plugin receives the request and passes it on
7) object schema validation is done
8) a validating admission control phase may happen that could involve an external validating webook (possible step, but could be bypassed). No changes can happen at this stage; either acceptance or rejection could happen here*.
9) the changes are saved in the "distributed persistent storage" (page 310 of Kubernetes in Action) system (etcd).
10) a response is returned to the client terminal that ran the original kubectl command.

The above steps were adapted from page 316 (most of the above steps) and 318 (#10) of Kubernetes in Action and this external website (several steps were corroborated or borrowed).

* This external article refers to "admission controller phases."

Leave a comment

Your email address will not be published. Required fields are marked *