K8S(十三) | Kubernetes Node

K8S(十三) | Kubernetes Node

节点是Kubernetes中的工作机器，以前称为a minion。节点可以是VM或物理机，具体取决于集群。每个节点都包含运行pod所需的服务，并由主组件管理。节点上的服务包括容器运行时，kubelet和kube-proxy。有关更多详细信息，请参阅 体系结构设计文档中的Kubernetes节点部分。

节点状态

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

地址条件容量信息

下面详细描述每个部分。

地址

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

HostName：节点内核报告的主机名。可以通过kubelet --hostname-override参数覆盖。ExternalIP：通常是可从外部路由的节点的IP地址（可从群集外部获得）。InternalIP：通常仅在群集内可路由的节点的IP地址。

条件

该conditions字段描述了所有Running节点的状态。

节点条件表示为JSON对象。例如，以下响应描述了健康节点。

"conditions": [ { "type": "Ready", "status": "True" }]

如果就绪状态的状态保持Unknown或False长于，则将pod-eviction-timeout参数传递给kube-controller-manager，并且节点控制器将调度节点上的所有Pod以进行删除。默认逐出超时持续时间为五分钟。在某些情况下，当节点无法访问时，apiserver无法与节点上的kubelet通信。在重新建立与apiserver的通信之前，不能将删除pod的决定传送到kubelet。同时，计划删除的pod可以继续在分区节点上运行。

在1.5之前的Kubernetes版本中，节点控制器会强制 从apiserver中删除这些无法访问的pod。但是，在1.5及更高版本中，节点控制器不会强制删除容器，直到确认它们已停止在群集中运行。您可以看到可能在无法访问的节点上运行的pod处于Terminating或Unknown处于状态。如果节点永久离开群集，如果Kubernetes无法从底层基础架构推断出，则群集管理员可能需要手动删除节点对象。从Kubernetes中删除节点对象会导致节点上运行的所有Pod对象从apiserver中删除，并释放它们的名称。

在版本1.12中，TaintNodesByCondition功能被提升为beta，因此节点生命周期控制器会自动创建 表示条件的污点。类似地，调度程序在考虑节点时忽略条件; 相反，它会查看Node的污点和Pod的容忍度。

现在，用户可以在旧的调度模型和更灵活的新调度模型之间进行选择。根据旧型号，可以安排没有任何容忍度的Pod。但是可以在该节点上安排容忍特定节点的污点的Pod。

警告：启用此功能会在观察到条件和创建污点之间产生一个小延迟。此延迟通常小于一秒，但它可以增加成功安排但被kubelet拒绝的Pod的数量。

容量

描述节点上可用的资源：CPU，内存以及可以在节点上调度的最大pod数。

信息

有关节点的一般信息，例如内核版本，Kubernetes版本（kubelet和kube-proxy版本），Docker版本（如果使用），操作系统名称。信息由Kubelet从节点收集。

管理

与pod和服务不同，Kubernetes本身并不创建节点：它由Google Compute Engine等云提供商在外部创建，或者存在于物理或虚拟机池中。因此，当Kubernetes创建节点时，它会创建一个表示节点的对象。创建后，Kubernetes会检查节点是否有效。例如，如果您尝试从以下内容创建节点：

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

Kubernetes在内部创建节点对象（表示），并通过基于metadata.name字段的运行状况检查来验证节点。如果节点有效 - 即，如果所有必需的服务都在运行 - 它有资格运行pod。否则，对于任何群集活动，它将被忽略，直到它变为有效。

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

目前，有三个组件与Kubernetes节点接口交互：节点控制器，kubelet和kubectl。

节点控制器

节点控制器是Kubernetes主组件，它管理节点的各个方面。

节点控制器在节点的生命周期中具有多个角色。第一种是在注册时为节点分配CIDR块（如果打开了CIDR分配）。

第二个是使节点控制器的内部节点列表与云提供商的可用计算机列表保持同步。在云环境中运行时，只要节点不健康，节点控制器就会询问云提供商该节点的VM是否仍然可用。如果不是，则节点控制器从其节点列表中删除该节点。

第三是监测节点的健康状况。节点控制器负责在节点变得无法访问时将NodeStatus的NodeReady条件更新为ConditionUnknown（即节点控制器由于某种原因停止接收心跳，例如由于节点关闭），然后从节点中驱逐所有pod （如果节点仍然无法访问，则使用正常终止）。（默认超时为40 --node-monitor-period秒，开始报告ConditionUnknown，之后5米开始驱逐pod。）节点控制器每秒检查每个节点的状态。

在1.13之前的Kubernetes版本中，NodeStatus是节点的心跳。从Kubernetes 1.13开始，节点租用功能作为alpha功能引入（功能门NodeLease， KEP-0009）。启用节点租用功能时，每个节点都有一个关联的Lease对象 kube-node-lease由节点定期更新的命名空间，NodeStatus和节点租约都被视为来自节点的心跳。节点租约经常更新，而NodeStatus仅在有一些更改或经过足够时间时从节点报告为主节点（默认值为1分钟，这比不可达节点的默认超时40秒）。由于节点租约比NodeStatus轻得多，因此从可伸缩性和性能角度来看，此功能使节点心跳显着降低。

在Kubernetes 1.4中，我们更新了节点控制器的逻辑，以便在大量节点到达主站时遇到问题时更好地处理案例（例如，因为主站有网络问题）。从1.4开始，节点控制器在决定pod驱逐时查看集群中所有节点的状态。

在大多数情况下，节点控制器将驱逐率限制为每秒 --node-eviction-rate（默认值0.1），这意味着它不会每10秒从多个节点驱逐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不能容忍taints时。此外，作为默认禁用的alpha功能，NodeController负责添加与节点无法访问或未就绪等节点问题相对应的污点。 有关污点和alpha功能的详细信息，请参阅此文档NoExecute。

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

节点自注册

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

对于自行注册，可以使用以下选项启动kubelet：

--kubeconfig - 凭证路径，以向apiserver验证自身。--cloud-provider - 如何与云提供商交谈以阅读有关自身的元数据。--register-node - 自动注册API服务器。--register-with-taints- 使用给定的taints列表注册节点（以逗号分隔=:）。No-op如果register-node是假的。--node-ip - 节点的IP地址。--node-labels- 在群集中注册节点时添加的标签（请参阅1.13+中NodeRestriction准入插件强制执行的标签限制）。--node-status-update-frequency - 指定kubelet将节点状态发布到master的频率。

当节点授权模式和 NodeRestriction录取插件的启用，kubelets仅被授权创建/修改自己的节点资源。

手动节点管理

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

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

管理员可以修改节点资源（无论设置如何--register-node）。修改包括在节点上设置标签并将其标记为不可调度。

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

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

kubectl cordon $NODENAME

注意：由DaemonSet控制器创建的Pod绕过Kubernetes调度程序，不遵守节点上的不可调度属性。这假设守护进程属于机器，即使它在准备重新启动时正在耗尽应用程序。

节点容量

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

Kubernetes调度程序确保节点上的所有pod都有足够的资源。它检查节点上容器请求的总和不大于节点容量。它包括由kubelet启动的所有容器，但不包括由容器运行时直接启动的容器，也不包括在容器外部运行的任何进程。

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

API对象

Node是Kubernetes REST API中的顶级资源。

关注我，每天学习Kubernetes