karmada-io
/
karmada
mirror of https://github.com/karmada-io/karmada.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: Add the limitations of search proxy 

Signed-off-by: jwcesign <jiangwei115@huawei.com>
This commit is contained in:
jwcesign 2023-06-04 15:57:29 +08:00
parent 1251ec9d36
commit e020038c2b
2 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/proposals/caching/README.md
View File

@ -18,6 +18,10 @@ Provides a caching layer for Karmada to cache (member clusters) Kubernetes resou
## Motivation
In multicluster scenario, if the administrators want to query the resource in multiple clusters, it's quite hard and inefficient, including changing the clusters' context, none-global resource view.
To address this issue, we propose a caching layer for Karmada to cache (member clusters) Kubernetes resources, the administrators could query the resource across multiple clusters efficiently with a unified entry.
### Goals
- Accelerates resource requests processing speed across regions
@ -43,6 +47,12 @@ Goals:
- Accelerate processing speed of resource requests across regions.
- Get resources in multiple clusters by labels.
### Risks and Mitigations
1. This feature aims to build a cache to store arbitrary resources from multiple member clusters. And these resources are exposed by `search/proxy` REST APIs. If a user has access privilege to `search/proxy`, they can directly access the cached resource without routing their request to the member clusters.
1. As previously mentioned, the resource query request will not be routed to the member clusters. So if a secret is cached in the Karmada control plane but a user in the member cluster cannot access it via member cluster's apiserver due to RBAC privilege limitations, they can still access the secret through the Karmada control plane.
1. This feature is designed for administrators who needs to query and view the resources in multiple clusters, not designed for the end users. Exposing this API to the end users may cause end users to be able to view resources that do not belong to them.
## Design Details
### Define the scope of the cached resource
@ -188,4 +198,6 @@ spec:
apiVersion: apps/v1
```
With this `ResourceRegistry`, Karmada will list and watch the resource defined in `spec.resourceSelectors` and caches the real-time manifest in the cache(local memory or database), and all the query results are from the cache.
### Test Plan

4
docs/proposals/resource-aggregation-proxy/README.md
View File

@ -57,7 +57,11 @@ Allow kubernetes API clients (kubectl, client-go, and other clients that use kub
## Non-Goals
## Risks and Mitigations
1. This feature aims to build a cache to store arbitrary resources from multiple member clusters. And these resources are exposed by `search/proxy` REST APIs. If a user has access privilege to `search/proxy`, they can directly access the cached resource without routing their request to the member clusters.
1. As previously mentioned, the resource query request will not be routed to the member clusters. So if a secret is cached in the Karmada control plane but a user in the member cluster cannot access it via member cluster's apiserver due to RBAC privilege limitations, they can still access the secret through the Karmada control plane.
1. This feature is designed for administrators who needs to query and view the resources in multiple clusters, not designed for the end users. Exposing this API to the end users may cause end users to be able to view resources that do not belong to them.
# Proposal