Before Kubernetes 1.7, admission controllers were compiled with Kubernetes API server, so they could only be configured before the API server started. Dynamic admission control aimed to break this limitation. There are two methods to implement custom dynamic admission control: via initializer and admission webhooks. The Initializer webhook can watch an uninitialized workload and check whether it needs to take any action against it.

The Admission webhook intercepts the request and checks the preset rules from its configuration before deciding whether the requests are allowed or not. Both the initializer and admission webhooks can admit and mutate the resource request on certain operations, so we can leverage them to force policies or validate whether the requests fulfill the requirement of your organization. Buggy initializer and admission webhooks might block all the target resources from being created. However, the Admission webhook provides a failure policy, which can address when the webhook server doesn't respond as expected. 

At the time of writing this book, the admission webhook has been promoted to beta, but the Initializer is still alpha. In this section, we'll implement a simple Admission webhook controller, which will verify whether the {"chapter": "5"} annotation is set to the podSpec during pod creation. The request will go through if the annotation is set. If not, the request will fail.