pr_release-1.16_reconfig-kubelet

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

@@ -54,7 +54,7 @@ fields is available in the inline `KubeletConfiguration`
 
 - Kubernetes v1.11 或者更高版本配置在主节点和节点上
 - kubectl v1.11 或者更高版本和集群配置通信
-- The Kubelet's `--dynamic-config-dir` flag 必须设置在节点的可写目录上
+- The Kubelet `--dynamic-config-dir` flag 必须设置在节点的可写目录上
 
 {{% /capture %}}
 
@@ -212,33 +212,37 @@ installed, but you can adapt the tasks if you prefer to extract the
 -->
 
 1. 选择一个节点去重新配置，在此示例中，此节点的名称为 `NODE_NAME`。
-2. 使用以下命令在后台启动kubectl代理：
+2. 使用以下命令在后台启动 kubectl 代理：
 
       ```bash
       kubectl proxy --port=8001 &
       ```
 
 3. 运行以下命令从 `configz` 端点中下载并解压配置。这个命令很长，因此在复制和黏贴时要小心。
-**如果您使用zsh**，请注意常见的 zsh 配置添加反斜杠转义URL中变量名称周围的大括号的开始和结束。
-例如：在粘贴期间，`$ {NODE_NAME}` 将被重写为 `$ \ {NODE_NAME \}`。
+**如果您使用 zsh**，请注意常见的 zsh 配置添加反斜杠转义 URL 中变量名称周围的大括号的开始和结束。
+例如：在粘贴期间，`$ {NODE_NAME}` 将被重写为 `$\{NODE_NAME\}`。
 您必须在运行命令之前删除反斜杠，否则命令将失败。
 
  ```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
-object, because they are not reported by the `configz` endpoint.
+object，because they are not reported by the `configz` endpoint。
 您需要手动将 `kind` 和 `apiVersion` 添加到下载对象中，因为它们不是由 `configz` 端点报出的。
+
 {{< /note >}}
 
 <!-- #### Edit the configuration file -->
 #### 修改配置文件
-
+<!--
 Using a text editor, change one of the parameters in the
 file generated by the previous procedure. For example, you
 might edit the QPS parameter `eventRecordQPS`.
+-->
+
 使用文本编辑器，在这个文件里，改变之前的程序生成的一个参数。例如，你或许会修改 QPS 参数  `eventRecordQPS`。
 
 <!-- #### Push the configuration file to the control plane -->
@@ -252,6 +256,7 @@ following command:
 kubectl -n kube-system create configmap my-node-config --from-file=kubelet=kubelet_configz_${NODE_NAME} --append-hash -o yaml
 ```
 -->
+
 用以下命令把配置文件推送到控制平面：
 
 ```bash
@@ -276,7 +281,7 @@ data:
     {...}
 ```
 -->
-这是一个响应有效的例子：
+这是一个有效响应的例子：
 
 ```none
 apiVersion: v1
@@ -297,7 +302,8 @@ data:
 The ConfigMap is created in the `kube-system` namespace because this
 ConfigMap configures a Kubelet, which is Kubernetes system component.
 -->
-ConfigMap是在 `kube-system` 命名空间中创建的，因为 ConfigMap 配置了 Kubelet，它是 Kubernetes 的系统组件。
+
+ConfigMap 是在 `kube-system` 命名空间中创建的，因为 ConfigMap 配置了 Kubelet，它是 Kubernetes 的系统组件。
 
 <!--
 The `--append-hash` option appends a short checksum of the ConfigMap contents
@@ -306,8 +312,9 @@ automatically, yet deterministically, generates new names for new ConfigMaps.
 The name that includes this generated hash is referred to as `CONFIG_MAP_NAME`
 in the following examples.
 -->
-`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。 这对于编辑然后推送工作流程很方便，因为它
-自动并确定地为新ConfigMaps生成新的名称。在以下示例中，包含生成的哈希名称为 `CONFIG_MAP_NAME`。
+
+`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。这对于编辑然后推送工作流程很方便，因为它
+自动并确定地为新 ConfigMaps 生成新的名称。在以下示例中，包含生成的哈希名称为 `CONFIG_MAP_NAME`。
 
 <!-- #### Set the Node to use the new configuration -->
 #### 用新配置创建新的节点
@@ -330,6 +337,7 @@ configSource:
         kubeletConfigKey: kubelet
 ```
 -->
