How the Aggregated Apiserver Works
Explore the architecture and workflow of the aggregated apiserver in Kubernetes. Understand its similarities to kube-apiserver, how it manages authentication using TLS and token validation, supports custom storage backends, and delegates authorization through RBAC. This lesson provides essential knowledge for implementing and securing aggregated apiservers effectively.
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-apiserverto 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 ...