In karmada-search, kubectl command only show two columns "Name and CreateTime" ?

[zheng-jx]

1. What happened: In karmada-search, "kubectl --kubeconfig karmada-proxy.config get pod" only show Name and CreateTime , karmada-proxy.config is karmada-host which server add "/apis/search.karmada.io/v1alpha1/proxying/karmada/proxy"。 NAME CREATED AT xxx 2024-10-12T07:04:05Z
2. What you expected to happen: NAME READY STATUS RESTARTS AGE xxx 1/1 Running 0 174m
3. How to reproduce it : 3.1 install karmada-search 3.2 copy karmada-apisever.config karmada-proxy.config , modify karmada-proxy.config server, http:// host:port -> http://host:port/apis/search.karmada.io/v1alpha1/proxying/karmada/proxy 3.3 create ResourceRegistry yaml `spec: resourceSelectors:
   • apiVersion: v1 kind: Pod targetCluster: clusterNames:
     • a
     • b` 3.4 kubectl --kubeconfig karmada-proxy.config get pod

4、*Others: In karmada-search, about tableConvertor, obj type is Unstructured but not pod

 func (h *HumanReadableGenerator) GenerateTable(obj runtime.Object, options GenerateOptions) (*metav1.Table, error) {
    t := reflect.TypeOf(obj)
    handler, ok := h.handlerMap[t]
       if !ok {
          // will return here,   use default tableConvertor
           return nil, fmt.Errorf("no table handler registered for this type %v", t)
    }
}

5. Environment:
   • karmda verison 1.11
   • kubectl-karmada 1.11
   • k8s version 1.20

[chaosi-zju]

I verified that this case indeed exist, do you have any idea how to solve this problem?

[zheng-jx]

Modify the tableConvertor of resource_cache to be compatible with unstructured types and select the corresponding handler according to the unstructured GVK

[chaosi-zju]

We actually registered *v1.PodList in handlerMap map[reflect.Type]*handlerEntry, but unfortunately obj runtime.Object is not recognized as *v1.PodList, but as *unstructured. UnstructuredList.

select the corresponding handler according to the unstructured GVK

do you mean you want the handlerMap map[reflect.Type]*handlerEntry to be as handlerMap map[GVK]*handlerEntry?

[zheng-jx]

Almost. Add a new map, such as map[GVK]*handlerEntry, and determine which one to use based on the reflect.Type.

[chaosi-zju]

I found this func (h *HumanReadableGenerator) GenerateTable is not only called by karmada-search, but also called by karmada-aggregated-apiserver

when I get resources handled by karmada-aggregated-apiserver, like cluster resource, the obj runtime.Object can be normally recognized as *cluster.ClusterList

I am now a little curious about why karmada-aggregated-apiserver can handle this problem correctly, this may be another breakthrough.

[zheng-jx]

karmada-aggregated-apiserver should be directly proxied to the target cluster, karmada-search has a layer of cache

[chaosi-zju]

karmada-aggregated-apiserver should be directly proxied to the target cluster, karmada-search has a layer of cache

you are right, here list from MultiClusterCache can only gets UnstructuredList

https://github.com/karmada-io/karmada/blob/54be414d9f24eea643b74f4b7c1f5e294778dfb9/vendor/k8s.io/apiserver/pkg/endpoints/handlers/get.go#L300-L303

Add a new map, such as map[GVK]*handlerEntry

It seems a feasible solution. I currently don't have any better approach, so I'll wait for others' opinions.