Kubernetes 架构：节点

名字可以标识一个节点。两个节点不可能在同一个时间内有相同的名字。Kubernetes 假定具有相同名称的资源是相同的对象。对于节点，他隐式的假定相同名称的实例 具有相同的状态（比如说：网络设置，根磁盘内容）。如果在不更改实例名称的情况下对其进行了修改，则可能导致不一致。如果需要大量更换或者更新的节点，现有的节点 对象首先从 APIServer 中删除，并在更新后重新添加。

如果 kubelet 的 --register-node 是 true（默认值），kubelet 会尝试注册自己到 API server。这是大多数发行版首选的模式。

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

• --kubeconfig - 向 API server 进行身份验证的证书路径；
• --cloud-provider - 如何与云提供商交互以获取自身的元数据；
• --register-node - 自动向 API server 注册；
• --register-with-taints - 使用给定的污点列表（逗号分隔的 <key>=<value>:<effect> ）注册节点。 如果 register-node 是 false 则什么都不操作；
• --node-ip - 节点的 IP 地址；
• --node-labels - 注册到集群之后添加的标签；
• --node-status-update-frequency - 指定 kubelet 多久同步一次节点状态到主节点；

当 节点认证模式 和 节点限制准入插件 是开启状态，kubelet 仅被授权创建/修改自己的节点资源。

你可以使用 kubectl 创建或者修改节点对象。

当需要手动创建节点对象时，给 kubelet 设置 --register-node=false 。

无论 --register-node 是什么样的，你都可以修改节点对象。比如，你可以在现有的节点上设置标签，或者将他标记为不可调度。

你可结合节点上的标签和 Pod 的节点选择器（node selector）来控制调度。比如，你可以约束 Pod 只有资格运行在一些可用节点的子集上。

标记节点不可调度会阻止新的 Pods 调度到该节点上，但是不会影响节点上现有的 Pods。这作为重启或者维护之前的准备步骤很有效。

标记一个节点不可调度，运行：

kubectl cordon $NODENAME

注意： 作为 DaemonSet 的一部分 Pods 是可以运行在不可调度节点上的。DaemonSet 通常会提供本地节点服务，即使正在耗尽工作负载的应用程序， 它也应该在节点上运行。

这些字段值的运用取决于你的云提供商或者裸机配置。

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

conditions 描述 Running 节点的状态。Conditions 的 Type 包括：

注意： 如果你使用 CLI 工具查看被 crodoned 的节点，Conditions 包括 SchedulingDisabled 。 SchedulingDisabled 不是 Kubernetes API 的 Condition；而是由节点标记为「不可调度」。

节点 condition 可以表示为一个 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 的参数）时间， 节点控制器上的 Pod 会被调度器从该节点上删除（迁移）。默认的驱逐超时时间为 5 分钟 。在某些情况下节点不可到达，API server 无法与节点上的 kubelet 通信。删除 Pod 的决定无法传递给 kubelet 直到 kubelet 与 API server 重新建立连接为止。 同时，计划删除的 Pod 可能会继续在分区节点上运行。

在确认节点已停止在集群中运行之前，节点控制器不会强制删除。你可以看到 Pod 可能在不可到达的节点处于 Terminating 或者 Unknown 状态。 如果 Kubernetes 无法从基础架构判断出某个节点永久离开集群的情况，集群管理员可能需要手动删除节点对象。从 Kubernetes 中删除该节点对象会导致 该节点上上运行的所有 Pod 对象从 API server 中删除，并释放其名称。

节点的生命周期控制器会自动创建代表 condition 的污点。在将 Pod 分配给节点时，调度程序会考虑节点的污点。Pods 也可以具有容忍度， 以使它们可以容忍节点的污点。

查看按条件污染节点获取更多的信息。

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

• Capacity 显示节点的资源总量
• Allocatable 显示可提供给 Pod 消耗的资源总量

节点的通用信息（System Info），包含：内核版本、系统、容器运行时以及 Kubernetes 版本信息等。

节点控制器是 Kubernetes 控制面板组件用来管理节点的各个方面。

节点控制器在节点的生命周期中扮演多个角色。第一个是注册时将 CIDR 分配给该节点（如果 CIDR 分配已打开）。

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

第三是监控节点的运行状况。当节点不可到达时，节点控制器负责将 NodeStatus 的 NodeReady 条件更新为 ConditionUnknown （即，由于某些原因（例如节点关闭）节点控制器停止接收心跳），然后如果该节点继续无法访问，则从该节点驱逐（优雅终结）所有的 Pods （默认超时为 40 秒，开始上报 ConditionUnknown，只有5分钟，开始驱逐 Pods）。节点控制器每隔 -node-monitor-period 秒检查一次节点的状态。

节点对象会跟踪节点资源的容量信息（比如：可用内存量和 CPU 数量）。自注册的节点在注册过程中报告其容量。如果你手动添加的节点，你需要在添加的时候设置节点的容量。

Kubernetes 调度程序确保所有的 Pod 都有足够的资源。调度器检查节点上的容器请求总和不大于节点的容量。请求总数包括了 kubelet 管理的所有容器，但是不包含 使用容器运行时直接启动的任何容器，也排除在 kubelet 组件之外的任何进程。

注意： 如果你要为非 Pod 进程显式的保留资源，查看为系统后台进程预留资源。