16. Kubernetes Admission Controllers

Overview

In this chapter, we will learn about Kubernetes admission controllers and use them to modify or validate incoming API requests. This chapter describes the utility of Kubernetes admission controllers and how they offer to extend the capabilities of your Kubernetes cluster. You will learn about several built-in admission controllers and the difference between mutating and validating controllers. By the end of this chapter, you will be able to create your own custom admission controllers and apply this knowledge to build a controller for your required scenario.

Introduction

In Chapter 4, How to Communicate with Kubernetes (API Server), we learned how Kubernetes exposes its Application Programming Interface (API) to interact with the Kubernetes platform. You also studied how to use kubectl to create and manage various Kubernetes objects. The kubectl tool is simply a client to the Kubernetes API server. Kubernetes master nodes host the API server through which anyone can communicate with the cluster. The API server provides a way to communicate with Kubernetes for not only external actors but also all internal components, such as the kubelet running on a worker node.

The API server is the central access point to our cluster. If we want to make sure that our organization's default set of best practices and policies are enforced, there is no better place to check for and apply them than at the API server. Kubernetes provides this exact capability via admission controllers.

Let's take a moment to understand why admission controllers...

How Admission Controllers Work

Kubernetes provides a set of more than 25 admission controllers. A set of admission controllers is enabled by default and the cluster administrator can pass flags to the API server to control enabling/disabling the additional controllers (configuring the API server in a production-grade cluster is outside the scope of this book). These can be broadly divided into two types:

• Mutating admission controllers allow you to modify the request before it gets applied to the Kubernetes platform. LimitRanger is one such example, which applies the defaultRequests to the Pod if it is undefined by the Pod itself.
• Validating admission controllers validate the request and cannot change the request object. If this controller rejects the request, it will not be actioned by the Kubernetes platform. An example of this would be the NamespaceExists controller, which rejects the request if the namespace referenced in the request is not available.

Essentially...

Creating Controllers with Custom Logic

As mentioned earlier, Kubernetes provides a list of controllers with predefined functionality. These controllers are baked into the Kubernetes server binary. However, what happens if you need to have your own policy or standard to check against, and none of the admission controllers fit your requirements?

To address such a requirement, Kubernetes provides something called admission webhooks. There are two types of admission webhooks, which we will study in the following sections.

The Mutating Admission Webhook

The mutating admission webhook is a type of mutating admission controller that doesn't have any logic of its own. Instead, it allows you to define a URL that will be called by the Kubernetes API server. This URL is the address to our webhook. Functionally, a webhook is an HTTPS server that accepts requests, processes them, and then responds back.

If multiple URLs are defined, they are processed in a chain, that is, the output...

How a Webhook Works

Webhooks are deployed as Pods in the Kubernetes cluster, and the Kubernetes API server calls them over SSL using the AdmissionReview object. This object defines the AdmissionRequest and AdmissionResponse objects. The webhook reads the request payload from the AdmissionRequest object and provides the success flag and optional changes in the AdmissionResponse object.

The following is a top-level definition of the AdmissionReview object. Note that AdmissionRequest and AdmissionResponse are both part of the AdmissionReview object. The following is an excerpt from the definition of the AdmissionReview object in the Kubernetes source code:

// AdmissionReview describes an admission review request/response.
type AdmissionReview struct {
    metav1.TypeMeta `json:",inline"`
    // Request describes the attributes for the admission request.
    // +optional
    Request *AdmissionRequest...

Validating a Webhook

We have learned that the mutating webhook essentially allows the modification of Kubernetes objects. The other kind of webhook is called a validating webhook. As the name suggests, this webhook does not allow any change in the Kubernetes objects; instead, it works as a gatekeeper to our cluster. It allows us to write code that can validate any Kubernetes object being requested and allow or reject the request based on the conditions that we specify.

Let's understand how this can be helpful using an example. Let's assume that our Kubernetes cluster is used by many teams, and we want to know which Pods are associated with which teams. One solution is to ask all the teams to add a label on their Pod (for example, a label with the key as teamName and the name of the team as the value). As you can guess, it is not a standard Kubernetes feature to enforce a set of labels. In this case, we would need to create our own logic to disallow Pods that do not have...

Summary

In this chapter, we learned that admission controllers provide a way to enforce the mutation and validation of objects during create, update, and delete operations. It is an easy way to extend the Kubernetes platform to adhere to the standards of your organization. They can be used to apply the best practices and policies onto the Kubernetes cluster.

Next, we learned what mutating and validating webhooks are, how to configure them, and how to deploy them on the Kubernetes platform. Webhooks provide a simple way to extend Kubernetes and help you to adapt to the requirements of a particular enterprise.

In the previous series of chapters, starting from Chapter 11, Build Your Own HA Cluster, to Chapter 15, Monitoring and Autoscaling in Kubernetes, you learned how to set up your highly-available cluster on AWS and run stateless, as well as stateful, applications. In the next few chapters, you will learn many advanced skills that will help you go beyond just running applications...