+
 用下面的命令行编辑节点的参数来指向新的 ConfigMap：
 
 ```bash
@@ -352,8 +360,9 @@ You must specify all three of `name`, `namespace`, and `kubeletConfigKey`.
 The `kubeletConfigKey` parameter shows the Kubelet which key of the ConfigMap
 contains its config.
 -->
-您必须指定这三个参数中的每一个 `name`, `namespace` 和 `kubeletConfigKey`。
-`kubeletConfigKey` 这个参数显示出 Kubelet 上的哪个 key 包含了 ConfigMap 的配置。
+
+您必须指定这三个参数中的每一个`name`，`namespace`和`kubeletConfigKey`。
+`kubeletConfigKey`这个参数显示出 Kubelet 上的哪个 key 包含了 ConfigMap 的配置。
 
 <!-- #### Observe that the Node begins using the new configuration -->
 #### 使用新配置监察节点
@@ -369,11 +378,12 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and
 - The `lastKnownGood` configuration is the version the
   Kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`.
 -->
+
 用 `kubectl get node ${NODE_NAME} -o yaml` 命令回收节点并用命令 `Node.Status.Config` 检查节点状态配置。
-在这个状态报告的配置里，对应这些配置源 `active`，`assigned` 和 `lastKnownGood`。
+在这个状态报告的配置里，对应这些配置源`active`，`assigned`和 `lastKnownGood`。
 
 - `active` 是 Kubelet 当前运行的版本。
-- `assigned` 参数是 Kubelet 基于 `Node.Spec.ConfigSource` 的最新版本.
+- `assigned` 参数是 Kubelet 基于 `Node.Spec.ConfigSource` 的最新版本。
 - `lastKnownGood` 参数是 Kubelet 的回退版本，如果在 `Node.Spec.ConfigSource` 中分配了无效的配置。
 
 <!--
@@ -383,9 +393,10 @@ match a valid `assigned` config after the Kubelet becomes comfortable with the c
 The details of how the Kubelet determines a config should become the `lastKnownGood` are
 not guaranteed by the API, but is currently implemented as a 10-minute grace period.
 -->
+
 如果用本地的配置部署节点，使其设置成默认值，这个`lastKnownGood`配置可能不存在。
 在 Kubelet 配置好后，将更新 `lastKnownGood` 去匹配一个有效的 `assigned` 配置。
-判断如何配置 Kubelet 的细节是使`lastKnownGood`不受API限制，但目前实施为 10分钟 的宽限期。
+判断如何配置 Kubelet 的细节是使`lastKnownGood`不受 API 限制，但目前实施为 10 分钟的宽限期。
 
 <!--
 You can use the following command (using `jq`) to filter down
@@ -430,7 +441,7 @@ The following is an example response:
 
 ```
 -->
-您可以使用以下命令 (using `jq`) 过滤到配置状态：
+您可以使用以下命令（using `jq`）过滤到配置状态：
 
 ```bash
 kubectl get no ${NODE_NAME} -o json | jq '.status.config'
@@ -478,8 +489,8 @@ structure. Possible errors are listed in
 You can search for the identical text in the Kubelet log for additional details
 and context about the error.
 -->
