REQUEST: New repo for building fleet-apiserver

XiShanYongYe-Chang commented 10 months ago

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:

Use this server address to query Karmada control plane resources: https://172.18.0.2:5443
Use this server address to query member1 cluster resources: https://172.18.0.2:5443/apis/cluster.karmada.io/v1alpha1/clusters/member1/proxy
Use this server address to query member2 cluster resources: https://172.18.0.2:5443/apis/cluster.karmada.io/v1alpha1/clusters/member2/proxy

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 https://github.com/karmada-io/karmada/pull/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.

XiShanYongYe-Chang commented 10 months ago

/assign @kevin-wangzefeng

kevin-wangzefeng commented 10 months ago

I think it is better to keep the repo name as kubernetes and not change it to fleet-apiserver. The forked repo should only contain the necessary inline changes to make the kube-apiserver programmable for the fleet-apiserver development. The rest of the fleet-apiserver code should be stored in a separate place, maybe a staging repo in karmada-io/karmada or a stand-alone repo.

XiShanYongYe-Chang commented 10 months ago

I think it is better to keep the repo name as kubernetes and not change it to fleet-apiserver.

Thanks, I get it. I will update the issue description.

The forked repo should only contain the necessary inline changes to make the kube-apiserver programmable for the fleet-apiserver development. The rest of the fleet-apiserver code should be stored in a separate place, maybe a staging repo in karmada-io/karmada or a stand-alone repo.

Yes, we will strive to develop and iterate according to this strategy. The plan is to first write code for the fleet-apiserver component and deploy it in the karmada-io/karmada repository.

XiShanYongYe-Chang commented 10 months ago

Revised the description of the issue.

kevin-wangzefeng commented 10 months ago

The plan is to first write code for the fleet-apiserver component and deploy it in the karmada-io/karmada repository.

I'm not quite clear on this, could you rephrase it?

XiShanYongYe-Chang commented 10 months ago

I'm sorry, I didn't explain it clearly. Let me try to describe it more clearly.

We plan to first store the rest of fleet-apiserver code in the karmada-io/karmada repo and compile and deploy fleet-apiserver. If this cannot be achieved, we will consider handling this matter in a new repository.

kevin-wangzefeng commented 10 months ago

Thanks for the clarification, the fork repo has been created at: https://github.com/karmada-io/kubernetes

RainbowMango commented 10 months ago

Just created v1.28.4-karmada branch based on Kubernetes v1.28.4.

XiShanYongYe-Chang commented 10 months ago

Thanks~ @kevin-wangzefeng @RainbowMango /close

karmada-bot commented 10 months ago

@XiShanYongYe-Chang: Closing this issue.

In response to [this](https://github.com/karmada-io/community/issues/61#issuecomment-1837932357): >Thanks~ @kevin-wangzefeng @RainbowMango >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

karmada-io / community