Deployments, StatefulSets, DaemonSets
Deploying Pods¶
Pods are a key resource for Kubernetes. A Pod is the smallest deployable unit in Kubernetes. Pods hold the containers for an application. To help deploy Pods, Kubernetes provides three different options: Deployments, DaemonSets, and StatefulSets.
Note: While ReplicaSets can be used, Kubernetes recommends using Deployments. Deployments use ReplicaSets as a mechanism to orchestrate Pod creation, deletion, and updates.
Stateful vs Stateless¶
In Kubernetes, deploying Pods may depend on if the application needs to save data (stateful) or does not need to save data (stateless). An example is an application that forwards data to a database. The database should be stateful because the data stored in the database needs to be retained if the database should be restarted or replaced. The application that connects to the database might just be forwarding requests to the database; if this is the case, then this application can be stateless because it does not store any data.
Use Cases¶
Deployments
Deployments are designed to manage stateless applications. A Deployment will maintain a set of identical Pods, making sure the appropriate number of Pods are running and upgrading those Pods in a controlled way.
One advantage of a Deployment is the ability to rollback to an earlier revision of the Deployment. This is useful if the current state of the Deployment is not stable and going back to a previous revision is the best solution.
Another advantage is the ability to scale up or down based on the workload. Because the Pods are identical (interchangeable), adding more Pods to share the workload (load balancing) is simple.
Note: It is possible to add a volume to a Deployment, but all of the Pods in the Deployment will share the storage and all of the Pods can modify the same data in the volume. This will not work for databases or other applications where modifying a shared volume will cause data issues.
StatefulSets
StatefulSets manage the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of those Pods. Like a Deployment, a StatefulSet manages Pods based on an identical container specification. Unlike a Deployment, a StatefulSet has a persistent ID for each Pod that persists across any rescheduling or restarts. Because of the persistent ID, the Pods are not interchangeable.
An advantage of a StatefulSet is ensuring that the state of an application is saved. Each Pod has a PersistentVolume (PV) attached to it. If the Pod crashes, the data is not lost; a new Pod is created and attached to the PV. An example is having identical copies of a database to provide high availability. Should the primary database crash, there are copies to readily take its place. If the database Pod needs to be replaced, the new Pod created and attached to the existing PV.
Note: StatefulSets do not use ReplicaSets and cannot be rolled back to a previous revision. StatefulSets can only be scaled up, scaled down, or deleted.
DaemonSets
DaemonSets are designed to run one Pod per Node. This ensures that a storage, logging, or monitoring Pod is on every Node. If a Node is added, the DaemonSet will automatically add a Pod to that Node. If a DaemonSet Pod must run on specific Nodes, instead of all Modes, label selectors help identify the Nodes to run on.
Note: StatefulSets do not guarantee one Pod per Node. StatefulSets will deploy the desired number of Pods to any available Nodes.
