Navigating Application Data Storage: On-Cluster vs Of-Cluster

‍
During my recent trip to KubeCon, I encountered a wealth of knowledge that significantly shifted my perspective on managing applications in Kubernetes, particularly around the concept of stateful versus stateless applications. The consensus among experts pointed to a clear preference for keeping applications stateless within Kubernetes environments, underscoring the inherent complexities and challenges associated with stateful applications. So, if you’ve been wondering whether to configure Postgres or Mongo directly within your cluster or opt for a managed database solution, this article is for you.

The Stateful vs. Stateless Debate

Kubernetes has revolutionised how we deploy and manage containerized applications, with its ability to orchestrate complex systems seamlessly. However, the distinction between stateful and stateless applications within this ecosystem has sparked a debate, emphasising the importance of understanding their implications on system architecture and maintenance.

Challenges of storing application data in Kubernetes

Stateful applications, those which save client data from one session to another, introduce a layer of complexity in Kubernetes environments, especially when their data is stored within the cluster:

- Maintenance Difficulties: Stateful applications make cluster maintenance, such as upgrades or scaling operations, more cumbersome. Storing the data on cluster, means that you cannot easily tear down and spin up clusters without risking data loss or inconsistencies.

- Backup and Disaster Recovery Complications: Tools like Velero, which are designed to backup Kubernetes clusters, face difficulties in effectively restoring Persistent Volumes. This limitation complicates disaster recovery strategies, making it harder to ensure data integrity and availability after system failures.

- Workload Migration: Migrating stateful workloads between clusters or setting up standby clusters for disaster recovery is significantly more complex when data resides within the cluster. Pointing applications to an external storage solution simplifies these processes, enhancing system resilience.

- ClusterMesh and Replication Issues: In architectures designed to treat multiple clusters as a single entity, stateful applications complicate data replication. If a cluster containing critical data fails, ensuring reliability and consistency across the remaining clusters becomes a challenge.

- Data Access for Machine Learning: For organisations leveraging machine learning, providing teams with access to data becomes easier with managed databases. Setting up replications of databases for ML teams to utilize is more straightforward when the data is external to the Kubernetes cluster.

A Shift in Perspective: Keeping Data External

The discussions and talks at KubeCon have brought to light that while Kubernetes offers robust solutions for managing containerized applications, it is perhaps best suited for stateless applications. The consensus suggests that keeping data external to the cluster not only simplifies maintenance and disaster recovery but also enhances the overall resilience and flexibility of the system architecture.

‍