Don't get me wrong; we are strong supporters of Kubernetes. It is a critical piece of and provides massive value when wielded correctly. But Kubernetes was originally intended to act as a container orchestration platform for stateless workloads, . our architecture not stateful applications Over the past few years, the Kubernetes community has done a great job evolving the project to support stateful workloads by creating StatefulSets, which is Kubernetes' answer to storage-centric workloads. StatefulSets run the gamut from databases, queues, and object stores to janky old web applications that need to modify a local filesystem for whatever reason. They provide developers with a set of pretty powerful guarantees: This allows you to easily configure the DNS address to the pod in your application. It works great for database connection strings or configuring complicated Kafka clients. We also use it for setting up erlang’s mesh network at times too. Consistent network identity for each pod: Whenever a pod is restarted, even if it is rescheduled onto a different node, the persistent volume is reattached to the node it is placed on. This is somewhat limited by the capabilities of the CSI (Container Storage Interface) you’re using. For instance, on AWS this only works within the same regional AZ since EBS volumes are AZ-linked. Persistent volume automation: StatefulSet updates are designed to be rolling and consistent. It will always update in the same order which can help preserve systems that have delicate coordination protocols. Sequential Rolling Updates: These guarantees cover a ton of the operations needed to run a stateful workload. In particular, it almost completely handles the availability portion. Given that EBS uptime and redundancy guarantees are extremely strong, StatefulSet’s rescheduling automation almost trivially guarantees you a high availability service. However, some caveats apply (e.g., that you have room in your cluster and don’t botch the AZ setup.) Kubernetes has a ton of promise in this area, and in theory, could certainly evolve into a platform to easily run stateful workloads alongside the stateless ones most developers use it for. What’s Missing From the Kubernetes StatefulSet? So, why do we think StatefulSets are broken? Well, if you run through the operational needs of a stateful workload in your head, there’s one key component that you might notice is missing: What do you do when you need to resize the underlying disk? The dataset is a common database store that typically grows at a pretty constant positive rate. Unless you support horizontal scaling and partitioning, you’ll need to add headroom in the disk as that dataset grows. This is where Kubernetes falls flat on its face. Currently, the StatefulSet controller has . This is despite the fact that almost all CSI implementations have native support for volume resizing the controller could hook into. There is a workaround, but it’s almost ludicrously roundabout: no built-in support for volume resizing Delete the StatefulSet while orphaning pods to avoid downtime with: kubectl sts < > --cascade=orphan delete name Manually edit the persistent volume for each pod to the new storage size Manually edit the StatefulSet volume claim with the new storage size, and add a dummy pod annotation to force a rolling update Recreate the StatefulSet with that new spec which allows the controller to reclaim control of the orphaned pods and begin the rolling update which will trigger the CSI to apply the volume resize We actually automated this entire process as . We knew we’d need to build storage resize automation to make stateful applications running with Plural to be operable by non-Kubernetes experts. It’s a nontrivial amount of logic in reality, and if someone were asked to do it in a high-pressure scenario, the chances of failure are incredibly high. part of the Plural operator Okay, so there’s a pretty noteworthy flaw in Kubernetes StatefulSets, but there a workaround even if it’s somewhat janky. is That shouldn’t be too bad, right? But It Gets Worse! The situation gets downright painful when you realize the impact of this limitation and that a lot of the Kubernetes operators have been built to manage stateful workloads. A pretty good example is the , which is a great project for both provisioning Prometheus databases and allowing a CRD-based workflow for configuring metrics, scrapers, and alerts. Prometheus operator The problem arises because the built-in controller for the operator has no logic to manage StatefulSet resize, but it does have the logic to recreate its underlying StatefulSet if it sees an event that triggered its deletion. This means that you effectively have no way to use the above workaround, since the moment you do a cascade orphan delete, the operator will recreate the StatefulSet against the old spec and prevent proper resize. The only solution is to delete the entire CRD or find a tweak that can fool the operator into not reconciling the object (sometimes, scale to zero will do this). Regardless, as a result of this flaw, there is effectively no way to resize a Prometheus instance with the operator without either significant downtime or data loss. Considering how robust the automation in StatefulSets is in all other cases, it’s pretty shocking that this is still a potential failure mode. Our Head of Community, Abhi, actually hit this issue with the interplay between operators and StatefulSet volume resizes as well while implementing it in the . open-source Vitess operator “Considering the natural complexity of a Vitess deployment, you can infer that disk resizing is proportionally complicated. is a database sharing system that sits on top of MySQL, meaning that volume resizing had to be both partitioning-aware and shard-aware. We had to manually write our own shard-safe that worked with the parent-child structure of Vitess custom resources, and condition to prevent downtime. Shoutout to notable Kubernetes contributor for designing this feature.” Vitess rolling restarts, create a cascade condition address every conceivable failure enisoc Other widely used and notable database operators, like , effectively reimplement the same procedure we implemented in the Plural operator in their own codebase. This causes a ton of wasted developer cycles on a problem that should only have to be fixed once. Zalando's Postgres operator The Potential of Kubernetes In general, we are extremely bullish on the potential for Kubernetes to make the operations of virtually any workload almost trivial, and a huge part of our mission at is to make that a possibility. Plural That said, we also need to be clear-eyed about gaps that still remain in the Kubernetes ecosystem, so we can either work around them or close them upstream. I think it’s pretty clear this is a significant gap, and if prioritized, this could be in a future release of Kubernetes. fixed pretty easily If you thought this was interesting, check out what we’re building on Kubernetes . here Also published here Photo by on CHUTTERSNAP Unsplash
