diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md
index 840fe4287b..b89f6a077c 100644
--- a/content/en/docs/concepts/architecture/controller.md
+++ b/content/en/docs/concepts/architecture/controller.md
@@ -26,7 +26,7 @@ closer to the desired state, by turning equipment on or off.
## Controller pattern
A controller tracks at least one Kubernetes resource type.
-These [objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
+These {{< glossary_tooltip text="objects" term_id="object" >}}
have a spec field that represents the desired state. The
controller(s) for that resource are responsible for making the current
state come closer to that desired state.
@@ -162,7 +162,7 @@ controller does.
## {{% heading "whatsnext" %}}
* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
-* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see
[Extension Patterns](/docs/concepts/extend-kubernetes/#extension-patterns)
diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md
index 4bd3ac32f1..1b9b6dd7b3 100644
--- a/content/en/docs/concepts/configuration/configmap.md
+++ b/content/en/docs/concepts/configuration/configmap.md
@@ -36,7 +36,7 @@ separate database or file service.
## ConfigMap object
-A ConfigMap is an API [object](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+A ConfigMap is an {{< glossary_tooltip text="API object" term_id="object" >}}
that lets you store configuration for other objects to use. Unlike most
Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
fields. These fields accept key-value pairs as their values. Both the `data`
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index a1a2d734b9..0f65808f72 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -226,7 +226,7 @@ see the [Troubleshooting](#troubleshooting) section.
### Monitoring compute & memory resource usage
The kubelet reports the resource usage of a Pod as part of the Pod
-[`status`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status).
+[`status`](/docs/concepts/overview/working-with-objects/#object-spec-and-status).
If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
are available in your cluster, then Pod resource usage can be retrieved either
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 3979c89d32..2907d2f0fd 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -17,7 +17,7 @@ methods for adding custom resources and how to choose between them.
## Custom resources
A *resource* is an endpoint in the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) that
-stores a collection of [API objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+stores a collection of {{< glossary_tooltip text="API objects" term_id="object" >}}
of a certain kind; for example, the built-in *pods* resource contains a collection of Pod objects.
A *custom resource* is an extension of the Kubernetes API that is not necessarily available in a default
diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md
index f872c20697..62233a17fc 100644
--- a/content/en/docs/concepts/overview/working-with-objects/_index.md
+++ b/content/en/docs/concepts/overview/working-with-objects/_index.md
@@ -1,7 +1,137 @@
---
-title: "Working with Kubernetes Objects"
-weight: 40
+title: Understanding Kubernetes Objects
+content_type: concept
+weight: 10
description: >
- Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
+ Kubernetes objects are persistent entities in the Kubernetes system.
+ Kubernetes uses these entities to represent the state of your cluster.
Learn about the Kubernetes object model and how to work with these objects.
+simple_list: true
+card:
+ name: concepts
+ weight: 40
---
+
+<!-- overview -->
+
+This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
+express them in `.yaml` format.
+
+<!-- body -->
+
+## Objects in Kubernetes {#kubernetes-objects}
+
+*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
+entities to represent the state of your cluster. Specifically, they can describe:
+
+* What containerized applications are running (and on which nodes)
+* The resources available to those applications
+* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
+
+A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
+will constantly work to ensure that object exists. By creating an object, you're effectively
+telling the Kubernetes system what you want your cluster's workload to look like; this is your
+cluster's *desired state*.
+
+To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
+[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
+interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
+the Kubernetes API directly in your own programs using one of the
+[Client Libraries](/docs/reference/using-api/client-libraries/).
+
+### Object spec and status
+
+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_.
+
+The `status` describes the _current state_ of the object, supplied and updated
+by the Kubernetes system and its components. The Kubernetes
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
+and actively manages every object's actual state to match the desired state you
+supplied.
+
+For example: in Kubernetes, a Deployment is an object that can represent an
+application running on your cluster. When you create the Deployment, you
+might set the Deployment `spec` to specify that you want three replicas of
+the application to be running. The Kubernetes system reads the Deployment
+spec and starts three instances of your desired application--updating
+the status to match your spec. If any of those instances should fail
+(a status change), the Kubernetes system responds to the difference
+between spec and status by making a correction--in this case, starting
+a replacement instance.
+
+For more information on the object spec, status, and metadata, see the
+[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
+
+### Describing a Kubernetes object
+
+When you create an object in Kubernetes, you must provide the object spec that describes its
+desired state, as well as some basic information about the object (such as a name). When you use
+the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
+include that information as JSON in the request body. **Most often, you provide the information to
+`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
+request.
+
+Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
+
+{{< codenew file="application/deployment.yaml" >}}
+
+One way to create a Deployment using a `.yaml` file like the one above is to use the
+[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
+in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+```
+
+The output is similar to this:
+
+```
+deployment.apps/nginx-deployment created
+```
+
+### Required fields
+
+In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
+
+* `apiVersion` - Which version of the Kubernetes API you're using to create this object
+* `kind` - What kind of object you want to create
+* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
+* `spec` - What state you desire for the object
+
+The precise format of the object `spec` is different for every Kubernetes object, and contains
+nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
+can help you find the spec format for all of the objects you can create using Kubernetes.
+
+For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
+for the Pod API reference.
+For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
+each container within that pod).
+Another example of an object specification is the
+[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
+for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
+its desired state.
+Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
+for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
+satisfy the StatefulSet specification.
+Different kinds of object can also have different `.status`; again, the API reference pages
+detail the structure of that `.status` field, and its content for each different type of object.
+
+## {{% heading "whatsnext" %}}
+
+If you're new to Kubernetes, read more about the following:
+
+* [Pods](/docs/concepts/workloads/pods/) which are the most important basic Kubernetes objects.
+* [Deployment](/docs/concepts/workloads/controllers/deployment/) objects.
+* [Controllers](/docs/concepts/architecture/controller/) in Kubernetes.
+* [kubectl](/docs/reference/kubectl/) and [kubectl commands](/docs/reference/generated/kubectl/kubectl-commands).
+
+To learn about the Kubernetes API in general, visit:
+
+* [Kubernetes API overview](/docs/reference/using-api/)
+
+To learn about objects in Kubernetes in more depth, read other pages in this section:
+<!-- Docsy automatically includes a list of pages in the section -->
diff --git a/content/en/docs/concepts/overview/working-with-objects/annotations.md b/content/en/docs/concepts/overview/working-with-objects/annotations.md
index 721bb67c7d..f4c8a68ba3 100644
--- a/content/en/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/en/docs/concepts/overview/working-with-objects/annotations.md
@@ -6,7 +6,8 @@ weight: 60
<!-- overview -->
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
-to objects. Clients such as tools and libraries can retrieve this metadata.
+to {{< glossary_tooltip text="objects" term_id="object" >}}.
+Clients such as tools and libraries can retrieve this metadata.
<!-- body -->
## Attaching metadata to objects
diff --git a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
index beafd85081..c341340be5 100644
--- a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -4,7 +4,8 @@ content_type: concept
weight: 70
---
-_Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some examples of field selector queries:
+_Field selectors_ let you select Kubernetes {{< glossary_tooltip text="objects" term_id="object" >}} based on the
+value of one or more resource fields. Here are some examples of field selector queries:
* `metadata.name=my-service`
* `metadata.namespace!=default`
diff --git a/content/en/docs/concepts/overview/working-with-objects/finalizers.md b/content/en/docs/concepts/overview/working-with-objects/finalizers.md
index 0e3d5f0662..b7ebb95b40 100644
--- a/content/en/docs/concepts/overview/working-with-objects/finalizers.md
+++ b/content/en/docs/concepts/overview/working-with-objects/finalizers.md
@@ -8,6 +8,10 @@ weight: 80
{{<glossary_definition term_id="finalizer" length="long">}}
+You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
+of {{< glossary_tooltip text="objects" term_id="object" >}} by alerting {{<glossary_tooltip text="controllers" term_id="controller">}}
+to perform specific cleanup tasks before deleting the target resource.
+
Finalizers don't usually specify the code to execute. Instead, they are
typically lists of keys on a specific resource similar to annotations.
Kubernetes specifies some finalizers automatically, but you can also specify
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
deleted file mode 100644
index 53969ab025..0000000000
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: Understanding Kubernetes Objects
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 40
----
-
-<!-- overview -->
-
-This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can
-express them in `.yaml` format.
-
-<!-- body -->
-
-## Understanding Kubernetes objects {#kubernetes-objects}
-
-*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these
-entities to represent the state of your cluster. Specifically, they can describe:
-
-* What containerized applications are running (and on which nodes)
-* The resources available to those applications
-* The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
-
-A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system
-will constantly work to ensure that object exists. By creating an object, you're effectively
-telling the Kubernetes system what you want your cluster's workload to look like; this is your
-cluster's *desired state*.
-
-To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the
-[Kubernetes API](/docs/concepts/overview/kubernetes-api/). When you use the `kubectl` command-line
-interface, for example, the CLI makes the necessary Kubernetes API calls for you. You can also use
-the Kubernetes API directly in your own programs using one of the
-[Client Libraries](/docs/reference/using-api/client-libraries/).
-
-### Object spec and status
-
-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_.
-
-The `status` describes the _current state_ of the object, supplied and updated
-by the Kubernetes system and its components. The Kubernetes
-{{< glossary_tooltip text="control plane" term_id="control-plane" >}} continually
-and actively manages every object's actual state to match the desired state you
-supplied.
-
-For example: in Kubernetes, a Deployment is an object that can represent an
-application running on your cluster. When you create the Deployment, you
-might set the Deployment `spec` to specify that you want three replicas of
-the application to be running. The Kubernetes system reads the Deployment
-spec and starts three instances of your desired application--updating
-the status to match your spec. If any of those instances should fail
-(a status change), the Kubernetes system responds to the difference
-between spec and status by making a correction--in this case, starting
-a replacement instance.
-
-For more information on the object spec, status, and metadata, see the
-[Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md).
-
-### Describing a Kubernetes object
-
-When you create an object in Kubernetes, you must provide the object spec that describes its
-desired state, as well as some basic information about the object (such as a name). When you use
-the Kubernetes API to create the object (either directly or via `kubectl`), that API request must
-include that information as JSON in the request body. **Most often, you provide the information to
-`kubectl` in a .yaml file.** `kubectl` converts the information to JSON when making the API
-request.
-
-Here's an example `.yaml` file that shows the required fields and object spec for a Kubernetes Deployment:
-
-{{< codenew file="application/deployment.yaml" >}}
-
-One way to create a Deployment using a `.yaml` file like the one above is to use the
-[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command
-in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
-
-```shell
-kubectl apply -f https://k8s.io/examples/application/deployment.yaml
-```
-
-The output is similar to this:
-
-```
-deployment.apps/nginx-deployment created
-```
-
-### Required fields
-
-In the `.yaml` file for the Kubernetes object you want to create, you'll need to set values for the following fields:
-
-* `apiVersion` - Which version of the Kubernetes API you're using to create this object
-* `kind` - What kind of object you want to create
-* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
-* `spec` - What state you desire for the object
-
-The precise format of the object `spec` is different for every Kubernetes object, and contains
-nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/)
-can help you find the spec format for all of the objects you can create using Kubernetes.
-
-For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
-for the Pod API reference.
-For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
-each container within that pod).
-Another example of an object specification is the
-[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
-for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
-its desired state.
-Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
-for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
-satisfy the StatefulSet specification.
-Different kinds of object can also have different `.status`; again, the API reference pages
-detail the structure of that `.status` field, and its content for each different type of object.
-
-## {{% heading "whatsnext" %}}
-
-Learn more about the following:
-
-* [Pods](/docs/concepts/workloads/pods/) which are the most important basic Kubernetes objects.
-* [Deployment](/docs/concepts/workloads/controllers/deployment/) objects.
-* [Controllers](/docs/concepts/architecture/controller/) in Kubernetes.
-* [Kubernetes API overview](/docs/reference/using-api/) which explains some more API concepts.
-* [kubectl](/docs/reference/kubectl/) and [kubectl commands](/docs/reference/generated/kubectl/kubectl-commands).
diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md
index aec2c4cc01..7ca0c3ff18 100644
--- a/content/en/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/labels.md
@@ -8,7 +8,8 @@ weight: 40
<!-- overview -->
-_Labels_ are key/value pairs that are attached to objects, such as pods.
+_Labels_ are key/value pairs that are attached to
+{{< glossary_tooltip text="objects" term_id="object" >}} such as Pods.
Labels are intended to be used to specify identifying attributes of objects
that are meaningful and relevant to users, but do not directly imply semantics
to the core system. Labels can be used to organize and to select subsets of
diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md
index 0b49938637..48655caf46 100644
--- a/content/en/docs/concepts/overview/working-with-objects/names.md
+++ b/content/en/docs/concepts/overview/working-with-objects/names.md
@@ -9,7 +9,7 @@ weight: 30
<!-- overview -->
-Each object in your cluster has a [_Name_](#names) that is unique for that type of resource.
+Each {{< glossary_tooltip text="object" term_id="object" >}} in your cluster has a [_Name_](#names) that is unique for that type of resource.
Every Kubernetes object also has a [_UID_](#uids) that is unique across your whole cluster.
For example, you can only have one Pod named `myapp-1234` within the same [namespace](/docs/concepts/overview/working-with-objects/namespaces/), but you can have one Pod and one Deployment that are each named `myapp-1234`.
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 6e838bac89..a1865b5ced 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -10,7 +10,7 @@ weight: 45
<!-- overview -->
-In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. 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)_.
+In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced {{< glossary_tooltip text="objects" term_id="object" >}} _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
<!-- body -->
diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md
index 928062f174..59170a7095 100644
--- a/content/en/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md
@@ -6,7 +6,7 @@ weight: 20
<!-- overview -->
The `kubectl` command-line tool supports several different ways to create and manage
-Kubernetes objects. This document provides an overview of the different
+Kubernetes {{< glossary_tooltip text="objects" term_id="object" >}}. This document provides an overview of the different
approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
details of managing objects by Kubectl.
diff --git a/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md
index 035298930b..317d71aa35 100644
--- a/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md
+++ b/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md
@@ -6,17 +6,18 @@ weight: 90
<!-- overview -->
-In Kubernetes, some {{< glossary_tooltip text="objects" term_id="Object" >}} are *owners* of other objects. For example, a
-{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of {{<glossary_tooltip text="Pods" term_id="pod">}}. These owned objects are *dependents*
-of their owner.
+In Kubernetes, some {{< glossary_tooltip text="objects" term_id="object" >}} are
+*owners* of other objects. For example, a
+{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner
+of a set of Pods. These owned objects are *dependents* of their owner.
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
-mechanism that some resources also use. For example, consider a Service that
+mechanism that some resources also use. For example, consider a Service that
creates `EndpointSlice` objects. The Service uses {{<glossary_tooltip text="labels" term_id="label">}} to allow the control plane to
determine which `EndpointSlice` objects are used for that Service. In addition
to the labels, each `EndpointSlice` that is managed on behalf of a Service has
an owner reference. Owner references help different parts of Kubernetes avoid
-interfering with objects they don’t control.
+interfering with objects they don’t control.
## Owner references in object specifications
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index 06d84c8e06..9e3a92f513 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -29,9 +29,9 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
## API objects {#api-overview}
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
-_RoleBinding_ and _ClusterRoleBinding_. You can
-[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
-or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
+_RoleBinding_ and _ClusterRoleBinding_. You can describe or amend the RBAC
+{{< glossary_tooltip text="objects" term_id="object" >}}
+using tools such as `kubectl`, just like any other Kubernetes object.
{{< caution >}}
These objects, by design, impose access restrictions. If you are making changes
diff --git a/content/en/docs/reference/glossary/object.md b/content/en/docs/reference/glossary/object.md
index 1e3a6165fd..6365c7839f 100644
--- a/content/en/docs/reference/glossary/object.md
+++ b/content/en/docs/reference/glossary/object.md
@@ -2,7 +2,7 @@
title: Object
id: object
date: 2020-10-12
-full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+full_link: /docs/concepts/overview/working-with-objects/#kubernetes-objects
short_description: >
A entity in the Kubernetes system, representing part of the state of your cluster.
aka:
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 488119c0d1..1aa6f82d90 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -402,7 +402,7 @@ kubectl taint nodes foo dedicated=special-user:NoSchedule
### Resource types
-List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
+List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [kind](/docs/concepts/overview/working-with-objects/):
```bash
kubectl api-resources
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index 62deb25f58..6e6b0fe9ae 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -39,7 +39,7 @@ API concepts:
* For some resource types, the API includes one or more *sub-resources*, which are represented as URI paths below the resource
Most Kubernetes API resource types are
-[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects):
+{{< glossary_tooltip text="objects" term_id="object" >}} –
they represent a concrete instance of a concept on the cluster, like a
pod or namespace. A smaller number of API resource types are *virtual* in
that they often represent operations on objects, rather than objects, such
diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md
index 980ad7020f..75560b627d 100644
--- a/content/en/docs/reference/using-api/server-side-apply.md
+++ b/content/en/docs/reference/using-api/server-side-apply.md
@@ -18,7 +18,7 @@ min-kubernetes-server-version: 1.16
Server-Side Apply helps users and controllers manage their resources through
declarative configurations. Clients can create and modify their
-[objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+{{< glossary_tooltip text="objects" term_id="object" >}}
declaratively by sending their fully specified intent.
A fully specified intent is a partial object that only includes the fields and
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
index 5bbd37fa18..77a095e1fe 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
@@ -109,7 +109,7 @@ Create the Pod:
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
```
-View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
+View the [specification](/docs/concepts/overview/working-with-objects/#object-spec-and-status)
of the Pod that you created:
```
@@ -140,8 +140,7 @@ Create the Pod:
kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
```
-View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
-of the Pod that you created:
+View the specification of the Pod that you created:
```
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
diff --git a/static/_redirects b/static/_redirects
index 5a0e2113e8..8c44663e96 100644
--- a/static/_redirects
+++ b/static/_redirects
@@ -33,7 +33,7 @@
/docs/concepts/abstractions/controllers/garbage-collection/ /docs/concepts/workloads/controllers/garbage-collection/ 301
/docs/concepts/abstractions/controllers/statefulsets/ /docs/concepts/workloads/controllers/statefulset/ 301
/docs/concepts/abstractions/init-containers/ /docs/concepts/workloads/pods/init-containers/ 301
-/docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301
+/docs/concepts/abstractions/overview/ /docs/concepts/overview/working-with-objects/ 301
/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/ 301
/docs/concepts/api-extension/apiserver-aggregation/ /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 301
/docs/concepts/api-extension/custom-resources/ /docs/concepts/extend-kubernetes/api-extension/custom-resources/ 301
@@ -102,6 +102,7 @@
/docs/concepts/tools/kubectl/object-management-using-declarative-config/ /docs/concepts/overview/object-management-kubectl/declarative-config/ 301
/docs/concepts/tools/kubectl/object-management-using-imperative-commands/ /docs/concepts/overview/object-management-kubectl/imperative-command/ 301
/docs/concepts/tools/kubectl/object-management-using-imperative-config/ /docs/concepts/overview/object-management-kubectl/imperative-config/ 301
+/docs/concepts/overview/working-with-objects/kubernetes-objects/ /docs/concepts/overview/working-with-objects/ 301
/docs/concepts/overview/object-management-kubectl/overview/ /docs/concepts/overview/working-with-objects/object-management/ 301
/docs/concepts/overview/object-management-kubectl/declarative-config/ /docs/tasks/manage-kubernetes-objects/declarative-config/ 301
/docs/concepts/overview/object-management-kubectl/imperative-command/ /docs/tasks/manage-kubernetes-objects/imperative-command/ 301