Backgroud
Karmada uses kube-apiserver as the API access entry point, which can provide users with a smooth transition from single-cluster to multi-cluster experience. However, there are still some confusion and inconvenience for users in the actual usage process.
When users use Karmada for resource operations, operation and maintenance, or secondary development, they need to switch kubeconfig context. Different contexts correspond to different targets, such as:
For some users, switching the above context requires awareness of cluster information. For existing businesses, certain modification are needed. For developers and operation personal, learning new knowledge is required.
In order to accommodate these users with historical burdens, Karmada needs to take compatibility with Kubernetes single-cluster operation experience as a starting point and further provide smooth migration best practices from single-cluster architecture to multi-cluster architecture.
The related proposal of FleetAPIServer can refer to karmada-io/karmada#4317
What does FleetAPIServer do?
- Add FleetAPIServer to provide users with a unified view of multi-cluster resources.
- The FleetAPIServer component is pluggable, and not using this component will not affect users' normal use of Karmada functions.
FleetAPIServer provides two types of APIs, namely the API that is compatible with the single-cluster experience of Kubernetes and the API centered around a multi-cluster architecture. In the implementation o this solution, the goal is achieved by accessing karmada-apiserver and APIServer of different member clusters to build API capabilities.
Repository Name
keep the repo name as kubernetes
How to create
Fork from kubernetes.
Why?
The functionality of fleet-apiserver is similar to that of kube-apiserver, providing users with REST API interfaces for access. To improve code reuse, we can directly fork the code of kube-apiserver. At this point, there are two options: the kubernetes repository and the apiserver repository.
After Demo verification, we need to modify the code content in the pkg/registry and staging/src/k8s.io/apiserver folders in the kubernetes repository. Therefore, forking the apiserver repository does not meet our goal.
What content will the kubernetes repo include?
The forked kubernetes repo should only contain the necessary inline changes to make the kube-apiserver programmable for the fleet-apiserver development.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent