Understanding the APIService object

Overview

Before diving into the complexities of how the aggregated apiserver works, let’s take a look at how to register our aggregated apiserver.

The aggregator layer

We can have multiple aggregated apiservers. They run separately alongside the kube-apiserver to provide REST APIs. They could run outside of the Kubernetes cluster, or inside of a cluster as Pods. The kube-apiserver provides core Kubernetes APIs, while aggregated apiservers serve our custom APIs.

API groups served by an aggregated apiserver are automatically proxied by the kube-apiserver to the aggregated apiserver. All those APIs are detectable in the kube-apiserver. In other words, the kube-apiserver aggregates these APIs and exposes them uniformly for external access, such as kubectl and other API clients. This brings a consistent user experience, because users do not need to care about where the APIs are actually served. All the users need to know is the address of the kube-apiserver. This can also help protect the security of aggregated apiservers.

In the kube-apiserver, there is a component called the kube-aggregator to handle this proxying work. Below, the diagram illustrates the whole process of how the kube-apiserver serves the REST APIs.