/concepts/architecture/nodes/

Nodes

node是kubernetes中的工作机，以前称为“minion”`. 可以是虚拟机或物理机，具体取决于集群。每个节点包含运行pods 所需的服务，并由master管理。

node上的服务包括容器环境-符合CRI标准-container runtime,kubelet和kube-proxy。请参阅架构设计文档中的The Kubernetes Node 一节以了解更多详细信息。

• Node Status
• Management
• Node topology
• API Object
• What's next

Node Status

节点的状态包含以下信息：

• Addresses
• Conditions
• Capacity and Allocatable
• Info

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

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

下面将详细介绍每个部分。

Addresses

这些字段的使用取决于云提供商或裸机配置.

• HostName: 需要自定义主机名. 在 kubelet 启动前--hostname-override参数指定主机名覆盖系统默认主机名.
• ExternalIP: Typically the IP address of the node that is externally routable (available from outside the cluster).外网也可以访问的ip
• InternalIP: 通常是只能在集群内路由的节点的IP地址.

Conditions

Conditions 字段描述节点 Running 状态. 有以下几种状态:

nodeconditions表示为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"
  }
]

如果就绪条件的状态保持Unknown或False的时间超过pod-eviction-timeoutpod逐出超时时间, 参数被传递给kube controller manager ，节点上的所有pod都被节点控制器计划删除。默认逐出超时持续时间为5分钟。在某些情况下，当无法访问节点时，APIServer无法与node上的kubelet通信。在与APIServer重新建立通信之前，无法将删除pod的决定传达给Kubelet。同时，计划删除的pod可以继续在分区节点上运行。

(node失联(异常关机,或者kubelet进程异常退出, 运行于此node上的pods并不会被驱逐到新的node上, 且不会更新pods状态一直认为其是正常运行))

In versions of Kubernetes prior to 1.5, the node controller would force delete these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in the Terminating or Unknown state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.在1.5之前的kubernetes版本中，节点控制器将强制从apiserver中删除这些无法访问的pod。但是，在1.5和更高版本中，节点控制器不会强制删除pod，直到确认它们已停止在集群中运行。您可以看到可能正在无法访问的节点上运行的pod处于终止或未知状态。在kubernetes无法从底层基础设施推断节点是否永久离开集群的情况下，集群管理员可能需要手动删除节点对象。从kubernetes中删除node对象会导致从apiserver中删除节点上运行的所有pod对象，并释放它们的名称。

In version 1.12, TaintNodesByCondition feature is promoted to beta, so node lifecycle controller automatically creates taints that represent conditions. Similarly the scheduler ignores conditions when considering a Node; instead it looks at the Node’s taints and a Pod’s tolerations.在版本1.12中，TaintNodesByCondition特性被提升为beta版，因此节点生命周期控制器会自动创建表示条件的taints。类似地，调度器在考虑一个节点时会忽略条件；相反，它会查看节点的污点和pod的容忍度。

Now users can choose between the old scheduling model and a new, more flexible scheduling model. A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that tolerates the taints of a particular Node can be scheduled on that Node.现在用户可以在旧的调度模型和新的、更灵活的调度模型之间进行选择。一个没有任何耐受性的pod将根据旧模型进行调度。但是一个能够容忍特定节点污染的pod可以在该节点上调度。

Caution: Enabling this feature creates a small delay between the time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.启用此功能将在观察到条件和创建污点之间创建一个小延迟。这种延迟通常小于1秒，但它可以增加成功调度但被kubelet拒绝的吊舱数量。

Capacity and Allocatable容量和可分配

Capacity:
 cpu:                2
 ephemeral-storage:  51175Mi
 hugepages-2Mi:      0
 memory:             4045652Ki
 pods:               110
Allocatable:
 cpu:                2
 ephemeral-storage:  48294789041
 hugepages-2Mi:      0
 memory:             3943252Ki
 pods:               110

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

Capacity字段描述当前节点的资源总量, Allocatable字段表示最多可分配的资源总量

在学习如何在节点上 资源保留reserve compute resources 您可以阅读更多有关容量和可分配资源的信息。

Info

System Info:
 Machine ID:                 7138b458771f48e99760b4a14e10e7ad
 System UUID:                423677FD-9A2E-A62D-7F4A-0A8390F257E7
 Boot ID:                    835eec1e-cd1c-4830-b0e9-015569f5f09d
 Kernel Version:             3.10.0-957.21.3.el7.x86_64
 OS Image:                   CentOS Linux 7 (Core)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://19.3.1
 Kubelet Version:            v1.15.4
 Kube-Proxy Version:         v1.15.4

Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name. This information is gathered by Kubelet from the node. 描述有关节点的一般信息，例如内核版本、kubernetes版本)kubelet和kube代理版本)、docker版本)如果使用)和os名称。此信息由kubelet从节点收集。

Management

与pods 和services不同, 节点不是由k8s集群创建的, : 而是由云服务商例如Google Compute Engine, 在外部创建的，或者它存在于物理或虚拟机池中kubelet, kube-proxy, docker是用户自行安装.因此，当kubernetes创建一个节点时，它会创建一个表示该节点的对象。创建后，kubernetes检查节点是否有效。例如，如果尝试从以下内容创建节点：

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

kubernetes在内部创建一个节点对象)表示)，并基于metadata.name字段通过运行状况检查来验证节点。如果节点有效)也就是说，如果所有必要的服务都在运行)，那么它就有资格运行pod。否则，任何群集活动都将忽略它，直到它变为有效。

Note: kubernetes保留无效节点的对象，并不断检查它是否有效。必须显式删除节点对象才能停止此进程。

Currently, there are three components that interact with the Kubernetes node interface: node controller, kubelet, and kubectl.目前，有三个组件与kubernetes节点接口交互：node controller、kubelet和kubectl。

Node Controller

节点控制器(node controller)是一个kubernetes Master组件，它管理nodes的各个方面。

节点控制器在节点的生命周期中有多个角色。

第一种是在注册节点时将cidr块分配给该节点)如果启用了cidr分配)分配网段

第二是让节点控制器的内部节点列表与云提供商的可用计算机列表保持最新。在云环境中运行时，每当节点不正常时，节点控制器会询问云提供商该节点的虚拟机是否仍然可用。否则，节点控制器将从其节点列表中删除该节点。节点存活探测

第三是监测节点的健康状况。节点控制器负责在节点变得不可访问时将NodeStatus的NodeReady条件更新为ConditionUnknown)即节点控制器由于某些原因停止接收心跳信号，例如由于节点关闭)，然后从节点中逐出所有pod)使用正常终止)如果节点仍然无法访问。)默认超时为40秒以开始报告未知条件，5秒后开始逐出pod。)节点控制器通过此设置--node-monitor-period可以修改检查周期秒为单位

在1.13之前的kubernetes版本中，nodestatus是来自节点的心跳。从kubernetes 1.13开始，node lease特性作为alpha特性引入(feature gate NodeLease, KEP-0009).启用节点租用功能后，每个节点在kube-node-lease命名空间中都有一个关联的租用对象(Lease)，该对象由节点定期更新，NodeStatus和node lease都被视为来自节点的心跳。当nodestatus从一个节点报告到主节点时，只有在发生了一些更改或经过了足够的时间)默认值为1分钟，比无法访问的节点的默认超时40秒长)，节点租约才会频繁地更新。由于node lease比nodestatus轻量级得多，因此从可伸缩性和性能角度来看，此功能使node heartbeat显著降低。简而言之由节点上报信息自动更新节点状态信息而不是心跳检查, 如果超出租约时间不续租会触发一个事件,k8smaster会做出相对应的操作

在kubernetes 1.4中，我们更新了节点控制器的逻辑，以便更好地处理大量节点在到达主节点时出现问题)例如，因为主节点有网络问题)的情况。从1.4开始，节点控制器在决定pod退出时查看集群中所有节点的状态。

在大多数情况下，节点控制器将逐出速率限制为--node-eviction-rate)默认为0.1)每秒，这意味着它不会每10秒逐出超过1个节点的pod。

当给定可用性区域中的节点变得不正常时，节点逐出行为将更改。节点控制器同时检查区域中不正常节点的百分比)NodeReady条件为ConditionUnknown或ConditionFalse)。如果不正常节点的部分至少为不正常区域阈值--unhealthy-zone-threshold)默认值为0.55)，则逐出率会降低：如果群集较小)即小于或等于-大型群集大小阈值节点---large-cluster-size-threshold默认值为50)，则逐出将停止，否则逐出率将降低到--次节点逐出率--secondary-node-eviction-rate )默认为0.01)每秒。每个可用性区域实现这些策略的原因是，一个可用性区域可能从主区域分区，而其他可用性区域则保持连接。如果集群不跨越多个云提供商可用性区域，则只有一个可用性区域)整个集群)。

将节点分散到可用性区域的一个关键原因是，当一个完整的区域关闭时，工作负载可以转移到正常区域。因此，如果一个区域中的所有节点都不正常，则节点控制器将以正常速率“节点逐出速率--node-eviction-rate”逐出。最糟糕的情况是所有区域都完全不正常)即集群中没有正常的节点)。在这种情况下，节点控制器假设主连接有问题，并停止所有收回操作，直到恢复某些连接。(不要把鸡蛋放在一个篮子里)

从kubernetes 1.6开始，NodeController还负责清除在带有NoExecute 污染的节点上运行的pod，而这些pod不能容忍这些污染。此外，作为默认禁用的alpha特性，NodeController负责添加与节点问题)如节点不可访问或未就绪)对应的污点。请参阅本文档了解有关NoExecute 污染和alpha特性的详细信息。

从版本1.8开始，节点控制器可以负责创建表示节点条件的污点。这是1.8版的alpha特性。

Self-Registration of Nodes节点自注册

# 启动示例
/usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1

当kubelet启动添加参数 --register-node为true)默认值)时，kubelet将尝试向api服务器注册自己。这是大多数发行版使用的首选模式。

对于自注册，kubelet从以下选项开始：

• --kubeconfig - 用于向APIServer验证自身的凭据的路径。
• --cloud-provider - How to talk to a cloud provider to read metadata about itself.如何与云提供商交谈以读取有关其自身的元数据。
• --register-node - Automatically register with the API server.自动注册到API服务器。
• --register-with-taints - Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if register-node is false.使用给定的污点列表)逗号分隔的“=：`”)注册节点。如果“register node”为false，则不执行操作。
• --node-ip - IP address of the node.
• --node-labels - 在群集中注册节点时要添加的标签(请参阅1.13+中由[noderestriction admission plugin执行的标签限制](https://kubernetes.io/docs/reference/acces... authn authz/admission controllers/noderestriction))。
• --node-status-update-frequency - Specifies how often kubelet posts node status to master.指定kubelet向master发送节点状态的频率。

当启用节点授权模式(Node authorization mode)和noderestriction许可插件(NodeRestriction admission plugin )时，kubelets只被授权创建/修改自己的节点资源。

Manual Node Administration手动节点管理

群集管理器可以创建和修改节点对象。

如果管理员希望手动创建节点对象，请在kubelet启动前设置 --register-node=false.

管理员可以修改节点资源)不考虑--register-node的设置)。修改包括在节点上设置标签并将其标记为不可调度。

