Understanding the APIService object
Explore the role of the APIService object in extending Kubernetes APIs through aggregated apiservers. Understand how it registers custom API groups and versions, manages security with TLS certificates, and controls request proxying and priority. Gain insights into handling multiple API groups and ensuring high availability for custom APIs within Kubernetes.
We'll cover the following...
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 ...