Reorganize Working with Kubernetes Objects section

- move Understanding Kubernetes Objects to be section overview
- within the section, consistently link to the new (moved) page from the
  first mention of “object”
- add a redirect

Co-authored-by: Divya Mohan <divya.mohan0209@gmail.com>

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)

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`

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

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

content/en/docs/concepts/overview/working-with-objects/_index.md

@@ -1,7 +1,137 @@
 ---
-title: "Working with Kubernetes Objects"
+title: Understanding Kubernetes Objects
-weight: 40
+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 -->

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

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`

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

content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -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).

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

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

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

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.
 

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
+In Kubernetes, some {{< glossary_tooltip text="objects" term_id="object" >}} are
-{{<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*
+*owners* of other objects. For example, a
-of their owner. 
+{{<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
 

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
+_RoleBinding_ and _ClusterRoleBinding_. You can describe or amend the RBAC
-[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
+{{< glossary_tooltip text="objects" term_id="object" >}}
-or amend them, using tools such as `kubectl`, just like any other Kubernetes 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

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: 

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

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

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

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)
+View the specification of the Pod that you created:
-of the Pod that you created:
 
 ```
 kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example

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