Address feedback

content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md

@@ -47,9 +47,9 @@ Kubelet's configuration.
 Each Kubelet watches a configuration reference on its respective Node object.
 When this reference changes, the Kubelet downloads the new configuration,
 updates a local reference to refer to the file, and exits.
-For the feature to work correctly, you must be running a process manager
-(like systemd) which will restart the Kubelet when it exits. When the Kubelet is
-restarted, it will begin using the new configuration.
+For the feature to work correctly, you must be running an OS-level service
+manager (such as systemd), which will restart the Kubelet if it exits. When the
+Kubelet is restarted, it will begin using the new configuration.
 
 The new configuration completely overrides configuration provided by `--config`,
 and is overridden by command-line flags. Unspecified values in the new configuration
@@ -97,28 +97,32 @@ to create the first Kubelet ConfigMap
 (see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)),
 Currently, the Kubelet is bootstrapped with **a combination of this file and command-line flags**
 that can override the configuration in the file.
-As a workaround, you can use to generate a config file containing a Node's
-current configuration by accessing the Kubelet server's `configz`
-endpoint via the kubectl proxy. This endpoint, in its current implementation, is
-intended to be used only as a debugging aid. Do not rely on the behavior of this
-endpoint for production scenarios.
-The `jq` command needs to be installed on your system, to unpack and edit the
-JSON response from the endpoint.
+As a workaround, you can generate a config file containing a Node's current
+configuration by accessing the Kubelet server's `configz` endpoint via the
+kubectl proxy. This endpoint, in its current implementation, is intended to be
+used only as a debugging aid. Do not rely on the behavior of this endpoint for
+production scenarios. The examples below use the `jq` command to streamline
+working with JSON. To follow the tasks as written, you need to have `jq`
+installed, but you can adapt the tasks if you prefer to extract the
+`kubeletconfig` subobject manually.
 
 #### Generate the configuration file
 
-1. Pick a Node to reconfigure. In this example, this Node is named `NODE_NAME`.
-2. Start the kubectl proxy in the background using the following command: 
-    ```bash
-    kubectl proxy --port=8001 &
-    ```
-3. Run the following command to download and unpack the configuration from the
-   `configz` endpoint. The command is long, so be careful when copying and
-   pasting.
-
-    ```bash
-    NODE_NAME=the-name-of-the-node-you-are-reconfiguring; curl -sSL http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
-    ```
+1.  Choose a Node to reconfigure. In this example, the name of this Node is
+    referred to as `NODE_NAME`.
+2.  Start the kubectl proxy in the background using the following command: 
+      ```bash
+      kubectl proxy --port=8001 &
+      ```
+3.  Run the following command to download and unpack the configuration from the
+    `configz` endpoint. The command is long, so be careful when copying and
+    pasting. **If you use zsh**, replace the `${NODE_NAME}` in the URL with the
+    actual name of the node, because zsh automatically escapes opening curly
+    braces, which causes the command to fail.
+
+      ```bash
+      NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
+      ```
 
 {{< note >}}
 You need to manually add the `kind` and `apiVersion` to the downloaded
@@ -129,7 +133,7 @@ object, because they are not reported by the `configz` endpoint.
 
 Using a text editor, change one of the parameters in the
 file generated by the previous procedure. For example, you
-might add the QPS parameter `eventRecordQPS`.
+might edit the QPS parameter `eventRecordQPS`.
 
 #### Push the configuration file to the control plane
 
@@ -252,13 +256,15 @@ The following is an example response:
 If an error occurs, the Kubelet reports it in the `Node.Status.Config.Error`
 structure. Possible errors are listed in
 [Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages).
-If you see an error, you can search for it in the Kubelet's log for additional
-details.
+You can search for the identical text in the Kubelet log for additional details
+and context about the error.
 
 #### Make more changes
 
-Follow the workflow above to make more changes and push them again. Each
-time you change the ConfigMap's contents, it gets a new name.
+Follow the workflow above to make more changes and push them again. Each time
+you push a ConfigMap with new contents, the --append-hash kubectl option creates
+the ConfigMap with a new name. The safest rollout strategy is to first create a
+new ConfigMap, and then update the Node to use the new ConfigMap.
 
 #### Reset the Node to use its local default configuration
 
@@ -269,8 +275,9 @@ Node using `kubectl edit node ${NODE_NAME}` and remove the
 #### Observe that the Node is using its local default configuration
 
 After removing this subfield, `Node.Status.Config` eventually becomes
-empty, since all config sources have been reset to `nil`, which indicates that the local
-default config is `assigned`, `active`, and `lastKnownGood`), and no error is reported.
+empty, since all config sources have been reset to `nil`, which indicates that
+the local default config is `assigned`, `active`, and `lastKnownGood`, and no
+error is reported.
 
 {{% /capture %}}