It’s commonly known that Kubernetes works easiest with stateless applications. After all, Kubernetes’ out of the box use case lends to a stateless microservices environment, which in recent years raised the question of whether containerized microservices applications could also be stateful given the former limitations of Kubernetes. Fortunately, new rollouts in Kubernetes now provide foundational support of stateless, stateful, and mixed applications.
Kubernetes introduced the StatefulSet (previously the Petset) which supports stateful applications and microservices by guaranteeing identifiable uniqueness across pods. As a result, you no longer need to feel pressured to create fully stateless applications in order to run on Kubernetes; you can run StatefulSets under the same pattern as your typical Kubernetes controllers. As you build out your microservices application, you’ll need to consider how to conserve costs with stateful, stateless and mixed services.
Google Cloud Kubernetes Engine anticipates each use case and has clear documentation on how to accommodate your needs. SADA has helped clients take advantage of GCP’s cost saving opportunities across a variety of complex applications. Let’s dive in!
Fully Stateless Applications on Google Kubernetes Engine (GKE)
As we’ve covered in previous articles, GKE is the obvious environment of choice for containerized microservices applications that need to scale. The service is fully managed by Google – you define the ground rules of scaling up and down, and Kubernetes handles the creation and destruction of pods as demand fluctuates. Under this design, you’re not wasting money running idle VMs or worrying about their maintenance; GKE handles the unexpected failure of a pod seamlessly.
Stateless applications are relatively easier to create in a Kubernetes environment, as they don’t require unique database replicas or pods. Everything is uniform. The Deployment controller handles the disposing of pods if they become unhealthy or are no longer needed.
As such, stateless applications are easier to scale as well, almost at the click of a button – perfect for backend servers, web APIs and certain web applications. This will be the most common use case for microservices in your project.
Stateful Applications in Google Kubernetes Engine
For many scenarios, however, you simply cannot get around the need for persistent storage and session creation. Since they were first released in Version 1.5, StatefulSets have become a dynamic feature of Kubernetes to accommodate a wider variety of applications than were previously possible.
For an even more than basic primer on StatefulSets, visit the Kubernetes documentation here. StatefulSets are used when there is a need for uniqueness between pods and replicas. They aren’t just for stateful applications – they can be adapted for distributed systems or clustered applications.
Unlike the average Kubernetes pods, pods within a StatefulSet have a unique index and a stable network identity that is published through a Headless Service. Creating stateful, containerized applications with transactional databases is also easily achieved using StatefulSets.You’ll find that, as this controller achieves more maturity in Kubernetes, there is a growing catalog of production-ready tutorials for deploying custom stateful architectures in Kubernetes.
But what if you want the best of all worlds? For example, consider a microservices application with a combination of stateful and stateless microservices that’s currently racking up a big bill? How do you run this application in Google Cloud Platform while still achieving security and cost savings? Not to worry – this is all possible, but there are extra steps to consider.
Cost Saving Tactics for Stateful Applications in Google Kubernetes Engine
By coupling your Kubernetes application with preemptible nodes on Google Cloud Platform, you’ll immediately see drastic cost savings off the price for regular VM instances.
Preemptible VMs are often touted for their cost savings in short lived batch processes, as they come and go as they please. However, this startup and shutdown of nodes poses a problem for maintaining state. Maybe you’re running an application comprised of dozens of stateless microservices, but a handful of them need to maintain some type of state. If that’s the case, you can consider using Node Affinity to schedule hard and soft preferences for your various microservices nodes that guides your application towards preemptible VMs where possible. This is only desired if your application is tolerant to failures of certain pods.
But for a fully stateless application, you need to gracefully handle the shutdown of a node (or the unexpected termination of a node) to hand off state to the next node.
Still with me? Just dream of the cost savings. To flesh out the architecture needs in more detail, we’ve created a tutorial for this use case here. Follow step by step to learn how to use Google Compute Engine to run startup and shutdown scripts to handle the termination and creation of preemptible nodes. While it’s certainly more involved than your average stateful applications, reducing cloud costs is a must for those with high scaling needs.
Custom Configurations, Costs Savings and Security – Just Ask SADA
Even after following best practice in Kubernetes and Google Cloud documentation, your workload might still benefit from extra cost reduction or additional security. SADA Systems is an expert in optimizing your Google Kubernetes Engine environment tailored to your specific business needs. Reach out to us today to discover how we can better use Google Cloud Platform’s service offerings to streamline your workflow.Request your FREE Consultation now!
