Skip to main content
Version: Next

Proxy Global Resources


The newly introduced proxy feature allows users to access all the resources both in karmada control plane and member clusters. With it, users can:

  • create, update, patch, get, list, watch and delete resources in karmada control plane, such as deployments and jobs. All the request behaviors are supported, just like using karmada-apiserver.
  • update, patch, get, list, watch and delete resources in member clusters, such as pods, nodes, and customer resources.
  • access subresources, such as pods' log and exec.

Quick start

To quickly experience this feature, we experimented with karmada-apiserver certificate.

cp $HOME/.kube/karmada.config $HOME/karmada-proxy.config

Step1: Define Resource To be Proxied

Define which member cluster resource you want to be proxied with ResourceRegistry by applying the following Yaml file in the karmada-apiserver:

kind: ResourceRegistry
name: proxy-sample
- apiVersion: v1
kind: Pod
- apiVersion: v1
kind: Node
kubectl --context karmada-apiserver apply -f resourceregistry.yaml

Based on the ResourceRegistry above, you can access pods and nodes with proxy function.

Step2: Obtain the karmada-apiserver Certificate

For Karmada deployed using hack/, you can directly copy it from the $HOME/.kube/ directory.

Step3: Access by proxy

Append /apis/ to the server address of karmada-proxy.config. Then set this file as default config:

export KUBECONFIG=$HOME/karmada-proxy.config

After processing the above steps, you can access pods and nodes with kubectl.

Taking getting the pod log as an example, you can use the following command:

kubectl  logs <pod-name> -n <namespace-name>

Specifying --raw as following has the same effect:

kubectl get --raw /apis/<ns>/pods/<pod-name>/log

Enjoy it!

Note: Use the current ability to rely on the Cluster's impersonator Secret. Please ensure that the correct impersonatorSecretRef is set in the Cluster object.


Is creating supported?

For resources not defined in ResourceRegistry, creating requests are redirected to karmada controller panel. So Resources are created in controller panel. For resources defined in ResourceRegistry, proxy doesn't know which cluster to create, and responses MethodNotSupported error.

Can I read resources by selectors?

Label selectors are fully supported. While field selectors are limited to and metadata.namespace

When I get pods with kubectl, only NAME and AGE columns are displayed

Yes, kubectl use application/json;as=Table;;v=v1 as content-type, while proxy only implement defaultTableConvertor as TableConvertor.

NAME                    AGE
nginx-65c54cc984-2jjw6 10s

But it doesn't affect usaging of client-go, which use application/json as content-type.

What will happen when I access resource with same name across clusters.

In this stage, proxy cannot discern the resources with same name across clusters. So get/update/patch/delete and subresources requests will return a conflict error. When list resources, the resources with same name will be returned in item list.

Users shall design to avoid or tolerate this error.

How to access resources in pull mode cluster

we can deploy apiserver-network-proxy (ANP) to access it.