Let's not rule out the other option. It may be better in some situations to manage state in a separate non-Kubernetes cluster, as long as it shares the same internal network (data proximity trumps everything).

Some valid reasons are as follows:

• You already have a separate storage cluster and you don't want to rock the boat
• Your storage cluster is used by other non-Kubernetes applications
• Kubernetes support for your storage cluster is not stable or mature enough

You may want to approach stateful applications in Kubernetes incrementally, starting with a separate storage cluster and integrating more tightly with Kubernetes later.