Add kube-apiserver, kube-controller-manager, kube-scheduler and etcd to glossary. (#6600)

* Move master component definitions to glossary

* review comments

* Update controller.yaml

Making a trivial change to un-stuck Travis

* Update controller.yaml

Removing trivial change

_data/glossary/controller.yaml

@@ -0,0 +1,12 @@
+id: controller
+name: Controller
+full-link: /docs/admin/kube-controller-manager/
+related:
+- controller-manager
+tags:
+- architecture
+- fundamental
+short-description: >
+  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.
+long-description: >
+  Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.

_data/glossary/etcd.yaml

@@ -0,0 +1,11 @@
+id: etcd
+name: etcd
+full-link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+tags:
+- architecture
+- storage
+short-description: >
+  Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
+long-description: >
+  Always have a backup plan for etcd's data for your Kubernetes cluster.
+  For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).

_data/glossary/kube-apiserver.yaml

@@ -0,0 +1,12 @@
+id: kube-apiserver
+name: kube-apiserver
+full-link: /docs/reference/generated/kube-apiserver/
+aka:
+- apiserver
+tags:
+- architecture
+- fundamental
+short-description: >
+  Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. 
+long-description: >
+  It is designed to scale horizontally -- that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/).

_data/glossary/kube-controller-manager.yaml

@@ -0,0 +1,14 @@
+id: kube-controller-manager
+name: kube-controller-manager
+full-link: /docs/reference/generated/kube-controller-manager/
+aka:
+- controller-manager
+related:
+- controller
+tags:
+- architecture
+- fundamental
+short-description: >
+  Component on the master that runs {% glossary_tooltip text="controllers" term_id="controller" %}.
+long-description: >
+  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.

_data/glossary/kube-scheduler.yaml

@@ -0,0 +1,13 @@
+id: kube-scheduler
+name: kube-scheduler
+full-link: /docs/reference/generated/kube-scheduler/
+aka:
+- scheduler
+tags:
+- architecture
+short-description: >
+  Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.
+long-description: >
+  Factors taken into account for scheduling decisions include individual and collective resource requirements, 
+  hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference
+  and deadlines.

docs/concepts/overview/components.md

@@ -22,16 +22,19 @@ the same VM, and do not run user containers on this VM. See
 
 ### kube-apiserver
 
-[kube-apiserver](/docs/admin/kube-apiserver/) exposes the Kubernetes API. It is the front-end for the
-Kubernetes control plane. It is designed to scale horizontally -- that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/).
+{% glossary_definition term_id="kube-apiserver" length="all" %}
 
 ### etcd
 
-[etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd/) is used as Kubernetes' backing store. All cluster data is stored here. Always have a backup plan for etcd's data for your Kubernetes cluster.
+{% glossary_definition term_id="etcd" length="all" %}
+
+### kube-scheduler
+
+{% glossary_definition term_id="kube-scheduler" length="all" %}
 
 ### kube-controller-manager
 
-[kube-controller-manager](/docs/admin/kube-controller-manager/) runs controllers, which are the background threads that handle routine tasks in the cluster. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
+{% glossary_definition term_id="kube-controller-manager" length="all" %}
 
 These controllers include:
 
@@ -56,11 +59,6 @@ The following controllers have cloud provider dependencies:
   * Service Controller: For creating, updating and deleting cloud provider load balancers
   * Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
 
-### kube-scheduler
-
-[kube-scheduler](/docs/admin/kube-scheduler/) watches newly created pods that
-are not assigned to any node, and selects a node for them to run on.
-
 ### addons
 
 Addons are pods and services that implement cluster features. The pods may be managed

docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -5,7 +5,7 @@ approvers:
 title: Operating etcd clusters for Kubernetes
 ---
 
-etcd is a strong, consistent, and highly-available key value store which Kubernetes uses for persistent storage of all of its API objects. This documentation provides specific instruction on operating, upgrading, and rolling back etcd clusters for Kubernetes. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
+{% glossary_definition term_id="etcd" length="all" prepend="etcd is a "%}
 
 <!-- TODO(mml): Write this doc.