Copy /en/docs/concepts/architecture/controller.md into /ja directory.
This commit is contained in:
TAKAHASHI Shuuji
@@ -0,0 +1,162 @@
|
||||
---
|
||||
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/#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 %}}
|
||||
Reference in New Issue
Block a user