Hongcai Ren
Hongcai Ren
Not sure if we can leverage the `ClusterID`. You can refer to this `KEP` for details. https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/2149-clusterid
/close in favor of #2369
Just thought a question. What would I do if I want to check the yamls we are using in CI?
> Error: Patch "https://10.50.160.24:32443/apis/apiextensions.k8s.io/v1/customresourcedefinitions/resourcebindings.work.karmada.io": unexpected EOF cc @prodanlabs @lonelyCZ could you please take a look?
> because, in some case, traffic controller will distinguish pods by name. if deploy pods with same name in different clusters, our traffic controller will have trouble to autoconfigure. But...
I mean, if you propagate Deployment by Karmada, then you will get different `Pods`. Can you describe your use case here in detail?
> But json log register （_ "k8s.io/component-base/logs/json/register"） does not work because we do not apply the log flags yet. So we can not use the flags --log-format=json to output karmada...
I don't know if we really need the json format logs for now. @lonelyCZ what's your opinion?
Hi @JackZxj thanks for reaching us. > But finally I found that cluster1 would not be the backup, but would be deleted by karmada. Karmada would evict resources from failure...
> I think when clusters recovered after disconnection, it should re-trigger the policies. Yes, you are right. Actually, we are working on it.(see #2301). > Sorry that I can not...