Storage
Mobility
Protection
Analysis and control
TOPICShare
What Is Kubernetes Deployment?A Deployment is a Kubernetes resource object used for declarative application updates. Deployments allow you to define the lifecycle of applications, including the container images they use, the number of pods and the manner of updating them.
Deployments are fully managed by the backend in Kubernetes, with the entire update process being server side, with no client involvement. They ensure that a specified number of pods are always running and available. The entire update process is recorded, with versioning to provide options for pausing, resuming or rolling back to previous versions. |
What Is Kubernetes StatefulSet?A StatefulSet is a workload API object for managing stateful applications. Usually, Kubernetes users are not concerned with how pods are scheduled, although they do require pods to be deployed in order, to be attached to persistent storage volumes, and to have unique, persistent network IDs that are retained through rescheduling. StatefulSets can help achieve these objectives.
Like Deployments, StatefulSets manage the pods based on the same container specifications. However, they differ from deployments in that they maintain sticky identities for each pod. Pods may be created from an identical spec, but they are not interchangeable and are thus assigned unique identifiers that persist through rescheduling. |
This article is part of our series about Kubernetes storage.
In this article:
- How Do Kubernetes Deployment and StatefulSets Work?
- Kubernetes StatefulSets vs Deployment: Use Cases and Examples
- Kubernetes Storage Optimization with Cloud Volumes ONTAP
How Do Kubernetes Deployment and StatefulSets Work?
Deployment
Deployments allow you to manage sets of identical pods (or ReplicaSets) using common configurations. Once you’ve defined and deployed a Deployment, Kubernetes ensures that the pods it manages meet the requirements you’ve set. This provides granular control over the rollout of new pod versions and rollback to previous versions.
Deployments are typically used for stateless applications, but you can save a deployment’s state by attaching a persistent volume and making it stateful. All deployed pods share the same volume, with the same data.
The controller verifies if the current state matches the deployment’s desired set, and creates a ReplicaSet if necessary, which then creates the pods. The major components of a deployment are the deployment template, the persistent volumes and the service.
Related content: read our guide to Kubernetes Persistent Volumes
StatefulSets
In a StatefulSet, each pod is given a name and treated individually, in contrast to a Kubernetes Deployment, where pods are easily replaceable. Stateful applications require pods with unique identities. This means that if any pod dies, it is immediately noticeable.
Every pod in a StatefulSet has two unique, stable identities (a network ID and a storage ID). The network ID enables the pod’s DNS name to persist across rescheduling (although the IP addresses may still change). The storage ID is retained regardless of the node the storage instance is rescheduled on. Persistent storage is required to enable the application to save the state and data across restarts.
StatefulSets serve as controllers, but they don’t create ReplicaSets—they create uniquely named pods, according to a specified pattern. The DNS name of a pod includes the ordinal index.
Each replica in a StatefulSet has its own state, with a unique persistent volume claim (PVC) created for each pod. For example, a StatefulSet with four replicas creates four pods, which each have their own volume, amounting to four PVCs.
StatefulSets require a headless service to return the IPs of the associated pods and enable direct interaction with them. The headless service has a service IP but no IP address and has to be created separately.
The major components of a StatefulSet are the set itself, the persistent volume and the headless service.
Related content: read our guide to Kubernetes StatefulSet
Key Differences
Here are the main differences between Deployments and StatefulSets:
- Deployments are used for stateless applications, StatefulSets for stateful applications
- The pods in a deployment are interchangeable, whereas the pods in a StatefulSet are not.
- Deployments require a service to enable interaction with pods, while a headless service handles the pods’ network ID in StatefulSets.
- In a deployment, the replicas all share a volume and PVC, while in a StatefulSet each pod has its own volume and PVC.
Kubernetes StatefulSets vs Deployment: Use Cases and Examples
Use a Deployment for Interchangeable Pods
Deployments are suited to cases where scaling up simply requires running more pods that are interchangeable.
For example, if you have a deployment of a Rust-based web application, traffic is routed to a single application instance by the load balancer at the front, which is provided via Kubernetes Services. The application retains all the state in its relational database, so you only need to request more copies if you want to scale up. The Kubernetes Deployment Controller will start instantly and create all the new pods.
The new pods have the same set of environment variables and ConfigMaps when booting, which presumably allows them to communicate with the database in the same way as the original pod.
The most appropriate use cases for deployments are stateless application workloads or cases that only require replicas of a single pod.
Use a StatefulSet for Unique Pods
StatefulSets are suitable for scaling stateful systems. For example, consider a relational database system behind your application with a deployment. You may want to scale up the app to build leader/follower topology based on consensus. However, you cannot implement a leader-election protocol for pods without identities.
When you scale a StatefulSet from one replica to three, for example, the StatefulSet controller will begin to deploy new (or missing) pods incrementally. The first pod will come up, initialize and finally settle into a “ready” state, followed by the second pod and so on.
A powerful feature of StatefulSets is the concept of PersistentVolumeClaim templates, which allow the provision of a unique persistent volume to each pod in a set. This is critical for replicating information such as the contents of a database.
The most appropriate use cases for StatefulSets include data services like key-value stores or databases, identity-sensitive systems like leader-election and consensus systems, or any workload that requires gradual roll-out.
Kubernetes Storage Optimization with Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP capacity can scale into the petabytes, and it supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP supports Managing Stateful Applications in Kubernetes and Kubernetes Persistent Volume provisioning and management requirements of containerized workloads.
Learn more about how Cloud Volumes ONTAP helps to address the challenges of containerized applications in these Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.