-如果发生错误，Kubelet 会在 `Node.Status.Config.Error` 中显示出它的结构体。 可能的错误列在
-[了解 Node.Status.Config.Error 信息](#understanding-node-status-config-error-messages).
+
+如果发生错误，Kubelet 会在 `Node.Status.Config.Error` 中显示出它的结构体。可能的错误列在 [了解节点配置错误信息](#了解节点配置错误信息)。
 您可以在 Kubelet 日志中搜索相同的文本以获取更多详细信息和有关错误的上下文。
 
 <!-- #### Make more changes -->
@@ -491,7 +502,8 @@ 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.
 -->
-按照下面的工作流程做出更多的改变并再次推送它们。你每次推送一个ConfigMap 的新内容时，--append-hash kubectl 选项都会给 ConfigMap 创建一个新的名称。
+
+按照下面的工作流程做出更多的改变并再次推送它们。你每次推送一个 ConfigMap 的新内容时，--append-hash kubectl 选项都会给 ConfigMap 创建一个新的名称。
 最安全的推出策略是首先创建一个新的 ConfigMap，然后更新 节点 以使用新的 ConfigMap。
 
 <!-- #### Reset the Node to use its local default configuration -->
@@ -515,7 +527,7 @@ the local default config is `assigned`, `active`, and `lastKnownGood`, and no
 error is reported.
 -->
 在删除此字段后，`Node.Status.Config` 最终变成空，所有配置源都已重置为 `nil`，这表示
-本地默认配置是 `assigned`，`active` 和 `lastKnownGood`这三个参数，没有报告错误。
+本地默认配置是`assigned`，`active` 和 `lastKnownGood`这三个参数，没有报告错误。
 
 {{% /capture %}}
 
@@ -532,6 +544,7 @@ This example uses `kubectl patch`:
 kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}"
 ```
 -->
+
 您可以使用几种不同的机制来更改节点的 configSource。
 这个例子使用`kubectl patch`：
 
@@ -540,7 +553,8 @@ kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{
 ```
 
 <!-- ## Understanding how the Kubelet checkpoints config -->
-## 了解Kubelet检查点的配置方式
+
+## 了解 Kubelet 检查点的配置方式
 
 <!--
 When a new config is assigned to the Node, the Kubelet downloads and unpacks the
@@ -552,8 +566,9 @@ exits if it detects that the assigned config has changed. When the Kubelet is
 restarted by the OS-level service manager (such as `systemd`), it reads the new
 metadata and uses the new config.
 -->
+
 当为节点分配新配置时，Kubelet 会在本地磁盘上，下载并解压配置负载为一组文件。Kubelet 还记录元数据
-在本地跟踪已分配和最后已知良好的配置源，以便 Kubelet 知道在重新启动时使用哪个配置，即使API服务器变为不可用。 在检查点配置和相关元数据之后，如果检测到已分配的配置改变了，则 Kubelet 退出。 当K ubelet 被 OS 级服务管理器（例如`systemd`）重新启动时，它会读取新的元数据并使用新配置。
+在本地跟踪已分配和最后已知良好的配置源，以便 Kubelet 知道在重新启动时使用哪个配置，即使 API 服务器变为不可用。在检查点配置和相关元数据之后，如果检测到已分配的配置改变了，则 Kubelet 退出。当 Kubelet 被 OS 级服务管理器（例如`systemd`）重新启动时，它会读取新的元数据并使用新配置。
 
 <!--
 The recorded metadata is fully resolved, meaning that it contains all necessary
@@ -563,9 +578,8 @@ via the idempotent `namespace/name` that identifies the target ConfigMap; the Ku
 tries to use the latest version of this ConfigMap.
 -->
 当记录的元数据已被完全解析时，意味着它包含的所有必需的信息去选择一个指定的
-配置版本 - 通常是 `UID` 和 `ResourceVersion`。与 `Node.Spec.ConfigSource` 形成对比，
-通过幂等 `namespace/name` 预期声明配置来标识目标 ConfigMap；Kubelet
-尝试使用此 ConfigMap的 最新版本。
+配置版本通常是`UID`和`ResourceVersion`。与`Node.Spec.ConfigSource`形成对比，
+通过幂等`namespace/name`预期声明配置来标识目标 ConfigMap；Kubelet 尝试使用此 ConfigMap 的最新版本。
 
 <!--
 When you are debugging problems on a node, you can inspect the Kubelet's config
@@ -583,7 +597,8 @@ metadata and checkpoints. The structure of the Kubelet's checkpointing directory
   | - ...
 ```
 -->
-当您在节点上调试问题时，可以检查Kubelet的配置元数据和检查点。Kubelet 的检查点目录结构是：
+
+当您在节点上调试问题时，可以检查 Kubelet 的配置元数据和检查点。Kubelet 的检查点目录结构是：
 
 ```none
 - --dynamic-config-dir (root for managing dynamic config)
@@ -598,14 +613,16 @@ metadata and checkpoints. The structure of the Kubelet's checkpointing directory
 ```
 
 <!-- ## Understanding Node.Status.Config.Error messages -->
-## 了解 Node.Status.Config.Error 信息
+
+## 了解节点配置错误信息
 
 <!--
 The following table describes error messages that can occur
 when using Dynamic Kubelet Config. You can search for the identical text
 in the Kubelet log for additional details and context about the error.
 -->
-下表描述了使用Dynamic Kubelet配置时可能发生的错误消息。 您可以在 Kubelet 日志中搜索相同的文本
+
+下表描述了使用 Dynamic Kubelet 配置时可能发生的错误消息。您可以在 Kubelet 日志中搜索相同的文本
 来获取有关错误的其他详细信息和上下文。
 
 <!--
@@ -652,25 +669,25 @@ in the Kubelet log for additional details and context about the error.
     <td><p>Kubelet可能无法解析下载配置的有效负载，或者当尝试从磁盘中加载有效负载时，遇到文件系统错误。</p></td>
 </tr>
 <tr>
-    <td><p>无法验证配置，请参阅Kubelet日志了解详细信息</p></td>
+    <td><p>无法验证配置，请参阅 Kubelet 日志了解详细信息</p></td>
     <td><p>有效负载中的配置将任何命令行标志所覆盖的和这些标志的特性们合并，包括配置文件和远程有效负载，
-    它们一起被Kubelet确定为无效。</p></td>
+    它们一起被 Kubelet 确定为无效。</p></td>
 </tr>
 <tr>
     <td><p>无效的 NodeConfigSource，理应刚好一个子字段必须是非空的，但这些字段都是空的</p></td>
-    <td><p>由 API 服务器验证 Node.Spec.ConfigSource 是否包含至少一个非空子字段，可能原因是 Kubelet 比API 服务器版本低，不识别更新的源类型。</p></td>
+    <td><p>由 API 服务器验证 Node.Spec.ConfigSource 是否包含至少一个非空子字段，可能原因是 Kubelet 比 API 服务器版本低，不识别更新的源类型。</p></td>
 </tr>
 <tr>
-    <td><p>无法同步：无法下载配置，请参阅Kubelet日志了解详细信息</p></td>
-    <td><p>Kubelet无法下载配置。可能是 Node.Spec.ConfigSource 无法解析为具体的API对象，或者网络错误中断了下载。 当处于此错误状态时，Kubelet 将重新下载。</p></td>
+    <td><p>无法同步：无法下载配置，请参阅 Kubelet 日志了解详细信息</p></td>
+    <td><p>Kubelet 无法下载配置。可能是 Node.Spec.ConfigSource 无法解析为具体的 API 对象，或者网络错误中断了下载。 当处于此错误状态时，Kubelet 将重新下载。</p></td>
 </tr>
 <tr>
-    <td><p>无法同步：内部故障，请参阅Kubelet日志了解详细信息</p></td>
+    <td><p>无法同步：内部故障，请参阅 Kubelet 日志了解详细信息</p></td>
     <td><p>Kubelet遇到了一些内部问题，因此无法更新其配置。 例如包括文件系统错误和从内部函数缓存中读取对象。</p></td>
 </tr>
 <tr>
-    <td><p>内部故障，请参阅Kubelet日志了解详细信息</p></td>
-    <td><p>在配置同步循环之外操作配置时，Kubelet遇到了一些内部问题。</p></td>
+    <td><p>内部故障，请参阅 Kubelet 日志了解详细信息</p></td>
+    <td><p>在配置同步循环之外操作配置时，Kubelet 遇到了一些内部问题。</p></td>
 </tr>
 </table>