I'm unfamiliar with Liquibase and I'm unclear how non-first Pods leverage Liquibase but, you may be able to use a lock to control access. A Pod that acquires the lock sets the property to true and, if it is unable to acquire the lock, the property is false.

One challenge will be in ensuring that the lock is released if the first Pod terminates. And, to understand the consequence on the other Pods. Is an existing Pod promoted?

Even though Kubernetes leverages etcd for its own distributed locking purposes, users are encouraged to run separate etcd instances if they need locks. Since you have to choose, you may as well choose what you prefer e.g. Redis, Zookeeper.

You could use an init Container or sidecar for the locking mechanism and a shared volume to record its state.

It feels as though Liquibase should be a distinct Deployment exposed as a Service that all Pods access.

Have you contacted Liquibase to see what it recommends for Kubernetes deployments?