节点上的标签可以与pod上的节点选择器一起使用，以控制调度，例如，将pod限制为仅能在节点的子集上运行。

将节点标记为不可调度可防止将新的pod调度到该节点，但不会影响节点上的任何现有pod。这对于节点重新启动前的准备步骤非常有用。例如，要将节点标记为不可调度，请运行以下命令：

kubectl cordon $NODENAME

Note: Pods created by a DaemonSet controller bypass the Kubernetes scheduler and do not respect the unschedulable attribute on a node. This assumes that daemons belong on the machine even if it is being drained of applications while it prepares for a reboot.由于DaemonSet程序控制器创建的pod绕过kubernetes调度程序，忽略节点上的unschedulable属性。这假设守护进程属于计算机，即使它在准备重新启动时正在耗尽应用程序即使属于节点上关键进程,直至重启它都不会被驱逐。

Node capacity节点容量

节点的容量)CPU数量和内存量)是节点对象的一部分。通常，节点在创建节点对象时会注册自己并报告其容量。如果正在执行手动节点管理，则在添加节点时需要设置节点容量。

kubernetes调度程序确保节点上的所有pod都有足够的资源。它检查节点上容器的请求总数是否不大于节点容量。它包括由kubelet启动的所有容器，但不包括由[容器运行时](https://kubernetes.io/docs/concepts/overvi... components)直接启动的容器，也不包括在容器外部运行的任何进程。只关注kubelet启动的pod中包含的容器

如果要显式地为非pod进程保留资源，请按照本教程的说明[为系统守护进程保留资源](https://kubernetes.io/docs/tasks/administr... cluster/reserve compute resources/system reserved)。

Node topology节点拓扑

功能状态：kubernetes v1.16alpha
如果启用了“拓扑管理器”[功能门](https://kubernetes.io/docs/reference/comma... line tools reference/feature gates/)，那么kubelet可以在做出资源分配决策时使用拓扑提示。

API Object

node是Kubernetes REST API中的顶级资源。有关api对象的更多详细信息，请参见：Node API object.

What's next

• Read about node components

• 了解节点级拓扑：控制节点上的拓扑管理策略

本作品采用《CC 协议》，转载必须注明作者和本文链接