Closed chaosi-zju closed 1 week ago
@XiShanYongYe-Chang @zhzhuang-zju @calvin0327 @carlory and anyone else
Can you help and look this problem?
Which of the two way do you think is better?
Personally, I prefer method two.
Hi @carlory @calvin0327 are there any security issues if we do this, or anything else that doesn't make sense?
There is no essential difference between the two methods, so they are the same regarding security. so more simpler and easier to understand is the better.
method two +1
method two +1
What happened:
In helm installation method, when installing
karmada-controller-manager
, we use ainitContainer
to wait for the ready status ofkarmada-apiserver
, which prevents thekarmada-controller-manager
fromCrashLoopBack
. This feature is introduced in #5010.In order to access host cluster kube-apiserver in
initContainer
, we mounted aservice-account-token
typeSecret
, because the deployment ofkarmada-controller-manager
is definedautomountServiceAccountToken: false
. UnsetautomountServiceAccountToken
is introduced in #2523.However, in #5010, we deleted the
Secret
mentioned above when we finished installation. Actually, we still need this secret after installation finished, otherwisekarmada-controller-manager
can't restart for lack of the mounted secret.What you expected to happen:
Now, we have two ways to resolve it:
Secret
but directly setautomountServiceAccountToken
.In #2523, we unset
automountServiceAccountToken
because we thinkkarmada-controller-manager
has no need to interact with host cluster, but now it seems that it needs to interact with the host cluster. So, maybe we can resetautomountServiceAccountToken
.How to reproduce it (as minimally and precisely as possible):
helm
method (the latest version)karmada-controller-manager
karmada-controller-manager
readyAnything else we need to know?:
Environment:
kubectl-karmada version
orkarmadactl version
): latest