feat: add proposal for cluster proxy enhancement #3822
Conversation
karmada-bot
added
kind/design
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
karmada-bot
added
the
size/L
jwcesign
force-pushed
the
proposal-cluster-proxy
branch
2 times, most recently
from
3f4be5b
to
b305d4a
Compare
Signed-off-by: jwcesign <jwcesign@gmail.com>
jwcesign
force-pushed
the
proposal-cluster-proxy
branch
from
b305d4a
to
003cd83
Compare
|
@jwcesign: GitHub didn't allow me to request PR reviews from the following users: yizhang-zen. Note that only karmada-io members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this: 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. |
| This might be a good place to talk about core concepts and how they relate. | ||
| --> | ||
|
|
||
| - If there are resources with the same name in different member clusters, operations such as `get`, `describe`, `exec`, and `logs` will fail. |
There was a problem hiding this comment.
How about add a external parameter like "--c clustername' to specify the cluster? If not point the multiple resource objects confusion .
| 1. Query target resource from all the clusters with the account of `kubeconfig`, and find out the only one target cluster. | ||
| 2. Route the request to the target cluster with the account of `kubeconfig`. |
There was a problem hiding this comment.
which kubeconfig we are talking about here? Karmada's kubeconfig?
What type of PR is this?
/kind design
/kind documentation
What this PR does / why we need it:
The single cluster users usually use
kubectlto query resources from member clusters separately. So after migrating to Karmada with multiple clusters, it will be great if they still can usekubectlto query resources from member clusters and unaware the member clusters, maintain the same experience as when in a cluster.Also, Karmada is usually used in multi-tenant environment, user A cloud not access to the resource of user B. This is always achieved by using RBAC. Which means the query operation should follow the RBAC privilege limitations in member clusters.
So this proposal proposes an enhancement to query resources from member clusters with native
kubectl, unaware the member clusters, and follow RBAC privilege limitations in member clusters.With this enhancement, users can feel the lease changes after migrating to Karmada, but enjoy the benefits of multiple clusters.
Which issue(s) this PR fixes:
Fixes #none
Special notes for your reviewer:
Does this PR introduce a user-facing change?: