Missing serviceaccount causes karmada-static-resource-job failure when using Custom Certificate Mode

[seanlaii]

Please provide an in-depth description of the question you have:
When installing the Karmada chart using Helm with certs.mode set to custom (values.yaml, L128), I encountered an issue. The karmada-static-resource-job (karmada-static-resource-job.yaml, L32) fails because it relies on a ServiceAccount that is only created when certs.mode is set to auto (pre-install-job.yaml, L449–498). This results in the static-resource-job failing due to a missing ServiceAccount, which in turn causes the remaining components to hang at the init container stage.

What do you think about this question?:
Is this behavior expected when using the custom certificate mode, and should the user manually create the required ServiceAccount?

Environment:

• Karmada version: 1.12.2
• Kubernetes version: 1.31
• Others:

[zhzhuang-zju]

Is this behavior expected when using the custom certificate mode, and should the user manually create the required ServiceAccount?

@seanlaii I don't think so. The certificate mode should have nothing to do with the ServiceAccount. I suspect it was introduced in release 1.10. Could you try using the Helm chart of release 1.9 and see if it can succeed?

[seanlaii]

Hi @zhzhuang-zju ,

Thanks for the reply! I've tested with release 1.9 as you advised, and I can confirm that it functions as expected.

Furthermore, I've investigated the installation issue with the current release. I found that by relocating the resource definitions for the Role, RoleBinding, and ServiceAccount (specifically, lines 448-498 in pre-install-job.yaml) outside of the certMode conditional check, the installation proceeds successfully. This modification ensures that these essential resources are created regardless of the selected mode.

If the maintainers concur that this behavior constitutes an issue, I would be happy to submit a pull request to address it.

Thank you again for your assistance!

[zhzhuang-zju]

If the maintainers concur that this behavior constitutes an issue, I would be happy to submit a pull request to address it.

Glad to hear that, feel free to submit the PR