karmada-io
deployment in non Karamada system namespaces
Hello, my device is not installed in the Karamada system namespace and I am unable to access the page after logging in. Do you support deployment in non Karamada system namespaces
我在一个K8S集群部署了两套karmada，一套部署台karmada-test命名空间一套部署在karmada-prd命名空间，现在需要将dashboard也分别部署在这两个命名空间，请问我要怎么操作，我看dashboard的web调用api的svc是硬编码在karmada-sytem命名空间，我可通过变量配置到karmada-prd命名空间吗 I have deployed two sets of Karamada in a K8S cluster, one in the Karamada test namespace and the other in the Karamada prd namespace. Now I need to deploy the dashboard separately in these two namespaces. How do I proceed? I noticed that the web API's SVC for the dashboard is hard coded in the Karamada sytem namespace. Can I configure it to the Karamada prd namespace through variables
The karmada dashboard can't be installed in different namespace except karmada-system, even if you specify the override namespace in kubectl or helm, because the karmada-dashboard-api hardcoded the karmada-system namespace. I think we can make the installed namespace as an extra options, and set karmada-system as default value.
The karmada dashboard can't be installed in different namespace except karmada-system, even if you specify the override namespace in kubectl or helm, because the karmada-dashboard-api hardcoded the karmada-system namespace. I think we can make the installed namespace as an extra options, and set karmada-system as default value.
Hello, please tell me how to achieve
The karmada dashboard can't be installed in different namespace except karmada-system, even if you specify the override namespace in kubectl or helm, because the karmada-dashboard-api hardcoded the karmada-system namespace. I think we can make the installed namespace as an extra options, and set karmada-system as default value.
Hello, please tell me how to achieve
I'm still on the train, more detailed doc will be provided later today.
karmada-system is hard-coded in the karmada-dashboard, one is literal string, another one is constant variable. What we expected is that we need extra namespace options in start cmd, and use namespace option instead of two kinds of hard-coded string.
you need to add namespace option in https://github.com/karmada-io/dashboard/blob/3939721189fddbbef61b6565e7669d29b644bdfc/cmd/api/app/options/options.go#L26-L40
because we need to share the options globally, so it need to make the options singleton, you can achieve it in the https://github.com/karmada-io/dashboard/blob/3939721189fddbbef61b6565e7669d29b644bdfc/cmd/api/app/options/options.go#L42-L45
apart from that, we need an extra method to get the singleton options.
and then you can try to change the hard-code string with the global options, here you should do it with more patient.
karmada-systemis hard-coded in the karmada-dashboard, one is literal string, another one is constant variable. What we expected is that we need extra namespace options in start cmd, and use namespace option instead of two kinds of hard-coded string.you need to add namespace option in
dashboard/cmd/api/app/options/options.go
Lines 26 to 40 in 3939721
type Options struct { BindAddress net.IP Port int InsecureBindAddress net.IP InsecurePort int KubeConfig string KubeContext string SkipKubeApiserverTLSVerify bool KarmadaKubeConfig string KarmadaContext string SkipKarmadaApiserverTLSVerify bool Namespace string DisableCSRFProtection bool OpenAPIEnabled bool } because we need to share the options globally, so it need to make the options singleton, you can achieve it in the
dashboard/cmd/api/app/options/options.go
Lines 42 to 45 in 3939721
// NewOptions returns initialized Options. func NewOptions() *Options { return &Options{} } apart from that, we need an extra method to get the singleton options.
and then you can try to change the hard-code string with the global options, here you should do it with more patient.
You still. Thank you. Do you have plans to implement this function in subsequent versions