Merge pull request #50342 from lmktfy/20250221_use_resource_glossary_entries

Add glossary tooltips for resource terms

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/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.

content/en/docs/reference/glossary/pod-security-policy.md

@@ -4,18 +4,14 @@ id: pod-security-policy
 date: 2018-04-12
 full_link: /docs/concepts/security/pod-security-policy/
 short_description: >
-  Enables fine-grained authorization of pod creation and updates.
-
+  Removed API that enforced Pod security restrictions.
 aka: 
 tags:
-- core-object
-- fundamental
+- security
 ---
- Enables fine-grained authorization of {{< glossary_tooltip term_id="pod" >}} creation and updates.
+A former Kubernetes API that enforced security restrictions during {{< glossary_tooltip term_id="pod" >}} creation and updates.
 
 <!--more--> 
 
-A cluster-level resource that controls security sensitive aspects of the Pod specification. The `PodSecurityPolicy` objects define a set of conditions that a Pod must run with in order to be accepted into the system, as well as defaults for the related fields. Pod Security Policy control is implemented as an optional admission controller.
-
 PodSecurityPolicy was deprecated as of Kubernetes v1.21, and removed in v1.25.
 As an alternative, use [Pod Security Admission](/docs/concepts/security/pod-security-admission/) or a 3rd party admission plugin.

content/en/docs/reference/glossary/qos-class.md

@@ -17,7 +17,8 @@ related:
  QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction.
 
 <!--more--> 
-QoS Class of a Pod is set at creation time  based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.
+QoS Class of a Pod is set at creation time based on its {{< glossary_tooltip text="infrastructure resource" term_id="infrastructure-resource" >}}
+requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction.
 Kubernetes can assign one of the following  QoS classes to a Pod: `Guaranteed`, `Burstable` or `BestEffort`.
 
 

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

@@ -11,7 +11,8 @@ tags:
 - workload
 - core-object
 ---
- A workload resource that manages a replicated application, ensuring that
+A workload management {{< glossary_tooltip text="object" term_id="object" >}}
+that manages a replicated application, ensuring that
 a specific number of instances of a {{< glossary_tooltip text="Pod" term_id="pod" >}} are running.
 
 <!--more-->

content/en/docs/reference/glossary/resource-quota.md

@@ -1,5 +1,5 @@
 ---
-title: Resource Quotas
+title: ResourceQuota
 id: resource-quota
 date: 2018-04-12
 full_link: /docs/concepts/policy/resource-quotas/
@@ -12,9 +12,13 @@ tags:
 - operation
 - architecture
 ---
- Provides constraints that limit aggregate resource consumption per {{< glossary_tooltip term_id="namespace" >}}.
+Object that constrains aggregate resource
+consumption, per {{< glossary_tooltip term_id="namespace" >}}.
 
-<!--more--> 
+<!--more-->
 
-Limits the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project.
+A ResourceQuota can either limits the quantity of {{< glossary_tooltip text="API resources" term_id="api-resource" >}}
+that can be created in a namespace by type, or it can set a limit on the total amount of
+{{< glossary_tooltip text="infrastructure resources" term_id="infrastructure-resource" >}}
+that may be consumed on behalf of the namespace (and the objects within it).
 

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

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

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

@@ -4,7 +4,7 @@ id: spec
 date: 2023-12-17
 full_link: /docs/concepts/overview/working-with-objects/#object-spec-and-status
 short_description: >
-  This field in Kubernetes manifests defines the desired state or configuration for specific Kubernetes objects.
+  Field in Kubernetes manifests that defines the desired state or configuration.
 
 aka:
 tags:
@@ -14,8 +14,8 @@ tags:
   Defines how each object, like Pods or Services, should be configured and its desired state.
 
 <!--more-->
-Almost every Kubernetes object includes two nested object fields that govern the object's configuration: the object spec and the object status. For objects that have a spec, you have to set this when you create the object, providing a description of the characteristics you want the resource to have: its desired state.
+Almost every Kubernetes object includes two nested object fields that govern the object's configuration: the object spec and the object status. For objects that have a spec, you have to set this when you create the object, providing a description of the characteristics you want the {{< glossary_tooltip text="resource" term_id="api-resource" >}} to have: its desired state.
 
-It varies for different objects like Pods, StatefulSets, and Services, detailing settings such as containers, volumes, replicas, ports,   
-and other specifications unique to each object type. This field encapsulates what state Kubernetes should maintain for the defined   
+It varies for different objects like Pods, StatefulSets, and Services, detailing settings such as containers, volumes, replicas, ports,
+and other specifications unique to each object type. This field encapsulates what state Kubernetes should maintain for the defined
 object.