Add cross-references to fundamental concepts (#18092)

content/en/docs/reference/glossary/annotation.md

@@ -14,5 +14,5 @@ tags:
 
 <!--more--> 
 
-The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels. Clients such as tools and libraries can retrieve this metadata.
+The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by {{< glossary_tooltip text="labels" term_id="label" >}}. Clients such as tools and libraries can retrieve this metadata.
 

content/en/docs/reference/glossary/cluster.md

@@ -11,7 +11,13 @@ tags:
 - fundamental
 - operation
 ---
-A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
+A set of worker machines, called {{< glossary_tooltip text="nodes" term_id="node" >}},
+that run containerized applications. Every cluster has at least one worker node.
 
 <!--more-->
-The worker node(s) host the pods that are the components of the application. The Control Plane manages the worker nodes and the pods in the cluster. In production environments, the Control Plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
+The worker node(s) host the {{< glossary_tooltip text="Pods" term_id="pod" >}} that are
+the components of the application workload. The
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}} manages the worker
+nodes and the Pods in the cluster. In production environments, the control plane usually
+runs across multiple computers and a cluster usually runs multiple nodes, providing
+fault-tolerance and high availability.

content/en/docs/reference/glossary/container-env-variables.md

@@ -10,8 +10,8 @@ aka:
 tags:
 - fundamental
 ---
- Container environment variables are name=value pairs that provide useful information into containers running in a Pod.
+ Container environment variables are name=value pairs that provide useful information into containers running in a {{< glossary_tooltip text="pod" term_id="pod" >}}
 
 <!--more-->
 
-Container environment variables provide information that is required by the running containerized applications along with information about important resources to the {{< glossary_tooltip text="Containers" term_id="container" >}}. For example, file system details, information about the container itself, and other cluster resources such as service endpoints.
+Container environment variables provide information that is required by the running containerized applications along with information about important resources to the {{< glossary_tooltip text="containers" term_id="container" >}}. For example, file system details, information about the container itself, and other cluster resources such as service endpoints.

content/en/docs/reference/glossary/deployment.md

@@ -16,5 +16,5 @@ tags:
 
 <!--more--> 
 
-Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the Pods are distributed among the nodes of a cluster.
+Each replica is represented by a {{< glossary_tooltip term_id="pod" >}}, and the Pods are distributed among the {{< glossary_tooltip text="nodes" term_id="node" >}} of a cluster.
 

content/en/docs/reference/glossary/horizontal-pod-autoscaler.md

@@ -11,9 +11,9 @@ aka:
 tags:
 - operation
 ---
- An API resource that automatically scales the number of pod replicas based on targeted CPU utilization or custom metric targets.
+ An API resource that automatically scales the number of {{< glossary_tooltip term_id="pod" >}} replicas based on targeted CPU utilization or custom metric targets.
 
 <!--more--> 
 
