Kubernetes is an object-oriented framework for orchestration of Docker containers. While running basic Kubernetes objects like pods and services is essential to all Kubernetes applications, the type of controller to use should be based on several factors.
Let’s explore the more advanced controller options for additional features.
A replica set provides essentially the same functionality as a replication controller but on a higher level in terms of configuration options.
A replica set is more declarative (additional configuration file settings) compared to a replication controller, which is more imperative (command line). For example, a replica set supports set-based selectors for selecting a value, such as version in (v1,v2,v3) rather than designating version=v2.
A replica set does not have a provision for making updates, so it’s best used if an application is designed never to be updated.
While you could provision a standalone replica set, it is recommended that you use it with a deployment, which is a higher-level controller than a replica set.
Just like the other controllers, a deployment is used to run a pod at a desired number of replicas. A deployment is associated with a specification that includes additional configuration over a standalone pod, replication controller, or a replica set, such as what deployment strategy to use.
When the application version is updated, the default deployment strategy is a rolling update because it allows keeping multiple versions of the deployment. The other strategy is to recreate pods, which removes the earlier version and creates a new version.
The controllers discussed so far do not apply any uniqueness to a pod in terms of network or storage. Upon rescheduling, a pod could get a different DNS, hostname, and persistent storage. In a rolling update, any of the pods could be updated first; no ordering is kept in scaling and updates. One pod is interchangeable with another.
A stateful set is a level above a deployment in that it keeps the unique identities of the pods. One pod is not the same as another in terms of their associated network and storage. In scaling or a rolling update, a cluster of pods are handled in an ordered manner. The DNS, hostname, and persistent storage associated with a pod are the same across pod rescheduling.
Use deployment for stateless applications, such as HTTP servers, and use a stateful set for stateful applications, such as databases.
A daemon set is a controller that runs exactly one pod on each node in a cluster. It may be configured to use a node selector to run one pod on each of the nodes that meet a certain criterion rather than all the pods. For example, you can add a new node to a cluster that has a daemon set running, as illustrated in figure 2.
Because a daemon set is running, a pod is started on the new third node, as illustrated in figure 3.
As storage, logging, and monitoring need to be performed on each node in a cluster, you can use a daemon set for running a cluster storage daemon, a log collection daemon, and a monitoring daemon. A daemon set adds the requisite pod on each new node.
