How the Aggregated Apiserver Works
Learn how the aggregated apiserver works in Kubernetes.
We'll cover the following...
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 ...