How to handle database schema migrations in a Kubernetes rolling update without downtime?

In a rolling deploy scenario, you will by definition have a period of time where multiple versions of your application will be running at the same time. Therefore the key to a zero downtime migration is less about how you invoke the migration and more about how you write the migration.

As mentioned in a comment above, the goal is to not make any breaking data or schema changes from the perspective of any running code. Some changes may need to be made in multiple deploys. For example, the renaming of a column might be accomplished as described here. Once the rolling deploy completes, the old code is gone and the old column can be safely removed. The last warning here is that code rollbacks are more complicated after you've performed such a migration because older code would expect the older column to exist, so in some scenarios it may be safer to instead find a way to temporarily keep backwards compatibility until it's certain you won't need to roll back.

With all that in mind: init containers, a separate Job kicked off by CI, or just running migrations in your application before you start your FastAPI server are all equally valid strategies, they just have slightly different behavior and implementation complexity.