In this comprehensive video, we dive deep into the concept of StatefulSets in Kubernetes. You may have heard about Deployments, but StatefulSets offer a unique way to manage stateful applications in a cloud-native environment. Throughout this video, you’ll learn what a StatefulSet is, its key features, and the differences between StatefulSets and Deployments.
Index
Introduction
What is a StatefulSet?
Key Features
Different then Deployment
Headless Service
Difference between StatefulSet and Deployment?
When to use StatefulSet (use case)?
Components
Pod Template
Volume Claim Templates
Headless Services
Storage Classes
Labels and Selectors
Implementation
Basic StatefulSet Configuration
Advance configuration
Scaling Operations
Manual Scaling
Scale Down
Automatic Scaling
Updates and Upgrades
Blue/Green Strategy
canary
rolling
What is a StatefulSet?
- A StatefulSet is a Kubernetes resource designed to manage stateful applications.
- What is Stateful application ?
-
A stateful application is one that maintains the state of its interactions over time. This means that the application keeps track of user sessions, data, and other contextual information between requests.
-
example:
Online shopping platforms that remember items in a user’s cart.
Social media applications that keep track of user preferences and interactions.
-
In Kubernetes, we send the request to service and then service will forward the request to its end points (means to pod).
Let’s take an example that we have 2 pods are running. If we perform some task on pod 1 then it will never reflect to pod2. For an example, if we created some users or groups on POD1 , but on POD2 these changes will be not reflected. After sometime, we again check these user status, but this time, our service send the request to POD2, you will observe nothing.
In order to resolve this issue, we attach the database with these pods. It means that whenever we do any modification, it will write on the database. Hence, we can say that the state of our application is always maintain.
- A StatefulSet is a Kubernetes resource designed to manage stateful applications.
- Unlike a Deployment, which is suitable for stateless applications, a StatefulSet provides guarantees about the uniqueness of pods and ordering.
Let’s understand the meaning of uniqueness of pods. We have one statefulSet is running called, nginx.
[root@master1 ~]# kubectl get statefulsets
NAME READY AGE
nginx 3/3 114s
If we explore the pods.
[root@master1 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 119s
nginx-1 1/1 Running 0 93s
nginx-2 1/1 Running 0 41s
Let's delete first pod.
[root@master1 ~]# kubectl delete pod/nginx-0
pod "nginx-0" deleted
Again explore the pods, you will notice that same pod name will be there. It means that it maintain the name of pod.Thus, we can say that in StatefulSet, it maintain the uniqueness of pods.
[root@master1 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-0 1/1 Running 0 21s
nginx-1 1/1 Running 0 2m6s
nginx-2 1/1 Running 0 74s
Now, understand the meaning of ordering of pod.
When we create the StatefulSet, it create first pod, once this pod is up and running after that it create the 2nd POD and then 3rd Pod.
At the time of upgrade the StatefulSet, it first delete the higher number of Pod, in this example, it will delete the pod-2 and then created a new version of POD2 and so on. See the below picture.
- A StatefulSet is a Kubernetes resource designed to manage stateful applications.
- Unlike a Deployment, which is suitable for stateless applications, a StatefulSet provides guarantees about the ordering and uniqueness of pods.
- This is crucial for applications that require stable identities, persistent storage, and ordered deployment and scaling.
From the above picture, we can say that each pod has its own PV. If one pod goes down and re-create, it will attach to same PV. Which means that no data loss.
Key Features of StatefulSets
1.Stable Network Identity: Each pod in a StatefulSet has a unique, stable hostname that persists across rescheduling.
2.Stable Storage: StatefulSets can be associated with PersistentVolumeClaims (PVCs) that ensure data is retained even if the pod is deleted or rescheduled.
3.Ordered Deployment and Scaling: Pods are created, updated, and deleted in a specific order, ensuring that the application can maintain its state.
4.Graceful Termination: Pods are terminated in reverse order, allowing for a controlled shutdown process.
Use Cases for StatefulSets
- Databases: Such as MySQL, PostgreSQL, or Cassandra, where data consistency and identity are crucial.
- Distributed Systems: Like Kafka or Zookeeper, where nodes need to maintain their state and identity.
- Applications with Persistent Data: Any application that requires persistent storage and stable network identities.
Difference between SatefulSet and Deployment
Components of a StatefulSet
When configuring a StatefulSet, several key components come into play:
- Pod Template: Defines the specifications for the pods created by the StatefulSet.
- Volume Claim Template: Specifies the persistent volume claims for each pod, ensuring that each pod has its own storage.
- Headless Services: Used to manage the network identities of the pods. A headless service does not have a cluster IP, allowing clients to connect directly to the pods.
- Storage Classes: Defines the type of storage used for persistent volumes.
- Labels and Selectors: Used to organize and manage the pods within the StatefulSet.
Basic Configuration of a StatefulSet
Creating a StatefulSet involves defining the necessary components in a YAML file. Here’s a basic example:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: mysql
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
Advanced Configuration: Volume Claim Templates
In more complex configurations, the volume claim template allows for the creation of dedicated persistent volumes for each pod. This ensures that data remains consistent and is not affected by the lifecycle of other pods.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: my-statefulset
spec:
serviceName: "my-service"
replicas: 2
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
ports:
- containerPort: 80
volumeMounts:
- name: my-storage
mountPath: /data
volumeClaimTemplates:
- metadata:
name: my-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
Create a Headless service for statefulSet
What is Headless service?
A Kubernetes headless Service allows a client to connect to whichever Pod it prefers, directly. It doesn’t route the client request like a regular Service does.
In simple words, we can say that In a StatefulSet, a headless service is often used to enable direct communication between pods without the need for a load balancer. This allows applications to connect to specific pods based on their stable identities, facilitating better management of stateful applications.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
clusterIP: None # Headless service
selector:
app: mysql
ports:
- port: 80
targetPort: 80
Scaling Operations
StatefulSets support both manual and automatic scaling:
- Manual Scaling: You can increase or decrease the number of replicas in the StatefulSet by modifying the replica count in the configuration.
- Automatic Scaling: Horizontal Pod Autoscaler (HPA) can be used to scale pods based on CPU utilization or other select metrics.
Upgrade Strategies
When it comes to upgrading StatefulSets, there are several strategies to consider:
- Blue/Green Deployment: This strategy involves maintaining two identical environments, allowing for a seamless switch between the old and new versions.
- Canary Releases: In this approach, a new version is released to a small subset of users before rolling it out to everyone.
- Rolling Updates: This method updates the pods incrementally, replacing old versions with new ones gradually.
Blue/Green Deployment Strategy
Blue/Green deployment is a change management strategy that minimizes downtime and risk during application updates. It involves maintaining two identical environments: one active (Blue) and one inactive (Green).
How Blue/Green Deployment Works
- Deploy the new version of the application to the inactive environment (Green).
- Thoroughly test the new version to ensure everything works correctly.
- Once verified, switch the load balancer to direct traffic to the Green environment.
- If issues arise, revert traffic back to the Blue environment quickly.
Advantages of Blue/Green Deployment
- Minimizes downtime during updates
- Allows easy rollback in case of issues
Considerations
While Blue/Green deployments offer many benefits, they require duplicate infrastructure, which can lead to increased costs. Organizations with tighter budgets might consider other strategies, such as Canary deployments or Rolling updates.
Conclusion
StatefulSets are a powerful feature in Kubernetes, allowing for the management of stateful applications with unique identities and persistent storage. Understanding the differences between StatefulSets and Deployments, as well as the key features and configurations, is essential for effectively deploying stateful applications in a Kubernetes environment.
As you explore Kubernetes further, consider how you can leverage StatefulSets for your applications that require stability and persistence. Whether it’s for databases, distributed systems, or any application with persistent data needs, StatefulSets can provide the structure and reliability you require.
Made with blog using What is a StatefulSet and Its Key Features? | StatefulSet vs Deployment