Add glossary tooltips for resource terms

Help people reading glossary entries understand what those entries
mean by the term "resource".

Author: lmktfy

content/en/docs/reference/glossary/api-group.md

@@ -11,9 +11,12 @@ tags:
 - fundamental
 - architecture
 ---
-A set of related paths in Kubernetes API. 
+A set of related paths in Kubernetes API.
 
 <!--more-->
-You can enable or disable each API group by changing the configuration of your API server. You can also disable or enable paths to specific resources. API group makes it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object.
+
+You can enable or disable each API group by changing the configuration of your API server. You can also disable or enable paths to specific
+{{< glossary_tooltip text="resources" term_id="api-resource" >}}. An API group makes it easier to extend the Kubernetes API.
+The API group is specified in a REST path and in the `apiVersion` field of a serialized {{< glossary_tooltip text="object" term_id="object" >}}.
 
 * Read [API Group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) for more information.

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

@@ -9,7 +9,8 @@ aka:
 tags:
 - tool
 ---
-cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running {{< glossary_tooltip text="containers" term_id="container" >}}.
+cAdvisor (Container Advisor) provides container users an understanding of the {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}}
+usage and performance characteristics of their running {{< glossary_tooltip text="containers" term_id="container" >}}.
 
 <!--more-->
 

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

@@ -10,7 +10,7 @@ aka:
 tags:
 - fundamental
 ---
-A group of Linux processes with optional resource isolation, accounting and limits.
+A group of Linux processes with optional {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}} isolation, accounting and limits.
 
 <!--more--> 
 

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

@@ -14,4 +14,4 @@ tags:
 
 <!--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 related details 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/customresourcedefinition.md

@@ -12,8 +12,10 @@ tags:
 - operation
 - extension
 ---
- Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
+A kind of {{< glossary_tooltip text="API object" term_id="object" >}} that defines a new custom API to add
+to your Kubernetes API server, without building a complete custom server.
 
 <!--more-->
 
-Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
+CustomResourceDefinitions let you extend the Kubernetes API for your environment if the built-in
+{{< glossary_tooltip text="API resources" term_id="api-resource" >}} can't meet your needs.

content/en/docs/reference/glossary/device-plugin.md

@@ -12,7 +12,8 @@ tags:
 ---
  Device plugins run on worker
 {{< glossary_tooltip term_id="node" text="Nodes">}} and provide
-{{< glossary_tooltip term_id="pod" text="Pods">}} with access to resources,
+{{< glossary_tooltip term_id="pod" text="Pods">}} with access to
+infrastructure {{< glossary_tooltip text="resources" term_id="infrastructure-resource" >}},
 such as local hardware, that require vendor-specific initialization or setup
 steps.
 

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

@@ -11,8 +11,8 @@ tags:
 ---
  Disruptions are events that lead to one or more
 {{< glossary_tooltip term_id="pod" text="Pods" >}} going out of service.
-A disruption has consequences for workload resources, such as
-{{< glossary_tooltip term_id="deployment" >}}, that rely on the affected
+A disruption has consequences for workload management {{< glossary_tooltip text="resources" term_id="api-resource" >}},
+such as {{< glossary_tooltip term_id="deployment" >}}, that rely on the affected
 Pods.
 
 <!--more-->

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

@@ -10,8 +10,9 @@ aka:
 tags:
 - networking
 ---
- Endpoints track the IP addresses of Pods with matching  {{< glossary_tooltip text="selectors" term_id="selector" >}}.
+Legacy {{< glossary_tooltip text="API resource" term_id="api-resource" >}} for tracking the IP addresses of Pods that back
+{{< glossary_tooltip text="Services" term_id="service" >}}
 
 <!--more-->
-Endpoints can be configured manually for {{< glossary_tooltip text="Services" term_id="service" >}} without selectors specified.
-The {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} resource provides a scalable and extensible alternative to Endpoints.
+The {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} object kind provides a scalable and extensible
+alternative to Endpoints.

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

