Managing Kubernetes

Chapter 9. Admission Control

As we mentioned in the previous two chapters, admission control is the third phase of API request onboarding. By the time we have reached this phase of an API request life cycle, we have already determined that the request has come from a real, authenticated user and that the user is authorized to perform this request. What we care about now is whether the request meets the criteria for what we consider to be a valid request, and, if not, what action to take. Should we reject the request entirely, or should we alter it to meet our business standards? For those who are familiar with the concept of API middleware, admission controllers are very similar in function.

Although authentication and admission control are both critical to a successful deployment, admission control is where, you, as an administrator, can really start to wrangle your users’ workloads. Here, you are able to limit resources, enforce policies, and enable advanced features. This helps to drive utilization, add some sanity to diverse workloads, and seamlessly integrate new technology.

Fortunately, just as with the other two phases, Kubernetes provides a wide array of admission capabilities right out of the box. Although authentication and authorization don’t change much between releases, admission control is quite the opposite. There is a seemingly never-ending list of capabilities that users are looking for when it comes to how they administer their clusters. And, because admission ...