-HPA is typically used with {{< glossary_tooltip text="Replication Controllers" term_id="replication-controller" >}}, {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, or Replica Sets. It cannot be applied to objects that cannot be scaled, for example {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}.
+HPA is typically used with {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}, {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, or {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}. It cannot be applied to objects that cannot be scaled, for example {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}.
 

content/en/docs/reference/glossary/host-aliases.md

@@ -10,7 +10,7 @@ aka:
 tags:
 - operation
 ---
- A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file.
+ A HostAliases is a mapping between the IP address and hostname to be injected into a {{< glossary_tooltip text="Pod" term_id="pod" >}}'s hosts file.
 
 <!--more-->
 

content/en/docs/reference/glossary/image.md

@@ -10,9 +10,9 @@ aka:
 tags:
 - fundamental
 ---
- Stored instance of a container that holds a set of software needed to run an application.
+ Stored instance of a {{< glossary_tooltip term_id="container" >}} that holds a set of software needed to run an application.
 
-<!--more--> 
+<!--more-->
 
 A way of packaging software that allows it to be stored in a container registry, pulled to a local system, and run as an application. Meta data is included in the image that can indicate what executable to run, who built it, and other information.
 

content/en/docs/reference/glossary/init-container.md

@@ -4,15 +4,14 @@ id: init-container
 date: 2018-04-12
 full_link: 
 short_description: >
-  One or more initialization containers that must run to completion before any app containers run. 
+  One or more initialization containers that must run to completion before any app containers run.
 
 aka: 
 tags:
 - fundamental
 ---
- One or more initialization containers that must run to completion before any app containers run. 
+ One or more initialization {{< glossary_tooltip text="containers" term_id="container" >}} that must run to completion before any app containers run.
 
 <!--more--> 
 
-Initialization (init) containers are like regular app containers, with one difference: init containers must run to completion before any app containers can start. Init containers run in series: each init container must run to completion before the next init container begins.  
-
+Initialization (init) containers are like regular app containers, with one difference: init containers must run to completion before any app containers can start. Init containers run in series: each init container must run to completion before the next init container begins.

content/en/docs/reference/glossary/kube-proxy.md

@@ -11,15 +11,17 @@ tags:
 - fundamental
 - networking
 ---
- [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) is a
-network proxy that runs on each node in your cluster, implementing part of
-the Kubernetes {{< glossary_tooltip term_id="service">}} concept.
+ kube-proxy is a network proxy that runs on each
+{{< glossary_tooltip text="node" term_id="node" >}} in your cluster,
+implementing part of the Kubernetes
+{{< glossary_tooltip term_id="service">}} concept.
 
 <!--more-->
 
-kube-proxy maintains network rules on nodes. These network rules allow
-network communication to your Pods from network sessions inside or outside
-of your cluster.
+[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
+maintains network rules on nodes. These network rules allow network
+communication to your Pods from network sessions inside or outside of
+your cluster.
 
 kube-proxy uses the operating system packet filtering layer if there is one
 and it's available. Otherwise, kube-proxy forwards the traffic itself.

content/en/docs/reference/glossary/kube-scheduler.md

@@ -4,15 +4,20 @@ id: kube-scheduler
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-scheduler/
 short_description: >
-  Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
+  Control plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
 
 aka: 
 tags:
 - architecture
 ---
- Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
+Control plane component that watches for newly created
+{{< glossary_tooltip term_id="node" >}} with no assigned
+{{< glossary_tooltip term_id="node" text="node">}}, and selects a node for them
+to run on.
 
-<!--more--> 
-
-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.
+<!--more-->
 
+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.

content/en/docs/reference/glossary/kubeadm.md

@@ -15,5 +15,5 @@ tags:
 
 <!--more--> 
 
-You can use kubeadm to install both the control plane and the worker node components.
+You can use kubeadm to install both the control plane and the {{< glossary_tooltip text="worker node" term_id="node" >}} components.
 

content/en/docs/reference/glossary/kubelet.md

@@ -11,9 +11,8 @@ tags:
 - fundamental
 - core-object
 ---
- An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.
+ An agent that runs on each {{< glossary_tooltip text="node" term_id="node" >}} in the cluster. It makes sure that {{< glossary_tooltip text="containers" term_id="container" >}} are running in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
 
 <!--more--> 
 
 The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.
-

content/en/docs/reference/glossary/persistent-volume-claim.md

@@ -11,9 +11,8 @@ tags:
 - core-object
 - storage
 ---
- Claims storage resources defined in a PersistentVolume so that it can be mounted as a volume in a container.
+ Claims storage resources defined in a {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}} so that it can be mounted as a volume in a {{< glossary_tooltip text="container" term_id="container" >}}.
 
 <!--more--> 
 
-Specifies the amount of storage, how the storage will be accessed (read-only, read-write and/or exclusive) and how it is reclaimed (retained, recycled or deleted). Details of the storage itself are in the PersistentVolume specification.
-
+Specifies the amount of storage, how the storage will be accessed (read-only, read-write and/or exclusive) and how it is reclaimed (retained, recycled or deleted). Details of the storage itself are described in the PersistentVolume object.

content/en/docs/reference/glossary/pod-priority.md

@@ -10,7 +10,7 @@ aka:
 tags:
 - operation
 ---
- Pod Priority indicates the importance of a Pod relative to other Pods.
+ Pod Priority indicates the importance of a {{< glossary_tooltip term_id="pod" >}} relative to other Pods.
 
 <!--more-->
 

content/en/docs/reference/glossary/podpreset.md

@@ -10,9 +10,9 @@ aka:
 tags:
 - operation
 ---
- An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time.
+ An API object that injects information such as secrets, volume mounts, and environment variables into {{< glossary_tooltip text="Pods" term_id="pod" >}} at creation time.
 
 <!--more--> 
 
-This object chooses the pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.
+This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration.
 

content/en/docs/reference/glossary/preemption.md

@@ -10,7 +10,7 @@ aka:
 tags:
 - operation
 ---
- Preemption logic in Kubernetes helps a pending Pod to find a suitable Node by evicting low priority Pods existing on that Node.
+ Preemption logic in Kubernetes helps a pending {{< glossary_tooltip term_id="pod" >}} to find a suitable {{< glossary_tooltip term_id="node" >}} by evicting low priority Pods existing on that Node.
 
 <!--more-->
 

content/en/docs/reference/glossary/replication-controller.md

@@ -11,7 +11,7 @@ tags:
 - workload
 - core-object
 ---
- Kubernetes service that ensures a specific number of instances of a pod are always running.
+ Kubernetes service that ensures a specific number of instances of a {{< glossary_tooltip text="Pod" term_id="pod" >}} are always running.
 
 <!--more--> 
 

content/en/docs/reference/glossary/security-context.md

@@ -4,14 +4,20 @@ id: security-context
 date: 2018-04-12
 full_link: /docs/tasks/configure-pod-container/security-context/
 short_description: >
-  The securityContext field defines privilege and access control settings for a Pod or Container, including the runtime UID and GID.
+  The securityContext field defines privilege and access control settings for a Pod or container.
 
 aka: 
 tags:
 - security
 ---
- The securityContext field defines privilege and access control settings for a Pod or Container, including the runtime UID and GID.
+ The `securityContext` field defines privilege and access control settings for
+a {{< glossary_tooltip text="Pod" term_id="pod" >}} or
+{{< glossary_tooltip text="container" term_id="container" >}}.
 
-<!--more--> 
+<!--more-->
 
-The securityContext field in a {{< glossary_tooltip term_id="pod" >}} (applying to all containers) or container is used to set the user, groups, capabilities, privilege settings, and security policies (SELinux/AppArmor/Seccomp) and more that container processes use.
+In a `securityContext`, you can define: the user that processes run as,
+the group that processes run as, and privilege settings.
+You can also configure security policies (for example: SELinux, AppArmor or seccomp).
+
+The `PodSpec.securityContext` setting applies to all containers in a Pod.

content/en/docs/reference/glossary/selector.md

@@ -10,9 +10,9 @@ aka:
 tags:
 - fundamental
 ---
- Allows users to filter a list of resources based on labels.
+ Allows users to filter a list of resources based on {{< glossary_tooltip text="labels" term_id="label" >}}.
 
 <!--more--> 
 
-Selectors are applied when querying lists of resources to filter them by {{< glossary_tooltip text="Labels" term_id="label" >}}.
+Selectors are applied when querying lists of resources to filter them by labels.
 

content/en/docs/reference/glossary/taint.md

@@ -11,8 +11,8 @@ tags:
 - core-object
 - fundamental
 ---
- A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of pods on nodes or node groups.
+ A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of {{< glossary_tooltip text="Pods" term_id="pod" >}} on {{< glossary_tooltip text="nodes" term_id="node" >}} or node groups.
 
 <!--more-->
 
-Taints and {{< glossary_tooltip text="tolerations" term_id="toleration" >}} work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a {{< glossary_tooltip text="node" term_id="node" >}}. A node should only schedule a pod with the matching tolerations for the configured taints.
+Taints and {{< glossary_tooltip text="tolerations" term_id="toleration" >}} work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node. A node should only schedule a Pod with the matching tolerations for the configured taints.

content/en/docs/reference/glossary/volume.md

@@ -11,9 +11,10 @@ tags:
 - core-object
 - fundamental
 ---
- A directory containing data, accessible to the containers in a {{< glossary_tooltip text="pod" term_id="pod" >}}.
+ A directory containing data, accessible to the {{< glossary_tooltip text="containers" term_id="container" >}} in a {{< glossary_tooltip term_id="pod" >}}.
 
 <!--more--> 
 
-A Kubernetes volume lives as long as the {{< glossary_tooltip text="pod" term_id="pod" >}} that encloses it. Consequently, a volume outlives any {{< glossary_tooltip text="containers" term_id="container" >}} that run within the {{< glossary_tooltip text="pod" term_id="pod" >}}, and data is preserved across {{< glossary_tooltip text="container" term_id="container" >}} restarts. 
+A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data in the volume is preserved across container restarts.
 
+See [storage](https://kubernetes.io/docs/concepts/storage/) for more information.