Deploying, Scaling, and Monitoring a Stateful Application

1. Deploying, Scaling, and Monitoring a Stateful Application

In this video, we will learn how to deploy, scale, and monitor stateful applications using Kubernetes. We will stress the similarities and differences compared with deploying stateless applications.

2. Recap Stateless Applications

Let us briefly recap what we have learned about stateless applications. Such applications are mapped to Deployments, and each Pod of the application does exactly the same tasks. Each Pod is an exact replica of the others. Stateful applications, on the other hand, need Pods that are not exact replicas of each other, as each Pod may work on different tasks. As we will see, much of what we have learned so far can be applied in this chapter as well.

3. Stateful Applications

Stateful apps are a general concept, and again, fit well to Kubernetes. Stateful applications save some internal state. When interrupted or stopped, a new Pod is replicated, and can continue to operate from the saved state. We use stateful applications all the time. For example, database backends like PostgreSQL are stateful. Each time we update data using any of the Pods, the new data needs to be persisted. Now, when a Pod terminates for whatever reason, a new one is created, and this new Pod needs to pick up the saved state.

4. Kubernetes StatefulSets

In Kubernetetes there are so-called "StatefulSets" which are used to create stateful applications. Here is a sample manifest for such a StatefulSet. A StatefulSet has the same sections that we know already: 'apiVersion', 'kind' for declaring a StatefulSet, 'metadata', and 'spec' for declaring detailed specifications of our StatefulSet, like the template for our Pods and the number of replicas. Again, we also have a selector section, which we will discuss later.

5. Deploying to a Kubernetes Cluster

We deploy StatefulSet like we deploy Deployments by executing the command "`kubectl apply -f <manifest.yml>". However, StatefulSets are created a little differently compared to Kubernetes Deployments: Pods are created in order, not all at once like the Pods in a Deployment. Furthermore, Pods get predictable names like `pod-0`, `pod-1`, `pod-2` and so on. This ensures the Pods of a StatefulSet have an identity, in contrast to those of a Deployment. Hence, with this identity different Pods of a StatefulSet can perform different roles.

6. Scaling A StatefulSet

StatefulSets can also be scaled up or scaled down. Again, this is extremely easy: We either change the number of 'replicas' in the Manifest and re-apply, or we use the command 'kubectl scale statefulsets'. When we scale up, additional Pods will be created one after another. For example, if our existing pods are 'pod-0', 'pod-1', 'pod-2', then first 'pod-3', then 'pod-4', will be added to the set. When scaling down, the Pods created last will be deleted first: For example, from our set of Pods, `pod-4`, then `pod-3` will be removed first.

7. Monitoring a StatefulSet

For monitoring, we have the same workflows like before with Deployments. Monitoring lets us react to problems like outages, load spikes, or missing storage. Again, we will use the command "kubectl" for basic monitoring tasks. Commands are the same as with Deployments. For example, we can use "kubectl get pods" to get all pods in a StatefulSet with their current status, or we can use "kubectl get services" to get all the services that a StatefulSet may use.

8. Let's practice!

With that new knowledge about StatefulSets, let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.