<p>When processing a rolling update with database migrations, how does kubernetes handle this? </p>

<p>For an instance - I have an app that gets updated from app-v1 to app-v2, which includes a migration step to alter an existing table. So this would mean it requires me to run something like <code>db:migrate</code> for a rails app once deployed.</p>

<p>When a rolling deployment takes place on 3 replica set. It will deploy from one pod to another. Potentially allowing PODs that don't have the new version of the app to break. </p>

<p>Although this scenario is not something that happens very often. It's quite possible that it would. I would like to learn about the best/recommended approaches for this scenario.</p>

<p>One way to prevent an old version from breaking is to split a migration into multiple steps. </p>

<p>E.g. you want to rename a column in the database. Renaming the column directly would break old versions of the app. This can be split into multiple steps:</p>

<ul>
<li>Add a db migration that inserts the new column</li>
<li>Change the app so that all writes go to the old and new column</li>
<li>Run a task that copies all values from the old to the new column</li>
<li>Change the app that it reads from the new column</li>
<li>Add a migration that remove the old column</li>
</ul>

<p>This is unfortunately quite a hassle, but prevents having a downtime with a maintenance page up.</p>
