@johscheuer , I have tried the steps of apply the new image directly previously, but after upgrade the pod number become more than upgrade and I checked the image in the pod, some images are old and some are new. So I have to set skip to true to remove all the pod but failed .
With the default settings it’s expected that for a short time after the upgrade some Pods have the new image and some have the old image and that we have some additional Pods. The reason for this is covered here (but not well explained):
Once all of the processes are running at the new version, we will recreate all of the pods so that the foundationdb container uses the new version for its own image. This will use the strategies described in Pod Update Strategy.
The TLDR is that storage Pods are recreate in a rolling strategy, taking one fault domain at a time with a wait time of 1 minute between recreations. All Pods that are non storage Pods (e.g.stateless and log Pods) will be replaced, this means we create a new Pod for every Pod, once the majority of the new Pods are up and running we will exclude the old Pods and delete them. The idea here is to reduce the number of recoveries.