Customizing and Extending the Kubernetes API with Admission Controllers

Customizing and Extending the Kubernetes API with Admission Controllers


[MUSIC].>>Hey. I’m Brendan and
we’re going to talk about Admission Controllers, how they interact with Kubernetes, and what they can do for you. Well, I wanted to start by
just diagramming out what a request looks like when
it comes into Kubernetes. There’s basically three parts. There’s obviously the person or potentially automation that
is making the API call, that goes to the API server, and that eventually goes
to the etcd database. That’s the basic flow
of all API requests. Now, inside of the API server itself, there is code that does
RBAC for authorization, and it also does authentication. So that allows you to say hey, this user can or can’t do certain
things within the cluster, but there’s a lot of stuff
that you might want to do that involves either modifying or validating an API object that
looks within the API object itself in order to make decisions
or even make modifications, and that’s where admission
controllers come in. So an admission
controller is something that happens after a authn and authz, after a user has been authorized, an admission controller is
called and those are usually web hooks so that you can dynamically register
admission controllers. There are two basic classes
of admission controllers. There are validating
emission controllers, and there are mutating
emission controllers. As you might guess from
the name of validating admission controller
looks at the contents of an API object and make sure
that it’s valid API object. We’ll talk a little bit about
some use cases for that. A mutating admission controller looks at the API object
and actually changes it. So it actually may add things, it may remove things, it actually modifies the
API object on the way in, and we’ll talk about the
use cases for that as well. Let’s take a look at validating
admission controllers first. With validating admission controller, the goal is to ensure some property
for an object is maintained. Generally when we think about this, we think about this in terms
of something like policy. As a concrete example, the gatekeeper open-source project that’s maintained by
Azure and others to build policy for Kubernetes uses a validating admission controller to integrate itself into Kubernetes. Using a policy engine like RegO
from the open policy agent folks, you can actually say things
like I want every replica set must have at
least three replicas. That’s something that
you can’t express with authorization or authentication, but it is something that you
can express with policy. Obviously this is because you want to make sure
that someone is doing a good job replicating their
application for reliability. You could also say something like every object in my Kubernetes
cluster has to have an annotation that is the e-mail
of the owner of that resource. This becomes really
valuable when you’re building automation to
for example reminds someone that they may have
a resource that needs to be deleted or a resource
that is having a problem. Having this standardized metadata in your system makes it much
easier to build automation, and really the only way
to make sure that people do that is through policy so that if they don’t and they don’t include that in
the request over here, that request is rejected. So obviously building
an admission controller can be a complicated thing to do. So the great thing about
projects like gatekeepers, they integrate with admission
control automatically for you, you just need to install
them in your cluster. But eventually over time, you may choose to build your own validating admission
controller as well. Let’s talk a little bit about
mutating and mission controllers. The goals behind a
mutating emission control are actually a little bit different, they’re to actually
change the API object to enable some defaulting
or to add capabilities. So a classic example of a mutating admission controller
would be to say, “Hey, we’re going to add
default CPU limits.” When someone creates a pod, they don’t supply a
set of resources in terms of CPU and memory
that that pod needs, we’re going to actually set
some defaults for them. Maybe we’ll set the
default request at one core and two gigs of memory, and that’s just to ensure that
the user has a good time. Because if you create a pod and
you don’t specify resource limits, generally speaking
Kubernetes will totally overpack and overload the cluster, things will start crashing, applications won’t work properly. So with a mutating
admission controller, we help a user find the
happy path instead of leading themselves down a
place where they’re going to actually do damage to their
application and to their users. Another popular example of a mutating admission
controller is a service mesh. Now, service mesh usually involves a some sidecar container that
lives next to your app container, and the easiest way to get that
sidecar injected is to use a mutating admission
controller that modifies the pod that a user creates
to add that sidecar. That way, you don’t have to educate the application developer
and you don’t have to change any configurations of the applications themselves
in order to get the sidecar applied to all of the
pods that they create. Likewise, if you need
to go from Version 1 to Version 2 of a particular container, if you centralize it
and standardize it with a mutating admission controller, you can be sure that you
can change the version that everybody is using without requiring everyone to go in and
change their YAML files. I hope that gives you a
perspective about how admission controller
is integrated with the basic API flow in Kubernetes, the differences between a
validating admission controller for things like policy, and a mutating admission
controller for defaulting or adding new
sidecars to your applications, and I hope you see how
they can empower you to do even more cool things with
the containers that you deploy it to Kubernetes
on Azure or elsewhere. [MUSIC].

2 thoughts on “Customizing and Extending the Kubernetes API with Admission Controllers”

Leave a Reply

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