-
Notifications
You must be signed in to change notification settings - Fork 917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize the naming of karmada config in Karmada Operator #6082
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #6082 +/- ##
==========================================
- Coverage 48.11% 48.10% -0.02%
==========================================
Files 668 668
Lines 55163 55211 +48
==========================================
+ Hits 26544 26557 +13
- Misses 26893 26927 +34
- Partials 1726 1727 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Hi @chaosi-zju , I found that in |
Yes, that is also our current purpose, we aims to create different secret for each component in format of just like: karmada-aggregated-apiserver-config
karmada-controller-manager-config
karmada-scheduler-config
karmada-descheduler-config
... besides, sorry I missed a point, the content of it should be like: apiVersion: v1
kind: Secret
metadata:
name: ${karmada_instance_name}-${component}-config
namespace: karmada-system
stringData:
karmada.config: |-
xxxx..... pay attention to the sub field |
8acb959
to
852a022
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @chaosi-zju , please help review the PR when you are available. Thank you! |
operator/pkg/tasks/init/upload.go
Outdated
func generateComponentKubeconfigSecrets(data InitData, configString string) []*corev1.Secret { | ||
var secrets []*corev1.Secret | ||
|
||
secrets = append(secrets, generateKubeconfigSecret(util.AdminKubeconfigSecretName(data.GetName()), data.GetNamespace(), configString)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still preserve admin-config for https://github.com/karmada-io/karmada/blob/master/operator/pkg/controller/karmada/planner.go#L162-L172.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me understand your intention:
Unlike local up
or karmadactl
, which allow for direct export of Karmada config to the file system of host machine for user access, the Karmada config generated by the operator
can only be stored as secret in cluster, which requires users to manually export it.
As a result, it is essential to retain this admin config for user access?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is reasonable
BTW, in that case, our related website doc which teach users how to export karmada config may also need updation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, your understanding is correct. Thanks for providing further details.
constants.KarmadaOperatorLabel, | ||
) | ||
if err != nil { | ||
return fmt.Errorf("failed to cleanup karmada kubeconfig secret '%s', err: %w", secretName, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
according to RainbowMango
, we prefer using 'karmada config' instead of 'karmada kubeconfig'
it is better to eliminate the term kubeconfig
when using karmada config.
operator/pkg/util/naming.go
Outdated
// ComponentKubeconfigSecretName returns secret name of karmada component kubeconfig | ||
func ComponentKubeconfigSecretName(karmadaComponent string) string { | ||
return generateResourceName(karmadaComponent, "config") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shall we directly name it as ${karmadaComponent}-config
?
- Other installation methods do not have logic inner
generateResourceName
- In your case, like
util.ComponentKubeconfigSecretName(util.KarmadaSearchName(data.GetName()))
, the parameterkarmadaComponent
actually always has prefixkarmada
, the logic innergenerateResourceName
is redundant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense. Updated in the PR.
@@ -24,11 +24,16 @@ import ( | |||
// Namefunc defines a function to generate resource name according to karmada resource name. | |||
type Namefunc func(karmada string) string | |||
|
|||
// AdminKubeconfigSecretName returns secret name of karmada-admin kubeconfig | |||
func AdminKubeconfigSecretName(karmada string) string { | |||
// AdminKarmadaConfigSecretName returns secret name of karmada-admin karmada-config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename this function to replace Kubeconfig
with KarmadaConfig
according to the comment.
Signed-off-by: wei-chenglai <[email protected]>
did a simple test, the installation is successful and the secret are as follows: $ kubectl get secret -n karmada-system
NAME TYPE DATA AGE
karmada-admin-config Opaque 1 7m10s
karmada-aggregated-apiserver-config Opaque 1 7m10s
karmada-cert Opaque 16 7m36s
karmada-controller-manager-config Opaque 1 7m10s
karmada-descheduler-config Opaque 1 7m10s
karmada-etcd-cert Opaque 6 7m36s
karmada-kube-controller-manager-config Opaque 1 7m10s
karmada-metrics-adapter-config Opaque 1 7m10s
karmada-scheduler-config Opaque 1 7m10s
karmada-search-config Opaque 1 7m10s
karmada-webhook-cert Opaque 2 7m36s
karmada-webhook-config Opaque 1 7m10s
sh.helm.release.v1.karmada-operator.v1 helm.sh/release.v1 1 9m12s meet expectations /lgtm |
What type of PR is this?
/kind feature
/kind cleanup
What this PR does / why we need it:
In karmada, here are two important secrets, which is mount by most karmada components. One is karmada-cert, which contains a series of cert files like ca.crt, apiserver.crt and so on; another is karmada-kubeconfig, which contains a kubeconfig of karmada-apiserver.
However, in different installation methods, we used inconsistent secret naming or file path naming, which can potentially cause some unnecessary problems, detail refer to #5363.
This PR aims to standardize the naming of karmada config in Karmada Operator installation method.
Which issue(s) this PR fixes:
Fixes #6051
Special notes for your reviewer:
Does this PR introduce a user-facing change?: