You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is because the default for deployment strategy is rolling update, which means that on a re-deployment triggered by a change to pod template, there can be two instances of the pod at the same time. That is, the new pod is started before the old is shutdown.
The docs say to only ever set replicas to 1 due to issue of there being more than once instance, but the rolling update can induce the same problem. You should therefore set the deployment strategy to Recreate to ensure old pod is shutdown before starting new one, thus ensuring there is truly only at most one pod for the operator running at the same time.
Also, #51 can indirectly solve this problem, as these 2 pods running at the same time will freeze each other for a short period of time, so they will not start double-handling the objects (yet there will be a short downtime, which will happen anyway due to pod recreation.)
The text was updated successfully, but these errors were encountered:
Docs at:
https://kopf.readthedocs.io/en/latest/deployment/
have
Deployment
example of:This should also set
.spec.strategy.type==Recreate
.https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment
This is because the default for deployment strategy is rolling update, which means that on a re-deployment triggered by a change to pod template, there can be two instances of the pod at the same time. That is, the new pod is started before the old is shutdown.
The docs say to only ever set replicas to 1 due to issue of there being more than once instance, but the rolling update can induce the same problem. You should therefore set the deployment strategy to
Recreate
to ensure old pod is shutdown before starting new one, thus ensuring there is truly only at most one pod for the operator running at the same time.GrahamDumpleton Thanks. That should be changed indeed.
Also, #51 can indirectly solve this problem, as these 2 pods running at the same time will freeze each other for a short period of time, so they will not start double-handling the objects (yet there will be a short downtime, which will happen anyway due to pod recreation.)
The text was updated successfully, but these errors were encountered: