Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

seanlaii
Copy link
Contributor

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?:

`karmada-operator`: standardize the naming of karmada config in karmada-operator installation method

@karmada-bot karmada-bot added kind/feature Categorizes issue or PR as related to a new feature. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. labels Jan 24, 2025
@karmada-bot karmada-bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jan 24, 2025
@codecov-commenter
Copy link

codecov-commenter commented Jan 24, 2025

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 41.46341% with 48 lines in your changes missing coverage. Please review.

Project coverage is 48.10%. Comparing base (d80b7d4) to head (1e3d8c0).

Files with missing lines Patch % Lines
operator/pkg/tasks/init/upload.go 0.00% 40 Missing ⚠️
operator/pkg/tasks/deinit/kubeconfig.go 89.28% 2 Missing and 1 partial ⚠️
operator/pkg/util/naming.go 0.00% 3 Missing ⚠️
operator/pkg/controller/karmada/planner.go 33.33% 2 Missing ⚠️

❗ 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     
Flag Coverage Δ
unittests 48.10% <41.46%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@seanlaii seanlaii changed the title Standardize the naming of karmada config in Karmada Operator [WIP] Standardize the naming of karmada config in Karmada Operator Jan 24, 2025
@karmada-bot karmada-bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 24, 2025
@seanlaii
Copy link
Contributor Author

Hi @chaosi-zju , I found that in karmada-operator, all the components reference the same secret.
Do we plan to change this behavior to create secrets for each component?
If that's the case, maybe I could create multiple secrets in https://github.com/karmada-io/karmada/blob/master/operator/pkg/tasks/init/upload.go#L108-L115 by checking if the components exist from data.Components()?

@chaosi-zju
Copy link
Member

chaosi-zju commented Jan 24, 2025

Do we plan to change this behavior to create secrets for each component?

Yes, that is also our current purpose, we aims to create different secret for each component in format of ${karmada_instance_name}-${component}-config

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 karmada.config (In the past, the subfields varied across different installation methods, and we hope to standardize them.)

@karmada-bot karmada-bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 25, 2025
@seanlaii seanlaii force-pushed the operator branch 2 times, most recently from 8acb959 to 852a022 Compare January 25, 2025 23:00
@karmada-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign liangyuanpeng, poor12 for approval. For more information see the Kubernetes Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@seanlaii seanlaii changed the title [WIP] Standardize the naming of karmada config in Karmada Operator Standardize the naming of karmada config in Karmada Operator Jan 25, 2025
@karmada-bot karmada-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 25, 2025
@seanlaii
Copy link
Contributor Author

Hi @chaosi-zju , please help review the PR when you are available. Thank you!

func generateComponentKubeconfigSecrets(data InitData, configString string) []*corev1.Secret {
var secrets []*corev1.Secret

secrets = append(secrets, generateKubeconfigSecret(util.AdminKubeconfigSecretName(data.GetName()), data.GetNamespace(), configString))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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?

Copy link
Member

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

Copy link
Contributor Author

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)
Copy link
Member

@chaosi-zju chaosi-zju Jan 26, 2025

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.

Comment on lines 32 to 35
// ComponentKubeconfigSecretName returns secret name of karmada component kubeconfig
func ComponentKubeconfigSecretName(karmadaComponent string) string {
return generateResourceName(karmadaComponent, "config")
}
Copy link
Member

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 parameter karmadaComponent actually always has prefix karmada, the logic inner generateResourceName is redundant

Copy link
Contributor Author

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
Copy link
Contributor Author

@seanlaii seanlaii Feb 5, 2025

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.

@chaosi-zju
Copy link
Member

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
/cc @RainbowMango

@karmada-bot karmada-bot added the lgtm Indicates that a PR is ready to be merged. label Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Umbrella] [Karmada config && certificates] secret and path naming convention
4 participants