Move the Job controller example
Move the job controller example so that the example of Job controller follows immediately after the concept of what a job controller does in introduced.pull/19999/head
parent
dfea2cb446
commit
09e2f904d2
|
@ -113,17 +113,15 @@ useful changes, it doesn't matter if the overall state is or is not stable.
|
|||
As a tenet of its design, Kubernetes uses lots of controllers that each manage
|
||||
a particular aspect of cluster state. Most commonly, a particular control loop
|
||||
(controller) uses one kind of resource as its desired state, and has a different
|
||||
kind of resource that it manages to make that desired state happen.
|
||||
kind of resource that it manages to make that desired state happen. For example,
|
||||
a controller for Jobs tracks Job objects (to discover new work) and Pod objects
|
||||
(to run the Jobs, and then to see when the work is finished). In this case
|
||||
something else creates the Jobs, whereas the Job controller creates Pods.
|
||||
|
||||
It's useful to have simple controllers rather than one, monolithic set of control
|
||||
loops that are interlinked. Controllers can fail, so Kubernetes is designed to
|
||||
allow for that.
|
||||
|
||||
For example: a controller for Jobs tracks Job objects (to discover
|
||||
new work) and Pod object (to run the Jobs, and then to see when the work is
|
||||
finished). In this case something else creates the Jobs, whereas the Job
|
||||
controller creates Pods.
|
||||
|
||||
{{< note >}}
|
||||
There can be several controllers that create or update the same kind of object.
|
||||
Behind the scenes, Kubernetes controllers make sure that they only pay attention
|
||||
|
|
Loading…
Reference in New Issue