Modify note content about kubectl, CRDs, and subresources (#34468)

* Modified the NOTE for Kubectl Subresource Support.

Improvement: Removed word tool.

Typo fix.

* Added task for patch the deployment using subresource flag.

* Updated the content.

* Updated the link for kubectl patch.

* Resolved nits.

* Improvement: updated the content.

* Removed new deployment and used existing deployment manifests.

content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md

@@ -1081,13 +1081,18 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
 3.  Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
 
 {{< note >}}
-The `kubectl` tool currently cannot be used to edit or patch the `status` subresource on a CRD: see the [Kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) for more details.
+The flag `--subresource` is used with the kubectl get, patch, edit, and replace commands to
+fetch and update the subresources, `status` and `scale`, for all the API resources that
+support them. This flag is available starting from kubectl version v1.24. Previously, reading
+subresources (like `status`) via kubectl involved using `kubectl --raw`, and updating
+subresources using kubectl was not possible at all. Starting from v1.24, the `kubectl` tool
+can be used to edit or patch the `status` subresource on a CRD object. See [How to patch a Deployment using the subresource flag](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#scale-kubectl-patch).
 
-The easier way to patch the status subresource from the CLI is directly interacting with the API server using the `curl` tool, in this example:
+This page is part of the documentation for Kubernetes v{{< skew currentVersion >}}.
+If you are running a different version of Kubernetes, consult the documentation for that release.
+
+Here is an example of how to patch the `status` subresource for a CRD object using `kubectl`:
 ```bash
-kubectl proxy &
-curl --header "Content-Type: application/json-patch+json" \
-  --request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/<your CRD name here>/status \
-  --data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]'
+kubectl patch customresourcedefinitions <CRD_Name> --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1"]}}'
 ```
 {{< /note >}}

content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md

@@ -392,7 +392,7 @@ You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.git
 And you can see the `retainKeys` strategy in the
 [Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
 
-## Alternate forms of the kubectl patch command
+### Alternate forms of the kubectl patch command
 
 The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or
 directly on the command line.
@@ -427,6 +427,90 @@ kubectl patch deployment patch-demo --patch-file patch-file.json
 kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}'
 ```
 
+### Update an object's replica count using `kubectl patch` with `--subresource` {#scale-kubectl-patch}
+
+{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
+
+The flag `--subresource=[subresource-name]` is used with kubectl commands like get, patch,
+edit and replace to fetch and update `status` and `scale` subresources of the resources
+(applicable for kubectl version v1.24 or more). This flag is used with all the API resources
+(built-in and CRs) which has `status` or `scale` subresource. Deployment is one of the
+examples which supports these subresources.
+
+Here's a manifest for a Deployment that has two replicas:
+
+{{< codenew file="application/deployment.yaml" >}}
+
+Create the Deployment:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+```
+
+View the Pods associated with your Deployment:
+
+```shell
+kubectl get pods -l app=nginx
+```
+
+In the output, you can see that Deployment has two Pods. For example:
+
+```
+NAME                                READY   STATUS    RESTARTS   AGE
+nginx-deployment-7fb96c846b-22567   1/1     Running   0          47s
+nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          47s
+```
+
+Now, patch that Deployment with `--subresource=[subresource-name]` flag:
+
+```shell
+kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":3}}'
+```
+
+The output is:
+
+```shell
+scale.autoscaling/nginx-deployment patched
+```
+
+View the Pods associated with your patched Deployment:
+
+```shell
+kubectl get pods -l app=nginx
+```
+
+In the output, you can see one new pod is created, so now you have 3 running pods.
+
+```
+NAME                                READY   STATUS    RESTARTS   AGE
+nginx-deployment-7fb96c846b-22567   1/1     Running   0          107s
+nginx-deployment-7fb96c846b-lxfr2   1/1     Running   0          14s
+nginx-deployment-7fb96c846b-mlgns   1/1     Running   0          107s
+```
+
+View the patched Deployment:
+
+```shell
+kubectl get deployment nginx-deployment -o yaml
+```
+
+```yaml
+...
+spec:
+  replicas: 3
+  ...
+status:
+  ...
+  availableReplicas: 3
+  readyReplicas: 3
+  replicas: 3
+```
+
+{{< note >}}
+If you run `kubectl patch` and specify `--subresource` flag for resource that doesn't support that
+particular subresource, the API server returns a 404 Not Found error.
+{{< /note >}}
+
 ## Summary
 
 In this exercise, you used `kubectl patch` to change the live configuration