Kubernetes Workload Resources: Difference between revisions
Line 21: | Line 21: | ||
Workload resources: | Workload resources: | ||
* <span id='Deployment'></span>Deployment | * <span id='Deployment'></span>[[Kubernetes Deployments|Deployment]] | ||
* <span id='StatefulSet'></span>StatefulSet | * <span id='StatefulSet'></span>[[Kubernetes StatefulSet|StatefulSet]] | ||
* <span id='DaemonSet'></span>DaemonSet | * <span id='DaemonSet'></span>[[Kubernetes DaemonSet|DaemonSet]] | ||
* <span id='Job'></span> | * <span id='Job'></span>[[Kubernetes Job#Overview|Job]] | ||
* <span id='CronJob'></span> CronJob | * <span id='CronJob'></span>[[Kubernetes CronJob#Overview|CronJob]] | ||
=To Distribute= | =To Distribute= | ||
====ReplicaSet==== | ====ReplicaSet==== |
Revision as of 23:45, 11 July 2023
Internal
Overview
Workload resources exist to create and manage Pods, which should not usually be created directly. Various workload resources implement different pod utilization patterns.
The pod-managing resources described here are some times referred to as higher-level pod controllers or "templated controllers". These controllers are part of and supervised by the controller manager.
TODO
Workload Resource
Describe the relationship between pod, deployment, ReplicaSet and workload resources. Which one are controllers and which are not?
Controller
TODO: https://kubernetes.io/docs/concepts/workloads/pods/#pods-and-controllers
A workload resource has an associated controller. The controller handles replication, rollout and automatic healing in case of pod failure. For example if a node fails, a controller notices that the pods on that node have stopped working and creates replacement pods, which are scheduled on healthy nodes.
Workload resources: