From e8719723dcb6b97ae1436634ad02548359cee5a8 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Tue, 31 Mar 2020 19:55:24 -0700 Subject: [PATCH] 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. --- content/en/docs/concepts/architecture/controller.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md index e5bee1d0a5..0021fc2a74 100644 --- a/content/en/docs/concepts/architecture/controller.md +++ b/content/en/docs/concepts/architecture/controller.md @@ -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