# Kubernetes Workload Resources

## OpenShift DeploymentConfig v.s. Kubernetes Deployment

Here are the comparison beetween **DeploymentConfig** and **Deployment**:

| | DeploymentConfig | Deployment |
| --------------- | ---------------------------------------------------------------------------------- | ------------------ |
| Manager | ReplicationController | ReplicaSet |
| Selector | Equality-based selector | Set-based selector |
| CAP | Consistency | Availability |
| Auto-Rollback | Rollback on Failure | N/A |
| Trigger | Such as new deployment on config change | N/A |
| Lifecycle hooks | Executing custom behavior in different points during the lifecycle of a deployment | N/A |

The official doc of OpenShift suggest to use Deployment instead of DeploymentConfig if you have no specific requirements.

## ReplicationController (DeploymentConfig)

* Features
* Ensure the number of pods
* Ensure the health of pods
* Scalability
* Rolling Update
* Rely on **label** and **selector** to manage pods
* The labels of pods should equal to those in the slector of DeploymentConfig
* Otherwise, the DeploymentConfig would keep creating new pods.

## ReplicaSet (Deployment)

ReplicaSet is said to be upgraded DeploymentConfig. However, they don't show large difference on behaviors.

* Key Difference
* Support set-based selector

Also, the official doc of Kubernetes suggest to use Deployment to create Pod and ReplicaSet for Deployment providing declarative updates for them.

## StatefulSets

StatefulSets shows almost same features as the ReplicaSet.

* Key Difference
* Sticky identity for each of pods

It is useful for the following senarios:

* Stable, **unique network identifiers**.
* Stable, **persistent storage**.
* **Ordered**, graceful deployment and scaling.
* **Ordered**, automated rolling updates.

:::info
"Ordered" means that the update or creation of pods is ordered and one by one. For example, if you deploy 4 pods, the deployed order is 1, 2, 3 , 4. Then you remove them, the removed order is 4, 3, 2, 1.
:::

## DaemonSet

DaemonSet will run a pod on each Node, so no matter you create or remove the Node, you will remove a Pod.

So, the senarios is mostly about monitoring and logs collection:

* running a cluster storage daemon on every node
* running a logs collection daemon on every node
* running a node monitoring daemon on every node

By the way, DaemonSet do not support RollBack.

## References

* [Understanding Deployments and DeploymentConfigs - Deployments | Building applications | OpenShift Container Platform 4.11](https://docs.openshift.com/container-platform/4.11/applications/deployments/what-deployments-are.html)
* [Deployments | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
* [ReplicaSet | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)
* [ReplicationController | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/)
* [StatefulSets | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
* [DaemonSet | Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
* [How to achieve Automatic Rollback in Kubernetes? - Stack Overflow](https://stackoverflow.com/questions/69468977/how-to-achieve-automatic-rollback-in-kubernetes)
* [『紅帽』的 Cloud-Native 工作術: 從 Container 到 OpenShift 。 :: 第 12 屆 iThome 鐵人賽](https://ithelp.ithome.com.tw/users/20130321/ironman/3566)
* [Kubernetes 30天學習筆記 :: 2018 iT 邦幫忙鐵人賽](https://ithelp.ithome.com.tw/users/20103753/ironman/1590)
* [[Kubernetes] ReplicaSet 介紹 | 小信豬的原始部落](https://godleon.github.io/blog/Kubernetes/k8s-ReplicaSet-Overview/)