Production Kubernetes

Chapter 8. Admission Control

We have written many times in this book about the flexible, modular design of Kubernetes being one of its great strengths. Sensible defaults can be replaced, augmented, or built upon to provide alternative or more fully featured experiences for platform consumers. Admission control is one area that particularly benefits from this flexible design goal. Admission control is concerned with validating and mutating requests to the Kubernetes API server before they are persisted in etcd. This ability to intercept objects with fine granularity and control opens up a number of interesting use cases. For example:

• Ensuring that new objects cannot be created in a Namespace that is currently being deleted (in terminating state)

• Enforcing that new Pods are not going to run as the root user

• Making sure that the total sum of memory used by all the Pods in a Namespace does not exceed a user-defined limit

• Ensuring that Ingress rules cannot be overwritten accidentally

• Adding a sidecar container to every Pod (e.g., Istio)

First we’ll take a high-level look at the admission chain, which is the process all requests to the API server go through. Then we’ll move on to cover the in-tree controllers. These are built-in admission controllers that can be enabled and disabled via flags to the API server and enable some of the preceding use cases. Other use cases require more custom implementation and are integrated via a flexible webhook model. We’ll dedicate a lot ...