[bug]：serviceaccount not found

[LY-today]

When connecting to a real cluster, the following error is reported. Do you need to add a serviceaccount synchronization mechanism?

failed to apply Pod: pods "cert-manager-cainjector-f9648d4cf-9nt47" is forbidden: error looking up service account cert-manager/cert-manager-cainjector: serviceaccount "cert-manager-cainjector" not found

[LY-today]

@sanposhiho please check

[sanposhiho]

@saza-ku @utam0k @ordovicia What do you think? I think a service acount doesn't affect the scheduling at all, so I believe we can just clear the service account name from Pods when importing.

[sanposhiho]

Thanks for all the bug reports, by the way! @LY-today The syncing feature is still a baby, and we need to refine it.

[utam0k]

@saza-ku @utam0k @ordovicia What do you think? I think a service acount doesn't affect the scheduling at all, so I believe we can just clear the service account name from Pods when importing.

+1.

@LY-today If you have a case where an SA is needed on your schedule, please let me know. If not, we can work on clearing the SA from the Pod.

[LY-today]

@saza-ku @utam0k @ordovicia What do you think? I think a service acount doesn't affect the scheduling at all, so I believe we can just clear the service account name from Pods when importing.

+1.

@LY-today If you have a case where an SA is needed on your schedule, please let me know. If not, we can work on clearing the SA from the Pod.

My business scenario requires SA, which causes errors when syncing pods. So I want to ask whether the simulation scheduler should also build SA's sync logic.

[sanposhiho]

For a short term solution, can you just try to use resourceApplierOptions.GVRsToApply so that the simulator syncs SA as well?

But, either way, we need to solve this problem because using SA with pods is very common in real clusters. The possible options are:

• syncing SA additionally by default
• not syncing SA additionally by default and clearing SA in pod spec. Only when resourceApplierOptions.GVRsToApply has SA, we don't clear SA.

The former is simpler, but would increase the number of objects that we have to sync even though SA isn't necessary for the default scheduling. So, those are pros and cons.

[LY-today]

For a short term solution, can you just try to use resourceApplierOptions.GVRsToApply so that the simulator syncs SA as well?

But, either way, we need to solve this problem because using SA with pods is very common in real clusters. The possible options are:

• syncing SA additionally by default
• not syncing SA additionally by default and clearing SA in pod spec. Only when resourceApplierOptions.GVRsToApply has SA, we don't clear SA.

The former is simpler, but would increase the number of objects that we have to sync even though SA isn't necessary for the default scheduling. So, those are pros and cons.

Agree, there are indeed pros and cons, so you can evaluate the best solution. I can provide MR

[sanposhiho]

@saza-ku @utam0k @ordovicia What is your take? I'm inclined to the first option, just syncing SA additionally because I feel like the latter makes the implementation complicated for a small win.

[saza-ku]

We've implemented so that it removes service accout name from pod specs, haven't we?

https://github.com/kubernetes-sigs/kube-scheduler-simulator/blob/master/simulator/resourceapplier/resource.go#L72

[ordovicia]

@saza-ku @utam0k @ordovicia What is your take? I'm inclined to the first option, just syncing SA additionally because I feel like the latter makes the implementation complicated for a small win.

I think syncing SA by default is a better option, too.
Typically, the number of SA is less than that of pods, and SA have a small data size, so syncing SA would not negatively affect the simulator.

[sanposhiho]

We've implemented so that it removes service accout name from pod specs, haven't we?

Hmm, why is this problem happening then?
Anyways, I think we can just start syncing SA as well. @LY-today can you open a PR, then we can review.

[LY-today]

We've implemented so that it removes service accout name from pod specs, haven't we?

Hmm, why is this problem happening then? Anyways, I think we can just start syncing SA as well. @LY-today can you open a PR, then we can review.

@sanposhiho I was thinking of doing that, but can I submit my PR tomorrow? Today is not convenient.

[sanposhiho]

Of course, you can do it whenever you're convenient. Take your time.

[LY-today]

@sanposhiho #432 #433 please,check