How the Aggregated Apiserver Works

Overview

Before diving into the implementation of the aggregated apiserver, let’s take a tour of how the aggregated apiserver works in a Kubernetes cluster.

We’ll start with a high-level view on the aggregated apiserver. What is it made of?

A high-level view

An aggregated apiserver works in a similar way to the kube-apiserver. It resembles most parts of the kube-apiserver. This leads to nearly the same architecture (as shown below). However, the aggregated apiserver does not have an embedded kube-aggregator and an embedded apiextension-apiserver (which serves CRDs).

From the image above, we can see that the aggregated apiserver has the same basic internal structure as the kube-apiserver:

• It has its own handler chain, including authentication, auditing, impersonation, and authorization. While the authentication and authorization here is not all self implemented, we may interact with the kube-apiserver to validate the auth info. It runs standalone, but actually works as a subsidiary. We will go over the auth part in detail a little bit later.

• It has its own resource handlers for every custom API group. Every handler pipeline consists of object decoding, conversion, defaulting, admission, REST ...