@@ -14,6 +14,8 @@ A {{< glossary_tooltip term_id="container" >}} type that you can temporarily run
 
 <!--more-->
 
-If you want to investigate a Pod that's running with problems, you can add an ephemeral container to that Pod and carry out diagnostics. Ephemeral containers have no resource or scheduling guarantees, and you should not use them to run any part of the workload itself.
+If you want to investigate a Pod that's running with problems, you can add an ephemeral container to that Pod and carry out diagnostics.
+Ephemeral containers have no {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}} or scheduling guarantees,
+and you should not use them to run any part of the workload itself.
 
 Ephemeral containers are not supported by {{< glossary_tooltip text="static pods" term_id="static-pod" >}}.

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

@@ -4,19 +4,19 @@ id: event
 date: 2022-01-16
 full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/
 short_description: >
-   Events are Kubernetes objects that describe some state change in the system.
+   Kubernetes objects that describe some state change in the cluster.
 aka: 
 tags:
 - core-object
 - fundamental
 ---
-Event is a Kubernetes object that describes state change/notable occurrences in the system.
+A Kubernetes {{< glossary_tooltip text="object" term_id="object" >}} that describes state changes
+or notable occurrences in the cluster.
 
 <!--more-->
-Events have a limited retention time and triggers and messages may evolve with time. 
-Event consumers should not rely on the timing of an event with a given reason reflecting a consistent underlying trigger, 
-or the continued existence of events with that reason. 
-
+Events have a limited retention time and triggers and messages may evolve with time.
+Event consumers should not rely on the timing of an event with a given reason reflecting a consistent underlying trigger,
+or the continued existence of events with that reason.
 
 Events should be treated as informative, best-effort, supplemental data.
 

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

@@ -12,7 +12,8 @@ tags:
 - operation
 ---
 Finalizers are namespaced keys that tell Kubernetes to wait until specific
-conditions are met before it fully deletes resources marked for deletion.
+conditions are met before it fully deletes {{< glossary_tooltip text="resources" term_id="api-resource" >}}
+that are marked for deletion.
 Finalizers alert {{<glossary_tooltip text="controllers" term_id="controller">}}
 to clean up resources the deleted object owned.
 
@@ -27,5 +28,6 @@ from the target object. When the `metadata.finalizers` field is empty,
 Kubernetes considers the deletion complete and deletes the object.
 
 You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
-of resources. For example, you can define a finalizer to clean up related resources or
-infrastructure before the controller deletes the target resource.
+of resources. For example, you can define a finalizer to clean up related
+{{< glossary_tooltip text="API resources" term_id="api-resource" >}} or infrastructure before the controller
+deletes the object being finalized.

content/en/docs/reference/glossary/group-version-resource.md

@@ -3,16 +3,19 @@ title: Group Version Resource
 id: gvr
 date: 2023-07-24
 short_description: >
-  The API group, API version and name of a Kubernetes API. 
+  The API group, API version and name of a Kubernetes API.
 
 aka: ["GVR"]
 tags:
 - architecture
 ---
-Means of representing unique Kubernetes API resource.
+Means of representing specific Kubernetes APIs uniquely.
 
 <!--more-->
 
-Group Version Resources (GVRs) specify the API group, API version, and resource (name for the object kind as it appears in the URI) associated with accessing a particular id of object in Kubernetes.
+Group Version Resources (GVRs) specify the API group, API version, and _resource_ (name for the object kind as it appears in the URI) associated with accessing a particular id of object in Kubernetes.
 GVRs let you define and distinguish different Kubernetes objects, and to specify a way of accessing
-objects that is stable even as APIs change.
+objects that is stable even as APIs change.
+
+In this usage, _resource_ refers to an HTTP resource. Because some APIs are namespaced, a GVR may
+not refer to a specific {{< glossary_tooltip text="API resource" term_id="api-resource" >}}.

content/en/docs/reference/glossary/helm-chart.md

@@ -4,13 +4,13 @@ id: helm-chart
 date: 2018-04-12
 full_link: https://helm.sh/docs/topics/charts/
 short_description: >
-  A package of pre-configured Kubernetes resources that can be managed with the Helm tool.
+  A package of pre-configured Kubernetes configurations that can be managed with the Helm tool.
 
 aka: 
 tags:
 - tool
 ---
- A package of pre-configured Kubernetes resources that can be managed with the Helm tool.
+A package of pre-configured Kubernetes configurations that can be managed with the Helm tool.
 
 <!--more--> 
 

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

@@ -4,16 +4,17 @@ id: horizontal-pod-autoscaler
 date: 2018-04-12
 full_link: /docs/tasks/run-application/horizontal-pod-autoscale/
 short_description: >
-  An API resource that automatically scales the number of pod replicas based on targeted CPU utilization or custom metric targets.
+  Object that automatically scales the number of pod replicas based on targeted resource utilization or custom metric targets.
 
 aka: 
 - HPA
 tags:
 - operation
 ---
- An API resource that automatically scales the number of {{< glossary_tooltip term_id="pod" >}} replicas based on targeted CPU utilization or custom metric targets.
+An {{< glossary_tooltip text="object" term_id="object" >}} that automatically scales the number of {{< glossary_tooltip term_id="pod" >}} replicas,
+based on targeted {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}} utilization or custom metric targets.
 
 <!--more--> 
 
-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" >}}.
+HorizontalPodAutoscaler (HPA) is typically used with {{< 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/kube-scheduler.md

@@ -18,6 +18,6 @@ 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.
+individual and collective {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}}
+requirements, hardware/software/policy constraints, affinity and anti-affinity specifications,
+data locality, inter-workload interference, and deadlines.

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

@@ -16,8 +16,12 @@ related:
  - container
 
 ---
- Provides constraints to limit resource consumption per {{< glossary_tooltip text="Containers" term_id="container" >}} or {{< glossary_tooltip text="Pods" term_id="pod" >}} in a namespace.
+Constraints resource consumption per {{< glossary_tooltip text="container" term_id="container" >}} or {{< glossary_tooltip text="Pod" term_id="pod" >}},
+specified for a particular {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
 
 <!--more--> 
-LimitRange limits the quantity of objects that can be created  by type, 
-as well as the amount of compute resources that may be requested/consumed by individual {{< glossary_tooltip text="Containers" term_id="container" >}} or {{< glossary_tooltip text="Pods" term_id="pod" >}} in a namespace.
+
+A [LimitRange](/docs/concepts/policy/limit-range/) either limits the quantity of {{< glossary_tooltip text="API resources" term_id="api-resource" >}}
+that can be created (for a particular resource type),
+or the amount of {{< glossary_tooltip text="infrastructure resources" term_id="infrastructure-resource" >}}
+that may be requested/consumed by individual containers or Pods within a namespace.

content/en/docs/reference/glossary/mixed-version-proxy.md

@@ -13,8 +13,9 @@ Feature to let a kube-apiserver proxy a resource request to a different peer API
 
 <!--more-->
 
-When a cluster has multiple API servers running different versions of Kubernetes, this 
-feature enables resource requests to be served by the correct API server.
+When a cluster has multiple API servers running different versions of Kubernetes, this
+feature enables {{< glossary_tooltip text="resource" term_id="api-resource" >}}
+requests to be served by the correct API server.
 
 MVP is disabled by default and can be activated by enabling
 the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `UnknownVersionInteroperabilityProxy` when 

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

@@ -10,7 +10,8 @@ aka:
 tags:
 - fundamental
 ---
- A client-provided string that refers to an object in a resource URL, such as `/api/v1/pods/some-name`.
+A client-provided string that refers to an object in a {{< glossary_tooltip text="resource" term_id="api-resource" >}}
+URL, such as `/api/v1/pods/some-name`.
 
 <!--more--> 
 

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

@@ -10,9 +10,10 @@ aka:
 tags:
 - fundamental
 ---
- An abstraction used by Kubernetes to support isolation of groups of resources within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
+An abstraction used by Kubernetes to support isolation of groups of {{< glossary_tooltip text="API resources" term_id="api-resource" >}}
+within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
 
 <!--more--> 
 
-Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
+Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced resources _(for example: Pods, Deployments, Services)_ and not for cluster-wide resources _(for example: StorageClasses, Nodes, PersistentVolumes)_.
 

content/en/docs/reference/glossary/network-policy.md

@@ -17,5 +17,10 @@ tags:
 
 <!--more--> 
 
-Network Policies help you declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate, and more specifically which port numbers to enforce each policy on. `NetworkPolicy` resources use labels to select Pods and define rules which specify what traffic is allowed to the selected Pods. Network Policies are implemented by a supported network plugin provided by a network provider. Be aware that creating a network resource without a controller to implement it will have no effect.
+NetworkPolicies help you declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate,
+and more specifically which port numbers to enforce each policy on. NetworkPolicy objects use {{< glossary_tooltip text="labels" term_id="label" >}}
+to select Pods and define rules which specify what traffic is allowed to the selected Pods.
+
+NetworkPolicies are implemented by a supported network plugin provided by a network provider.
+Be aware that creating a NetworkPolicy object without a controller to implement it will have no effect.
 

content/en/docs/reference/glossary/node-pressure-eviction.md

@@ -12,7 +12,8 @@ tags:
 - operation
 ---
 Node-pressure eviction is the process by which the {{<glossary_tooltip term_id="kubelet" text="kubelet">}} proactively terminates
-pods to reclaim resources on nodes.
+pods to reclaim {{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}}
+on nodes.
 
 <!--more-->
 

content/en/docs/reference/glossary/operator-pattern.md

@@ -10,7 +10,7 @@ aka:
 tags:
 - architecture
 ---
- The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
+The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
 design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom
 resources.
 

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

@@ -11,7 +11,9 @@ tags:
 - core-object
 - storage
 ---
- 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" >}}.
+Claims storage {{< glossary_tooltip text="resources" term_id="infrastructure-resource" >}} defined in a
+{{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}, so that the storage can be mounted as
+a volume in a {{< glossary_tooltip text="container" term_id="container" >}}.
 
 <!--more--> 
 

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

@@ -4,14 +4,16 @@ id: persistent-volume
 date: 2018-04-12
 full_link: /docs/concepts/storage/persistent-volumes/
 short_description: >
-  An API object that represents a piece of storage in the cluster. Available as a general, pluggable resource that persists beyond the lifecycle of any individual Pod.
+  API object that represents a piece of storage in the cluster.
 
 aka: 
 tags:
 - core-object
 - storage
 ---
- An API object that represents a piece of storage in the cluster. Available as a general, pluggable resource that persists beyond the lifecycle of any individual {{< glossary_tooltip text="Pod" term_id="pod" >}}.
+An API object that represents a piece of storage in the cluster. Representation of as a general, pluggable storage
+{{< glossary_tooltip text="resource" term_id="infrastructure-resource" >}} that can persist beyond the lifecycle of any
+individual {{< glossary_tooltip text="Pod" term_id="pod" >}}.
 
 <!--more--> 
 

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

@@ -21,4 +21,5 @@ Pods on Nodes are terminated either voluntarily or involuntarily.
 
 Voluntary disruptions are started intentionally by application owners or cluster 
 administrators. Involuntary disruptions are unintentional and can be triggered by 
-unavoidable issues like Nodes running out of resources, or by accidental deletions. 
+unavoidable issues like Nodes running out of {{< glossary_tooltip text="resources" term_id="infrastructure-resource" >}},
+or by accidental deletions.