whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add concept page about Controllers (#15733)

Browse Source 
* Add controller concept

* Fix controller glossary entries

* Link from Understanding Kubernetes Objects to Controllers
This commit is contained in:
Tim Bannister
2019-10-02 18:06:08 +01:00
committed by Kubernetes Prow Robot
parent bf83aaf699
commit 9a7b191bcc
14 changed files with 203 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/glossary/controller.md
+15 -4
View File
@@ -2,7 +2,7 @@
title: Controller
id: controller
date: 2018-04-12
full_link: /docs/admin/kube-controller-manager/
full_link: /docs/concepts/architecture/controller/
short_description: >
A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
@@ -11,9 +11,20 @@ tags:
- architecture
- fundamental
---
A control loop that watches the shared state of the cluster through the {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} and makes changes attempting to move the current state towards the desired state.
In Kubernetes, controllers are control loops that watch the state of your
{{< glossary_tooltip term_id="cluster" text="cluster">}}, then make or request
changes where needed.
Each controller tries to move the current cluster state closer to the desired
state.
<!--more-->
<!--more-->
Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.
Controllers watch the shared state of your cluster through the
{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (part of the
{{< glossary_tooltip term_id="control-plane" >}}).
Some controllers also run inside the control plane, providing control loops that
are core to Kubernetes' operations. For example: the deployment controller, the
daemonset controller, the namespace controller, and the persistent volume
controller (and others) all run within the
{{< glossary_tooltip term_id="kube-controller-manager" >}}.
content/en/docs/reference/glossary/kube-controller-manager.md
+2 -3
View File
@@ -2,7 +2,7 @@
title: kube-controller-manager
id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/generated/kube-controller-manager/
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
Component on the master that runs controllers.
@@ -13,7 +13,6 @@ tags:
---
Component on the master that runs {{< glossary_tooltip text="controllers" term_id="controller" >}}.
<!--more-->
<!--more-->
Logically, each {{< glossary_tooltip text="controller" term_id="controller" >}} is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
content/en/docs/reference/glossary/statefulset.md
-3
View File
@@ -18,6 +18,3 @@ tags:
<!--more-->
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable&#58; each has a persistent identifier that it maintains across any rescheduling.
A StatefulSet operates under the same pattern as any other Controller. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to get there from the current state.