REQUEST: New repo for building fleet-apiserver

[XiShanYongYe-Chang]

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 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.

[XiShanYongYe-Chang]

/assign @kevin-wangzefeng

[kevin-wangzefeng]

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]

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]

Revised the description of the issue.

[kevin-wangzefeng]

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]

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]

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

[RainbowMango]

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

[XiShanYongYe-Chang]

Thanks~ @kevin-wangzefeng @RainbowMango
/close

[karmada-bot]

@XiShanYongYe-Chang: Closing this issue.

In response to this:

Thanks~ @kevin-wangzefeng @RainbowMango
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.