How rolling update strategy works with when database column removed in new deployment. In this case older version still try to save data.
It’s not about how the kubernetes update strategy works when you’re making database changes like this, but more how you architect the database change in the application itself. The same applies however/where ever your application is deployed.
So if we start with the application at version x - where the column still exists, then version x+1 should contain logic to work with the column either being present or absent - and if the column suddenly vanishes, the application should handle this correctly.
So we deploy x+1
Then we can deploy the database upgrade.
Then in version x+2 you remove the logic for the old column from the application.
The same applies to column renames, or any database change where an object that did exist no longer does.
I got your point to design in such a way. In above scenario, x + 1 cannot be deployed before db changes as application cant work but yes we can deploy db changes in 2 steps.
Anyways thanks,