From b7f82b11bc9adc8e1d4e2f6cc72c817f1927deb6 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 14 Aug 2020 23:02:31 +0800 Subject: [PATCH] [zh] Rework the reconfig kubelet task Most of the translation are good. However, there are quite some places where the current text failed to convey the correct message ... --- .../administer-cluster/reconfigure-kubelet.md | 625 ++++++++---------- 1 file changed, 293 insertions(+), 332 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md index 126cbf4b19..1a4867a9e7 100644 --- a/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -1,18 +1,14 @@ --- -title: 在实时集群上重新配置节点的 Kubelet +title: 在运行中的集群上重新配置节点的 kubelet content_type: task --- @@ -24,12 +20,12 @@ content_type: task allows you to change the configuration of each Kubelet in a live Kubernetes cluster by deploying a ConfigMap and configuring each Node to use it. --> -[动态Kubelet配置](https://github.com/kubernetes/enhancements/issues/281) -引导你在一个运行的 Kubernetes 集群上更改每一个 Kubelet 的配置，通过部署 ConfigMap 并配置每个节点来使用它。 +[动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281) +允许你在一个运行的 Kubernetes 集群上通过部署 ConfigMap +并配置每个节点来使用它来更改每个 kubelet 的配置，。 -{{< warning >}} -**警告**：所有Kubelet配置参数都可以动态地更改，但这对某些参数来说是不安全的。在决定动态更改参数之前，你需要深刻理解这种变化将如何影响你的集群的行为。 -在把一组节点推广到集群范围之前，都要仔细地测试这些节点上的配置变化。与配置相关的建议可以在具体的文件下找到，内联 `KubeletConfiguration` -[类型文档](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)。 +{{< warning >}} +所有 kubelet 配置参数都可以动态更改，但这对某些参数来说是不安全的。 +在决定动态更改参数之前，你需要深刻理解这种变化将如何影响你的集群的行为。 +在把一组变更推广到集群范围之前，需要在较小规模的节点集合上仔细地测试这些配置变化。 +与特定字段配置相关的建议可以在源码中 `KubeletConfiguration` +[类型文档](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)中找到。 {{< /warning >}} - - ## {{% heading "prerequisites" %}} +你需要一个 Kubernetes 集群。 +你需要 v1.11 或更高版本的 kubectl，并以配置好与集群通信。 +{{< version-check >}} +你的集群 API 服务器版本（如 v1.12）不能比你所用的 kubectl +的版本差不止一个小版本号。 +例如，如果你的集群在运行 v1.16，那么你可以使用 v1.15、v1.16、v1.17 的 kubectl， +所有其他的组合都是 +[不支持的](/zh/docs/setup/release/version-skew-policy/#kubectl)。 -- Kubernetes v1.11 或者更高版本配置在主节点和节点上 -- kubectl v1.11 或者更高版本和集群配置通信 -- The Kubelet `--dynamic-config-dir` flag 必须设置在节点的可写目录上 + +某些例子中使用了命令行工具 [jq](https://stedolan.github.io/jq/)。 +你并不一定需要 `jq` 才能完成这些任务，因为总是有一些手工替代的方式。 +针对你所重新配置的每个节点，你必须设置 kubelet 的参数 +`-dynamic-config-dir`，使之指向一个可写的目录。 - -## 在你集群中的一个实时节点上配置Kubelet + +## 重配置 集群中运行节点上的 kubelet - ### 基本工作流程概述 -在实时集群中配置 Kubelet 的基本工作流程如下： +在运行中的集群中配置 kubelet 的基本工作流程如下： -1. 编写一个 YAML 或 JSON 的配置文件包含 Kubelet 的配置。 +1. 编写一个 YAML 或 JSON 的配置文件包含 kubelet 的配置。 2. 将此文件包装在 ConfigMap 中并将其保存到 Kubernetes 控制平面。 -3. 更新 Kubelet 的相应节点对象以使用此 ConfigMap。 +3. 更新 kubelet 的相应节点对象以使用此 ConfigMap。 -每个 Kubelet 都会在其各自的节点对象上查看配置引用。当此引用更改时，Kubelet 将下载新配置， +每个 kubelet 都会在其各自的节点对象上监测（Watch）配置引用。当引用更改时，kubelet 将下载新配置， 更新本地引用以引用该文件，然后退出。 -要想使该功能正常地工作，您必须运行操作系统级别的服务管理器（如systemd），如果退出，将重启Kubelet。 -当Kubelet重新启动时，它将开始使用新配置。 +要想使该功能正常地工作，你必须运行操作系统级别的服务管理器（如 systemd）， +在 kubelet 退出时将其重启。 +kubelet 重新启动时，将开始使用新配置。 -这个新配置完全地覆盖 `--config` 所提供的配置，并被命令行标志覆盖。新配置中未指定的值将收到适合配置版本的默认值 -(e.g. `kubelet.config.k8s.io/v1beta1`)，除非被标志覆盖。 +这个新配置完全地覆盖 `--config` 所提供的配置，并被命令行标志覆盖。 +新配置中未指定的值将收到适合配置版本的默认值 +(e.g. `kubelet.config.k8s.io/v1beta1`)，除非被命令行标志覆盖。 -这个节点的 Kubelet 配置状态通过命令 `Node.Spec.Status.Config` 获取。一旦您已经改变了一个节点去使用新的 ConfigMap ， -您就可以观察此状态以确认这个节点正在使用的预期配置。 +节点 kubelet 配置状态可通过 `node.spec.status.config` 获取。 +一旦你已经改变了一个节点去使用新的 ConfigMap， +就可以观察此状态以确认该节点正在使用的预期配置。 -这个文档描述编辑节点信息用命令 `kubectl edit`，还有一些其他的方式去修改节点的规范，包括命令 `kubectl patch`， -例如，哪一个更利于脚本化的工作流程。 +本文用命令 `kubectl edit` 描述节点的编辑，还有一些其他的方式去修改节点的规约， +包括更利于脚本化的工作流程的 `kubectl patch`。 -这个文档仅仅讲述了在单节点上使用每一个 ConfigMap。请注意对于多个节点使用相同的 ConfigMap 也是有效的。 +本文仅仅讲述在单节点上使用每个 ConfigMap。请注意对于多个节点使用相同的 ConfigMap +也是合法的。 -{{< warning >}} -**警告**：通过更新本地的 ConfigMap *有可能* 会改变配置信息，这样会导致所有 Kubelets 所配置的 ConfigMap 同步更新。 -它是更安全的去处理 ConfigMap 按照惯例不变，借助于 `kubectl`'s `--append-hash` 选项，并逐步把更新推广到 `Node.Spec.ConfigSource`。 +{{< warning >}} +通过就地更新 ConfigMap 来更改配置是 *可能的*。 +尽管如此，这样做会导致所有配置为使用该 ConfigMap 的 kubelet 被同时更新。 +更安全的做法是按惯例将 ConfigMap 视为不可变更的，借助于 +`kubectl` 的 `--append-hash` 选项逐步把更新推广到 `node.spec.configSource`。 {{< /warning >}} - -### 节点授权器的自动RBAC规则 - -以前，您需要手动创建RBAC规则允许节点访问其分配的ConfigMaps。 节点授权器现在 -自动地配置这些规则。 +### 节点鉴权器的自动 RBAC 规则 - -### 生成包含当前配置的文件 +以前，你需要手动创建 RBAC 规则以允许节点访问其分配的 ConfigMap。节点鉴权器现在 +能够自动配置这些规则。 -动态 Kubelet 配置特性允许您提供覆盖对于整个配置对象，而不是每个字段的叠加。 这是一个 -更简单的模型，可以更轻松地跟踪配置值的来源和调试问题。 然而，妥协是你必须从现有配置的认识开始， -以确保您只更改您打算修改的字段。 +### 生成包含当前配置的文件 + +动态 kubelet 配置特性允许你为整个配置对象提供一个重载配置，而不是靠单个字段的叠加。 +这是一个更简单的模型，可以更轻松地跟踪配置值的来源，更便于调试问题。 +然而，相应的代价是你必须首先了解现有配置，以确保你只更改你打算修改的字段。 -理想情况下，Kubelet 将被引导从磁盘上的一个文件，并且你可以编辑这个文件（也可以是版本控制的）， -去创建第一个 Kubelet ConfigMap (参考文档 [通过配置文件设置Kubelet参数](/docs/tasks/administer-cluster/kubelet-config-file))， -目前，Kubelet 使用 **文件和命令行标志的组合** 进行引导来覆盖文件中的配置。 -作为解决方法，您可以生成一个配置文件包含节点当前的组态，通过 kubectl 代理访问Kubelet服务器的 `configz` 端点。 -该端点在其当前实现中，旨在被用来作为一个调试辅助工具。在生产环境下，不要依赖此端点的特性。 -下面的例子使用 `jq` 命令来简化使用 JSON。按照所写的步骤，您需要安装 `jq` ， -但如果您喜欢手动提取 `kubeletconfig` 子对象，您也可以完成这个任务。 +组件 kubelet 从其配置文件中加载配置数据，不过你可以通过设置命令行标志 +来重载文件中的一些配置。这意味着，如果你仅知道配置文件的内容，而你不知道 +命令行重载了哪些配置，你就无法知道 kubelet 的运行时配置是什么。 + + +因为你需要知道运行时所使用的配置才能重载之，你可以从 kubelet 取回其运行时配置。 +你可以通过访问 kubelet 的 `configz` 末端来生成包含节点当前配置的配置文件； +这一操作可以通过 `kubectl proxy` 来完成。 +下一节解释如何完成这一操作。 + + +{{< caution >}} +组件 `kubelet` 上的 `configz` 末端是用来协助调试的，并非 kubelet 稳定行为的一部分。 +请不要在产品环境下依赖此末端的行为，也不要在自动化工具中使用此末端。 +{{< /caution >}} + + +关于如何使用配置文件来配置 kubelet 行为的更多信息可参见 +[通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file) +文档。 #### 生成配置文件 + +{{< note >}} +下面的任务步骤中使用了 `jq` 命令以方便处理 JSON 数据。为了完成这里讲述的任务， +你需要安装 `jq`。如果你更希望手动提取 `kubeletconfig` 子对象，也可以对这里 +的对应步骤做一些调整。 +{{< /note >}} + +1. 选择要重新配置的节点。在本例中，此节点的名称为 `NODE_NAME`。 +2. 使用以下命令在后台启动 kubectl 代理： - ```bash - kubectl proxy --port=8001 & - ``` - + ```bash + kubectl proxy --port=8001 & + ``` + +3. 运行以下命令从 `configz` 端点中下载并解压配置。这个命令很长，因此在复制粘贴时要小心。 + **如果你使用 zsh**，请注意常见的 zsh 配置要添加反斜杠转义 URL 中变量名称周围的大括号。 + 例如：在粘贴时，`${NODE_NAME}` 将被重写为 `$\{NODE_NAME\}`。 + 你必须在运行命令之前删除反斜杠，否则命令将失败。 -1. 选择一个节点去重新配置，在此示例中，此节点的名称为 `NODE_NAME`。 -2. 使用以下命令在后台启动 kubectl 代理： + ```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} + ``` - ```bash - kubectl proxy --port=8001 & - ``` - -3. 运行以下命令从 `configz` 端点中下载并解压配置。这个命令很长，因此在复制和黏贴时要小心。 -**如果您使用 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 + +{{< note >}} +你需要手动将 `kind` 和 `apiVersion` 添加到下载对象中，因为它们不是由 `configz` 末端 +返回的。 {{< /note >}} - -#### 修改配置文件 +#### 修改配置文件 -使用文本编辑器，在这个文件里，改变之前的程序生成的一个参数。例如，你或许会修改 QPS 参数 `eventRecordQPS`。 - - -#### 把配置文件推送到控制平面 +使用文本编辑器，改变上述操作生成的文件中一个参数。 +例如，你或许会修改 QPS 参数 `eventRecordQPS`。 +#### 把配置文件推送到控制平面 -用以下命令把配置文件推送到控制平面： +用以下命令把编辑后的配置文件推送到控制平面： ```bash -kubectl -n kube-system create configmap my-node-config --from-file=kubelet=kubelet_configz_${NODE_NAME} --append-hash -o yaml +kubectl -n kube-system create configmap my-node-config \ + --from-file=kubelet=kubelet_configz_${NODE_NAME} \ + --append-hash -o yaml ``` -这是一个有效响应的例子： +下面是合法响应的一个例子： -```none +```yaml apiVersion: v1 kind: ConfigMap metadata: @@ -300,53 +333,40 @@ data: ``` - -ConfigMap 是在 `kube-system` 命名空间中创建的，因为 ConfigMap 配置了 Kubelet，它是 Kubernetes 的系统组件。 +你会在 `kube-system` 命名空间中创建 ConfigMap，因为 kubelet 是 Kubernetes 的系统组件。 - -`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。这对于编辑然后推送工作流程很方便，因为它 -自动并确定地为新 ConfigMaps 生成新的名称。在以下示例中，包含生成的哈希名称为 `CONFIG_MAP_NAME`。 - - -#### 用新配置创建新的节点 +`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。 +这对于先编辑后推送的工作流程很方便， +因为它自动并确定地为新 ConfigMap 生成新的名称。 +在以下示例中，包含生成的哈希字符串的对象名被称为 `CONFIG_MAP_NAME`。 - -用下面的命令行编辑节点的参数来指向新的 ConfigMap： +#### 配置节点使用新的配置 ```bash kubectl edit node ${NODE_NAME} ``` - -在您的文本编辑器中，在 `spec` 下增添以下 YAML： + +在你的文本编辑器中，在 `spec` 下增添以下 YAML： ```yaml configSource: @@ -361,14 +381,12 @@ 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 ConfigMap 中的哪个键下面包含所要的配置。 +#### 观察节点开始使用新配置 -用 `kubectl get node ${NODE_NAME} -o yaml` 命令回收节点并用命令 `Node.Status.Config` 检查节点状态配置。 -在这个状态报告的配置里，对应这些配置源`active`，`assigned`和 `lastKnownGood`。 +用 `kubectl get node ${NODE_NAME} -o yaml` 命令读取节点并检查 `node.status.config` 内容。 +状态部分报告了对应 `active`（使用中的）配置、`assigned`（被赋予的）配置和 +`lastKnownGood`（最近已知可用的）配置的配置源。 -- `active` 是 Kubelet 当前运行的版本。 -- `assigned` 参数是 Kubelet 基于 `Node.Spec.ConfigSource` 的最新版本。 -- `lastKnownGood` 参数是 Kubelet 的回退版本，如果在 `Node.Spec.ConfigSource` 中分配了无效的配置。 +- `active` 是 kubelet 当前运行时所使用的版本。 +- `assigned` 参数是 kubelet 基于 `node.spec.configSource` 所解析出来的最新版本。 +- `lastKnownGood` 参数是 kubelet 的回退版本；如果在 `node.spec.configSource` 中 + 包含了无效的配置值，kubelet 可以回退到这个版本。 - -如果用本地的配置部署节点，使其设置成默认值，这个`lastKnownGood`配置可能不存在。 -在 Kubelet 配置好后，将更新 `lastKnownGood` 去匹配一个有效的 `assigned` 配置。 -判断如何配置 Kubelet 的细节是使`lastKnownGood`不受 API 限制，但目前实施为 10 分钟的宽限期。 +如果用本地配置部署节点，使其设置成默认值，这个 `lastKnownGood` 配置可能不存在。 +在 kubelet 配置好后，将更新 `lastKnownGood` 为一个有效的 `assigned` 配置。 +决定如何确定某配置成为 `lastKnownGood` 配置的细节并不在 API 保障范畴， +不过目前实现中采用了 10 分钟的宽限期。 -您可以使用以下命令（using `jq`）过滤到配置状态： +你可以使用以下命令（使用 `jq`）过滤出配置状态： ```bash kubectl get no ${NODE_NAME} -o json | jq '.status.config' ``` + 以下是一个响应示例： ```json @@ -480,9 +465,15 @@ kubectl get no ${NODE_NAME} -o json | jq '.status.config' } } } - ``` + +如果你没有安装 `jq`，你可以查看整个响应对象，查找其中的 `node.status.config` +部分。 + - -如果发生错误，Kubelet 会在 `Node.Status.Config.Error` 中显示出它的结构体。可能的错误列在 [了解节点配置错误信息](#了解节点配置错误信息)。 -您可以在 Kubelet 日志中搜索相同的文本以获取更多详细信息和有关错误的上下文。 - - -#### 做出更多的改变 +如果发生错误，kubelet 会在 `node.status.config.error` 中显示出错误信息的结构体。 +可能的错误列在[了解节点配置错误信息](#understanding-node-config-status-errors)节。 +你可以在 kubelet 日志中搜索相同的文本以获取更多详细信息和有关错误的上下文。 +#### 做出更多的改变 {#make-more-changes} -按照下面的工作流程做出更多的改变并再次推送它们。你每次推送一个 ConfigMap 的新内容时，--append-hash kubectl 选项都会给 ConfigMap 创建一个新的名称。 -最安全的推出策略是首先创建一个新的 ConfigMap，然后更新 节点 以使用新的 ConfigMap。 - - -#### 重置节点以使用其本地默认配置 +按照下面的工作流程做出更多的改变并再次推送它们。 +你每次推送一个 ConfigMap 的新内容时，kubeclt 的 `--append-hash` 选项都会给 +ConfigMap 创建一个新的名称。 +最安全的上线策略是首先创建一个新的 ConfigMap，然后更新节点以使用新的 ConfigMap。 -重置节点去使用已经配好的的配置，用 `kubectl edit node $ {NODE_NAME}` 命令编辑节点，并删除 -`Node.Spec.ConfigSource` 字段。 +#### 重置节点以使用其本地默认配置 - -#### 监察正在使用本地默认配置的节点 +要重置节点，使其使用节点创建时使用的配置，可以用 +`kubectl edit node $ {NODE_NAME}` 命令编辑节点，并删除 `node.spec.configSource` +字段。 + + -在删除此字段后，`Node.Status.Config` 最终变成空，所有配置源都已重置为 `nil`，这表示 -本地默认配置是`assigned`，`active` 和 `lastKnownGood`这三个参数，没有报告错误。 - +#### 观察节点正在使用本地默认配置 +在删除此字段后，`node.status.config` 最终变成空，所有配置源都已重置为 `nil`。 +这表示本地默认配置成为了 `assigned`、`active` 和 `lastKnownGood` 配置， +并且没有报告错误。 - -## Kubectl 补丁示例 - +## `kubectl patch` 示例 -您可以使用几种不同的机制来更改节点的 configSource。 -这个例子使用`kubectl patch`： +你可以使用几种不同的机制来更改节点的 configSource。 + +本例使用`kubectl patch`： ```bash kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}" ``` - - - -## 了解 Kubelet 检查点的配置方式 - +## 了解 Kubelet 如何为配置生成检查点 -当为节点分配新配置时，Kubelet 会在本地磁盘上，下载并解压配置负载为一组文件。Kubelet 还记录元数据 -在本地跟踪已分配和最后已知良好的配置源，以便 Kubelet 知道在重新启动时使用哪个配置，即使 API 服务器变为不可用。在检查点配置和相关元数据之后，如果检测到已分配的配置改变了，则 Kubelet 退出。当 Kubelet 被 OS 级服务管理器（例如`systemd`）重新启动时，它会读取新的元数据并使用新配置。 +当为节点赋予新配置时，kubelet 会下载并解压配置负载为本地磁盘上的一组文件。 +kubelet 还记录一些元数据，用以在本地跟踪已赋予的和最近已知良好的配置源，以便 +kubelet 在重新启动时知道使用哪个配置，即使 API 服务器变为不可用。 +在为配置信息和相关元数据生成检查点之后，如果检测到已赋予的配置发生改变，则 kubelet 退出。 +当 kubelet 被 OS 级服务管理器（例如 `systemd`）重新启动时，它会读取新的元数据并使用新配置。 -当记录的元数据已被完全解析时，意味着它包含的所有必需的信息去选择一个指定的 -配置版本通常是`UID`和`ResourceVersion`。与`Node.Spec.ConfigSource`形成对比， -通过幂等`namespace/name`预期声明配置来标识目标 ConfigMap；Kubelet 尝试使用此 ConfigMap 的最新版本。 +当记录的元数据已被完全解析时，意味着它包含选择一个指定的配置版本所需的所有信息 +-- 通常是 `UID` 和 `ResourceVersion`。 +这与 `node.spec.configSource` 形成对比，后者通过幂等的 `namespace/name` 声明来标识 +目标 ConfigMap；kubelet 尝试使用此 ConfigMap 的最新版本。 +当你在调试节点上问题时，可以检查 kubelet 的配置元数据和检查点。kubelet 的检查点目录结构是： + -当您在节点上调试问题时，可以检查 Kubelet 的配置元数据和检查点。Kubelet 的检查点目录结构是： - ```none -- --dynamic-config-dir (root for managing dynamic config) -| - meta - | - assigned (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the assigned config) - | - last-known-good (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the last-known-good config) +- --dynamic-config-dir （用于管理动态配置的根目录） +|-- meta + | - assigned （编码后的 kubeletconfig/v1beta1.SerializedNodeConfigSource 对象，对应赋予的配置） + | - last-known-good （编码后的 kubeletconfig/v1beta1.SerializedNodeConfigSource 对象，对应最近已知可用配置） | - checkpoints - | - uid1 (dir for versions of object identified by uid1) - | - resourceVersion1 (dir for unpacked files from resourceVersion1 of object with uid1) + | - uid1 （用 uid1 来标识的对象版本目录) + | - resourceVersion1 （uid1 对象 resourceVersion1 版本下所有解压文件的目录） | - ... | - ... ``` - + +## 了解节点配置错误信息 {#understanding-node-config-status-errors} -下表描述了使用 Dynamic Kubelet 配置时可能发生的错误消息。您可以在 Kubelet 日志中搜索相同的文本 -来获取有关错误的其他详细信息和上下文。 +下表描述了使用动态 kubelet 配置时可能发生的错误消息。 +你可以在 kubelet 日志中搜索相同的文本来获取有关错误的其他详细信息和上下文。 - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
错误信息可能的原因

无法加载配置，请参阅 Kubelet 日志了解详细信息

Kubelet可能无法解析下载配置的有效负载，或者当尝试从磁盘中加载有效负载时，遇到文件系统错误。

无法验证配置，请参阅 Kubelet 日志了解详细信息

有效负载中的配置将任何命令行标志所覆盖的和这些标志的特性们合并，包括配置文件和远程有效负载， - 它们一起被 Kubelet 确定为无效。

无效的 NodeConfigSource，理应刚好一个子字段必须是非空的，但这些字段都是空的

由 API 服务器验证 Node.Spec.ConfigSource 是否包含至少一个非空子字段，可能原因是 Kubelet 比 API 服务器版本低，不识别更新的源类型。

无法同步：无法下载配置，请参阅 Kubelet 日志了解详细信息

Kubelet 无法下载配置。可能是 Node.Spec.ConfigSource 无法解析为具体的 API 对象，或者网络错误中断了下载。 当处于此错误状态时，Kubelet 将重新下载。

无法同步：内部故障，请参阅 Kubelet 日志了解详细信息

Kubelet遇到了一些内部问题，因此无法更新其配置。 例如包括文件系统错误和从内部函数缓存中读取对象。

内部故障，请参阅 Kubelet 日志了解详细信息

在配置同步循环之外操作配置时，Kubelet 遇到了一些内部问题。

+{{< table caption = "理解 node.status.config.error 消息" >}} + 错误信息 | 可能的原因 +:----------------| :---------------- +failed to load config, see Kubelet log for details | kubelet 可能无法解析下载配置的有效负载，或者当尝试从磁盘中加载有效负载时，遇到文件系统错误。 +failed to validate config, see Kubelet log for details | 有效负载中的配置，与命令行标志所产生的覆盖配置以及特行门控的组合、配置文件本身、远程负载被 kubelet 判定为无效。 +invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | 由于 API 服务器负责对 node.spec.configSource 执行验证，检查其中是否包含至少一个非空子字段，这个消息可能意味着 kubelet 比 API 服务器版本低，因而无法识别更新的源类型。 +failed to sync: failed to download config, see Kubelet log for details | kubelet 无法下载配置数据。可能是 node.spec.configSource 无法解析为具体的 API 对象，或者网络错误破坏了下载。处于此错误状态时，kubelet 将重新尝试下载。 +failed to sync: internal failure, see Kubelet log for details | kubelet 遇到了一些内部问题，因此无法更新其配置。 例如：发生文件系统错误或无法从内部缓存中读取对象。 +internal failure, see Kubelet log for details | 在对配置进行同步的循环之外操作配置时，kubelet 遇到了一些内部问题。 + +{{< /table >}} + +## {{% heading "whatsnext" %}} + + +- 关于如何通过配置文件来配置 kubelet 的更多细节信息，可参阅 + [使用配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file). +- 阅读 API 文档中 [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) 说明