163 lines
6.6 KiB
Markdown
163 lines
6.6 KiB
Markdown
---
|
|
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.
|
|
|
|
{{< glossary_definition term_id="controller" length="short">}}
|
|
|
|
{{% /capture %}}
|
|
|
|
|
|
{{% capture body %}}
|
|
|
|
## Controller pattern
|
|
|
|
A controller tracks at least one Kubernetes resource type.
|
|
These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
|
have a spec field that represents the desired state. 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. You'll see examples of this below.
|
|
|
|
{{< comment >}}
|
|
Some built-in controllers, such as the namespace controller, act on objects
|
|
that do not have a spec. For simplicity, this page omits explaining that
|
|
detail.
|
|
{{< /comment >}}
|
|
|
|
### Control via API server
|
|
|
|
The {{< glossary_tooltip term_id="job" >}} controller is an example of a
|
|
Kubernetes built-in controller. Built-in controllers manage state by
|
|
interacting with the cluster API server.
|
|
|
|
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
|
|
Pods.
|
|
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 for that Job be nearer to your
|
|
desired state: creating Pods that do the work you wanted for that Job, so that
|
|
the Job is closer to completion.
|
|
|
|
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 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.
|
|
|
|
Controllers that interact with external state find their desired state from
|
|
the API server, then communicate 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](/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.
|
|
|
|
As long as the controllers for your cluster are running and able to make
|
|
useful changes, it doesn't matter if the overall state is or is not stable.
|
|
|
|
## 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 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
|
|
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](/docs/concepts/#kubernetes-control-plane)
|
|
* Discover some of the basic [Kubernetes objects](/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 %}}
|