|
| 1 | +--- |
| 2 | +title: Controllers |
| 3 | +content_template: templates/concept |
| 4 | +weight: 30 |
| 5 | +--- |
| 6 | + |
| 7 | +{{% capture overview %}} |
| 8 | + |
| 9 | +In robotics and automation, a _control loop_ is |
| 10 | +a non-terminating loop that regulates the state of a system. |
| 11 | + |
| 12 | +Here is one example of a control loop: a thermostat in a room. |
| 13 | + |
| 14 | +When you set the temperature, that's telling the thermostat |
| 15 | +about your *desired state*. The actual room temperature is the |
| 16 | +*current state*. The thermostat acts to bring the current state |
| 17 | +closer to the desired state, by turning equipment on or off. |
| 18 | + |
| 19 | +{{< glossary_definition term_id="controller" length="short">}} |
| 20 | + |
| 21 | +{{% /capture %}} |
| 22 | + |
| 23 | + |
| 24 | +{{% capture body %}} |
| 25 | + |
| 26 | +## Controller pattern |
| 27 | + |
| 28 | +A controller tracks at least one Kubernetes resource type. |
| 29 | +These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) |
| 30 | +have a spec field that represents the desired state. The |
| 31 | +controller(s) for that resource are responsible for making the current |
| 32 | +state come closer to that desired state. |
| 33 | + |
| 34 | +The controller might carry the action out itself; more commonly, in Kubernetes, |
| 35 | +a controller will send messages to the |
| 36 | +{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} that have |
| 37 | +useful side effects. You'll see examples of this below. |
| 38 | + |
| 39 | +{{< comment >}} |
| 40 | +Some built-in controllers, such as the namespace controller, act on objects |
| 41 | +that do not have a spec. For simplicity, this page omits explaining that |
| 42 | +detail. |
| 43 | +{{< /comment >}} |
| 44 | + |
| 45 | +### Control via API server |
| 46 | + |
| 47 | +The {{< glossary_tooltip term_id="job" >}} controller is an example of a |
| 48 | +Kubernetes built-in controller. Built-in controllers manage state by |
| 49 | +interacting with the cluster API server. |
| 50 | + |
| 51 | +Job is a Kubernetes resource that runs a |
| 52 | +{{< glossary_tooltip term_id="pod" >}}, or perhaps several Pods, to carry out |
| 53 | +a task and then stop. |
| 54 | + |
| 55 | +(Once [scheduled](/docs/concepts/scheduling/), Pod objects become part of the |
| 56 | +desired state for a kubelet). |
| 57 | + |
| 58 | +When the Job controller sees a new task it makes sure that, somewhere |
| 59 | +in your cluster, the kubelets on a set of Nodes are running the right |
| 60 | +number of Pods to get the work done. |
| 61 | +The Job controller does not run any Pods or containers |
| 62 | +itself. Instead, the Job controller tells the API server to create or remove |
| 63 | +Pods. |
| 64 | +Other components in the |
| 65 | +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} |
| 66 | +act on the new information (there are new Pods to schedule and run), |
| 67 | +and eventually the work is done. |
| 68 | + |
| 69 | +After you create a new Job, the desired state is for that Job to be completed. |
| 70 | +The Job controller makes the current state for that Job be nearer to your |
| 71 | +desired state: creating Pods that do the work you wanted for that Job, so that |
| 72 | +the Job is closer to completion. |
| 73 | + |
| 74 | +Controllers also update the objects that configure them. |
| 75 | +For example: once the work is done for a Job, the Job controller |
| 76 | +updates that Job object to mark it `Finished`. |
| 77 | + |
| 78 | +(This is a bit like how some thermostats turn a light off to |
| 79 | +indicate that the your room is now at the temperature you set). |
| 80 | + |
| 81 | +### Direct control |
| 82 | + |
| 83 | +By contrast with Job, some controllers need to make changes to |
| 84 | +things outside of your cluster. |
| 85 | + |
| 86 | +For example, if you use a control loop to make sure there |
| 87 | +are enough {{< glossary_tooltip text="Nodes" term_id="node" >}} |
| 88 | +in your cluster, then that controller needs something outside the |
| 89 | +current cluster to set up new Nodes when needed. |
| 90 | + |
| 91 | +Controllers that interact with external state find their desired state from |
| 92 | +the API server, then communicate directly with an external system to bring |
| 93 | +the current state closer in line. |
| 94 | + |
| 95 | +(There actually is a controller that horizontally scales the |
| 96 | +nodes in your cluster. See |
| 97 | +[Cluster autoscaling](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)). |
| 98 | + |
| 99 | +## Desired versus current state {#desired-vs-current} |
| 100 | + |
| 101 | +Kubernetes takes a cloud-native view of systems, and is able to handle |
| 102 | +constant change. |
| 103 | + |
| 104 | +Your cluster could be changing at any point as work happens and |
| 105 | +control loops automatically fix failures. This means that, |
| 106 | +potentially, your cluster never reaches a stable state. |
| 107 | + |
| 108 | +As long as the controllers for your cluster are running and able to make |
| 109 | +useful changes, it doesn't matter if the overall state is or is not stable. |
| 110 | + |
| 111 | +## Design |
| 112 | + |
| 113 | +As a tenet of its design, Kubernetes uses lots of controllers that each manage |
| 114 | +a particular aspect of cluster state. Most commonly, a particular control loop |
| 115 | +(controller) uses one kind of resource as its desired state, and has a different |
| 116 | +kind of resource that it manages to make that desired state happen. |
| 117 | + |
| 118 | +It's useful to have simple controllers rather than one, monolithic set of control |
| 119 | +loops that are interlinked. Controllers can fail, so Kubernetes is designed to |
| 120 | +allow for that. |
| 121 | + |
| 122 | +For example: a controller for Jobs tracks Job objects (to discover |
| 123 | +new work) and Pod object (to run the Jobs, and then to see when the work is |
| 124 | +finished). In this case something else creates the Jobs, whereas the Job |
| 125 | +controller creates Pods. |
| 126 | + |
| 127 | +{{< note >}} |
| 128 | +There can be several controllers that create or update the same kind of object. |
| 129 | +Behind the scenes, Kubernetes controllers make sure that they only pay attention |
| 130 | +to the resources linked to their controlling resource. |
| 131 | + |
| 132 | +For example, you can have Deployments and Jobs; these both create Pods. |
| 133 | +The Job controller does not delete the Pods that your Deployment created, |
| 134 | +because there is information ({{< glossary_tooltip term_id="label" text="labels" >}}) |
| 135 | +the controllers can use to tell those Pods apart. |
| 136 | +{{< /note >}} |
| 137 | + |
| 138 | +## Ways of running controllers {#running-controllers} |
| 139 | + |
| 140 | +Kubernetes comes with a set of built-in controllers that run inside |
| 141 | +the {{< glossary_tooltip term_id="kube-controller-manager" >}}. These |
| 142 | +built-in controllers provide important core behaviors. |
| 143 | + |
| 144 | +The Deployment controller and Job controller are examples of controllers that |
| 145 | +come as part of Kubernetes itself (“built-in” controllers). |
| 146 | +Kubernetes lets you run a resilient control plane, so that if any of the built-in |
| 147 | +controllers were to fail, another part of the control plane will take over the work. |
| 148 | + |
| 149 | +You can find controllers that run outside the control plane, to extend Kubernetes. |
| 150 | +Or, if you want, you can write a new controller yourself. |
| 151 | +You can run your own controller as a set of Pods, |
| 152 | +or externally to Kubernetes. What fits best will depend on what that particular |
| 153 | +controller does. |
| 154 | + |
| 155 | +{{% /capture %}} |
| 156 | + |
| 157 | +{{% capture whatsnext %}} |
| 158 | +* Read about the [Kubernetes control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) |
| 159 | +* Discover some of the basic [Kubernetes objects](https://kubernetes.io/docs/concepts/#kubernetes-objects) |
| 160 | +* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) |
| 161 | +* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. |
| 162 | +{{% /capture %}} |
0 commit comments