Edit This Page

节点

在 Kubernetes 中，节点（Node）是执行工作的机器，以前叫做 minion。根据你的集群环境，节点可以是一个虚拟机或者物理机器。每个节点都包含用于运行 pods 的必要服务，并由主控组件管理。节点上的服务包括 容器运行时、kubelet 和 kube-proxy。查阅架构设计文档中 Kubernetes 节点 一节获取更多细节。

• 节点状态
• 管理
• 节点拓扑
• API 对象
• 接下来

节点状态

一个节点的状态包含以下信息:

• 地址
• 条件
• 容量与可分配
• 信息

可以使用以下命令显示节点状态和有关节点的其他详细信息：

kubectl describe node <insert-node-name-here>

下面对每个章节进行详细描述。

地址

这些字段组合的用法取决于你的云服务商或者裸机配置。

• HostName：由节点的内核指定。可以通过 kubelet 的 --hostname-override 参数覆盖。
• ExternalIP：通常是可以外部路由的节点 IP 地址（从集群外可访问）。
• InternalIP：通常是仅可在集群内部路由的节点 IP 地址。

条件

conditions 字段描述了所有 Running 节点的状态。条件的示例包括：

节点条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的节点。

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

如果 Ready 条件处于状态 Unknown 或者 False 的时间超过了 pod-eviction-timeout（一个传递给 kube-controller-manager 的参数），节点上的所有 Pods 都会被节点控制器计划删除。默认的删除超时时长为5 分钟。某些情况下，当节点不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区节点上运行。

在 1.5 版本之前的 Kubernetes 里，节点控制器会将不能访问的 pods 从 apiserver 中强制删除。但在 1.5 或更高的版本里，在节点控制器确认这些 pods 已经在集群停止运行前不会强制删除它们。你可以看到这些处于 Terminating 或者 Unknown 状态的 pods 可能在无法访问的节点上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个节点是否已经永久的离开了集群，集群管理员可能需要手动删除这个节点对象。从 Kubernetes 删除节点对象将导致 apiserver 删除节点上所有运行的 Pod 对象并释放它们的名字。

在版本 1.12 中，TaintNodesByCondition 功能已升级为 Beta 功能，因此节点生命周期控制器会自动创建代表条件的 污点。同样，scheduler 在考虑节点时会忽略条件，而是查看节点的污点和 Pod 的容忍度。

现在用户可以在旧的调度模型和新的、更灵活的调度模型之间进行选择，一个没有任何容忍度的 Pod 会根据旧模型进行调度。但是能够容忍特定节点的污点的 Pod 则可以在该节点上调度执行。

警告: 启用此功能会在观察条件与到产生污点之间产生较小的延迟。此延迟通常少于一秒，但会增加成功调度但被 kubelet 拒绝的 Pod 数量。

容量与可分配

描述节点上的可用资源：CPU、内存和可以调度到节点上的 pods 的最大数量。

capacity 块中的字段指示节点拥有的资源总量。allocatable 块指示节点上可供普通 Pod 消耗的资源量。

可以在学习如何在节点上保留计算资源的同时阅读有关容量和可分配资源的更多信息。

信息

关于节点的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

管理

与 pods 和 services 不同，节点并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个节点时，它其实仅仅创建了一个对象来代表这个节点。创建以后，Kubernetes 将检查这个节点是否可用。例如，如果你尝试使用如下内容创建一个节点：

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes 会在内部创一个 Node 对象（用以表示节点），并基于 metadata.name 字段执行健康检查，对节点进行验证。如果节点可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略直到变为可用。

注意： Kubernetes 保留无效节点的对象，并继续检查它是否有效。必须显式删除 Node 对象以停止此过程。

当前，有 3 个组件同 Kubernetes 节点接口交互：节点控制器、kubelet 和 kubectl。

节点控制器

节点控制器是一个 Kubernetes master 组件，管理节点的方方面面。

节点控制器在节点的生命周期中扮演了多个角色。第一个是当节点注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。

第二个是使用云服务商提供了可用节点列表保持节点控制器内部的节点列表更新。如果在云环境下运行，任何时候当一个节点不健康时节点控制器将询问云服务节点的虚拟机是否可用。如果不可用，节点控制器会将这个节点从它的节点列表删除。

第三个是监控节点的健康情况。节点控制器负责在节点不能访问时（也即是节点控制器因为某些原因没有收到心跳，例如节点宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果节点持续不可访问，节点控制器将删除节点上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）节点控制器每隔 --node-monitor-period 秒检查每个节点的状态。

在 1.13 之前的 Kubernetes 版本中，NodeStatus 是来自节点的心跳信号。从 1.14 开始，默认情况下已启用节点租赁功能作为 beta 功能(功能特性开关 NodeLease、KEP-0009)。

启用节点租赁功能后，每个节点在 kube-node-lease 命名空间中都有一个关联的 Lease 租赁对象，该对象由节点定期更新，并且 NodeStatus 和节点租赁都被视为来自节点的心跳信号。仅当发生某些更改或经过了足够的时间（默认值为 1 分钟，比无法访问的节点的默认超时 40 秒）时，才会频繁更新节点租约，同时将 NodeStatus 从节点报告给主节点。由于节点租赁比 NodeStatus 轻得多，因此从可伸缩性和性能的角度来看，此功能使节点心跳明显便利。

在 Kubernetes 1.4 中我们更新了节点控制器逻辑以更好地处理大批量节点访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，节点控制器在决定删除 pod 之前会检查集群中所有节点的状态。

大部分情况下，节点控制器把驱逐频率限制在每秒 --node-eviction-rate 个（默认为 0.1）。这表示它每 10 秒钟内之多从一个节点驱逐 Pods。

当一个可用区域中的节点变为不健康时，它的驱逐行为将发生改变。节点控制器会同时检查可用区域中不健康（NodeReady 状态为 ConditionUnknown 或 ConditionFalse）的节点的百分比。如果不健康节点的部分超过 --unhealthy-zone-threshold （默认为 0.55），驱逐速率将会减小：如果集群较小（意即小于等于 --large-cluster-size-threshold 个 节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒 --secondary-node-eviction-rate 个（默认为 0.01）。在单个可用区域实施这些策略的原因是当一个可用区域可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个可用区域，那就只有一个可用区域整个集群）。

在多个可用区域分布你的节点的一个关键原因是当整个可用区域故障时，工作负载可以转移到健康的可用区域。因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率 --node-eviction-rate 进行驱逐操作。在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，节点控制器将假设 master 的连接出了某些问题，它将停止所有驱逐动作直到一些连接恢复。

从 Kubernetes 1.6 开始，NodeController 还负责驱逐运行在拥有 NoExecute 污点的节点上的 pods，如果这些 pods 没有容忍这些污点。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据节点故障（例如节点不可访问或没有 ready）添加污点。请查看这个文档了解关于 NoExecute 污点和这个 alpha 特性。

从版本 1.8 开始，可以使节点控制器负责创建代表节点条件的污点。这是版本 1.8 的 Alpha 功能。

节点自注册

当 kubelet 标志 --register-node 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。

对于自注册模式，kubelet 使用下列参数启动：

• --kubeconfig - 用于向 apiserver 验证自己的凭据路径。
• --cloud-provider - 如何从云服务商读取关于自己的元数据。
• --register-node - 自动向 API 服务注册。
• --register-with-taints - 使用 taints 列表（逗号分隔的 <key>=<value>:<effect>）注册节点。当 register-node 为 false 时无效。
• --node-ip - 节点 IP 地址。
• --node-labels - 在集群中注册节点时要添加的标签（请参阅 NodeRestriction 准入插件 在 1.13+ 中实施的标签限制）。
• --node-status-update-frequency - 指定 kubelet 向 master 发送状态的频率。

启用节点授权模式 和 NodeRestriction 准入插件时，仅授权小组件创建或修改其自己的节点资源。

手动节点管理

集群管理员可以创建及修改节点对象。

如果管理员希望手动创建节点对象，请设置 kubelet 标记 --register-node=false。

管理员可以修改节点资源（忽略 --register-node 设置）。修改包括在节点上设置 labels 及标记它为不可调度。

节点上的 labels 可以和 pods 的节点 selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的节点子集上运行。

标记一个节点为不可调度的将防止新建 pods 调度到那个节点之上，但不会影响任何已经在它之上的 pods。这是重启节点等操作之前的一个有用的准备步骤。例如，标记一个节点为不可调度的，执行以下命令：

kubectl cordon $NODENAME

注意：

请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照节点上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。

节点容量

节点的容量（cpu 数量和内存容量）是节点对象的一部分。通常情况下，在创建节点对象时，它们会注册自己并报告自己的容量。如果你正在执行手动节点管理，那么你需要在添加节点时手动设置节点容量。

Kubernetes 调度器保证一个节点上有足够的资源供其上的所有 pods 使用。它会检查节点上所有容器要求的总和不会超过节点的容量。这包括由 kubelet 启动的所有容器，但不包括由 container runtime 直接启动的容器，也不包括在容器外部运行的任何进程。

如果要为非 Pod 进程显式保留资源。请按照本教程为系统守护程序保留资源。

节点拓扑

如果启用了 TopologyManager 功能开关，则 kubelet 可以在做出资源分配决策时使用拓扑提示。

API 对象

节点是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到：节点 API 对象。

接下来

• 了解有关节点组件的信息。
• 阅读有关节点级拓扑的信息：控制节点上的拓扑管理策略。

反馈

此页是否对您有帮助？

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.