-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
167 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,160 @@ | ||
| --- | ||
| title: Controllers | ||
| content_template: templates/concept | ||
| weight: 30 | ||
| --- | ||
|
|
||
| {{% capture overview %}} | ||
|
|
||
| In robotics and automation, a _control loop_ is | ||
| a non-terminating loop that regulates the state of a system. | ||
|
|
||
| Here is one example of a control loop: a thermostat in a room. | ||
|
|
||
| When you set the temperature, that's telling the thermostat | ||
| about your *desired state*. The actual room temperature is the | ||
| *current state*. The thermostat acts to bring the current state | ||
| closer to the desired state, by turning equipment on or off. | ||
|
|
||
| In Kubernetes, a _controller_ is a control loop that watches the | ||
| state of your | ||
| {{< glossary_tooltip term_id="cluster" text="cluster">}}, then | ||
| makes or requests changes. Each controller tries to move the current | ||
| cluster state closer to the desired state. | ||
|
|
||
| {{% /capture %}} | ||
|
|
||
|
|
||
| {{% capture body %}} | ||
|
|
||
| ## Controller pattern | ||
|
|
||
| A controller tracks at least one Kubernetes resource type. | ||
| These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) | ||
| and their associated data are the desired state, so the | ||
| controller(s) for that resource are responsible for making the current | ||
| state come closer to that desired state. | ||
|
|
||
| The controller might carry the action out itself; more commonly, in Kubernetes, | ||
| a controller will send messages to the | ||
| {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} that have | ||
| useful side effects. | ||
|
|
||
| ### Control via API server | ||
|
|
||
| The controller for Job is an example of a built-in controller that | ||
| makes all of its changes by interacting with your cluster's API server. | ||
|
|
||
| {{< glossary_tooltip term_id="job" >}} is a Kubernetes resource that | ||
| runs a {{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, | ||
| to carry out a task and then stop. | ||
|
|
||
| (Once [scheduled](/docs/concepts/scheduling/), Pod objects become part | ||
| of the desired state for a kubelet). | ||
|
|
||
| When the Job controller sees a new task it makes sure that, somewhere | ||
| in your cluster, the kubelets on a set of Nodes are running the right | ||
| number of Pods to get the work done. | ||
| The Job controller does not run any Pods or containers | ||
| itself. Instead, the Job controller tells the API server to create or remove | ||
| Pod [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/). | ||
| Other components in the | ||
| {{< glossary_tooltip text="control plane" term_id="control-plane" >}} | ||
| act on the new information (there are new Pods to schedule and run), | ||
| and eventually the work is done. | ||
|
|
||
| After you create a new Job, the desired state is for that Job to | ||
| be completed. The Job controller makes the current state be nearer | ||
| to the desired state, by creating Pods that do the work you | ||
| wanted. | ||
|
|
||
| Controllers also update the objects that configure them | ||
| For example: once the work is done for a Job, the Job controller | ||
| updates that Job object to mark it `Finished`. | ||
|
|
||
| (This is a bit like how some thermostats turn a light off to | ||
| indicate that the your room is now at the temperature you set). | ||
|
|
||
| ### Direct control | ||
|
|
||
| By contrast with Job, some controllers need to make changes to | ||
| things outside of your cluster. | ||
|
|
||
| For example, if you use a control loop to make sure there | ||
| are enough {{< glossary_tooltip text="Nodes" term_id="node" >}} | ||
| in your cluster, then that controller needs something outside the | ||
| current cluster to set up new Nodes when needed. | ||
|
|
||
| This kind of controller finds its desired state from the API | ||
| server and then communicates directly with an external system | ||
| to bring the current state closer in line. | ||
|
|
||
| (There actually is a controller that horizontally scales the | ||
| nodes in your cluster. See | ||
| [Cluster autoscaling](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). | ||
|
|
||
| ## Desired versus current state {#desired-vs-current} | ||
|
|
||
| Kubernetes takes a cloud-native view of systems, and is able to handle | ||
| constant change. | ||
|
|
||
| Your cluster could be changing at any point as work happens and | ||
| control loops automatically fix failures. This means that, | ||
| potentially, your cluster never reaches a stable state. | ||
|
|
||
| So long as the controllers for your cluster are making useful changes, | ||
| it's OK for the current state to be different from the desired state | ||
| at a particular moment. | ||
|
|
||
| ## Design | ||
|
|
||
| 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. | ||
|
|
||
| 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 Job objects, whereas the Job | ||
| controller creates some Pod objects. | ||
|
|
||
| {{< 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 | ||
| to the resources linked to their controlling resource. | ||
|
|
||
| For example, you can have Deployments and Jobs; these both create Pods. | ||
| The Job controller does not delete the Pods that your Deployment created, | ||
| because there is information ({{< glossary_tooltip term_id="label" text="labels" >}}) | ||
| the controllers can use to tell those Pods apart. | ||
| {{< /note >}} | ||
|
|
||
| ## Ways of running controllers {#running-controllers} | ||
|
|
||
| Kubernetes comes with a set of built-in controllers that run inside | ||
| the {{< glossary_tooltip term_id="kube-controller-manager" >}}. These | ||
| built-in controllers provide important core behaviors. | ||
|
|
||
| The Deployment controller and Job controller are examples of controllers that | ||
| come as part of Kubernetes itself (“built-in” controllers). | ||
| Kubernetes lets you run a resilient control plane, so that if any of the built-in | ||
| controllers were to fail, another part of the control plane will take over the work. | ||
|
|
||
| You can find controllers that run outside the control plane, to extend Kubernetes. | ||
| Or, if you want, you can write a new controller yourself. | ||
| You can run your own controller as a set of Pods, | ||
| or externally to Kubernetes. What fits best will depend on what that particular | ||
| controller does. | ||
|
|
||
| {{% /capture %}} | ||
|
|
||
| {{% capture whatsnext %}} | ||
| * Read about the [Kubernetes control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) | ||
| * Discover some of the basic [Kubernetes objects](https://kubernetes.io/docs/concepts/#kubernetes-objects) | ||
| * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) | ||
| * If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. | ||
| {{% /capture %}} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters