kubernates的node是一个工作的机器。他可以是虚拟机或者物理机，取决于集群。每个node包含运行pod所需的服务，并由master组件管理。node上的这些服务包括容器运行时，kubelet和kube-proxy。
节点状态包含以下信息。
hostname：hostname由node的内核报道出。可以通过使用kubelet --hostname-override参数来重写。
externalIp：外部可路由的节点的IP地址（可以从集群外部获得）
InternalIP：节点的IP地址只能在集群内路由。
condition字段描述了所有运行时的node的状态
outofdisk: true表示node上的可用空间不足以添加新的额pods，反之为false
ready：true表示节点是健康的并且准备好接收新的pods，false表示节点不健康，不能接收新的pod，unknown表示node controller在最后的时间里没有监听到node（默认是40秒）
memoryPressure：node上的内存是否存在压力。
pidpressure：进程是否有压力，即node上是否有太多的进程
diskpressure：磁盘是否有压力
networkunavailable：网络配置是否正确
node condition用一个json对象表示
如果ready的状态长期保持unknown或者false，时间超过了pod-eviction-timeout，那么就会有一个参数传递给kube-controller-manager然后node中的所有的pods将会被node-controller删除。默认的逐出超时时间是五分钟。在某些情况下，node无法被访问，apiserver不能与node上的kubelet进行通信。在与apiserver重新建立通信之前，不能将删除pod的命令传递给kubelet。同时，计划删除的pod还是可以继续在node上运行的
capacity：描述了node上可用的资源,cpu,内存以及node上可以调度的最大pod数。
info：有关节点的一般信息，例如内核版本，kubernates版本（包括kubelet和kube-proxy的版本），docker版本，操作系统名称。这些信息是由kubelet从node上收集下来的。
不像pods和services，kubernates本身不创建node，它是由外部的云提供商来创建的，或者存在你的物理机或者虚拟机的pool中。所以，当kubernates创建一个node的时候，它只是创建一个表示该节点的对象。创建完后（node对象），kubernates会检查节点是否有效。
kubernates在内部创建完node对象的时候，通过基于metadata.name变量的健康检查来验证node是不是可用的。如果节点有效，即所有必要的服务都在运行，那么它资格来运行pod。否则任何的集群后动都会忽略掉它，直到他变为有效。
注意：kubernates会保留无效节点的对象，并不断地检查它是否有效。必须显示的删除node对象才能停止此活动。
目前有三个组件与kubernates的node接口交互：node controller ，kubelet，kubectl
node controller：
它是kubernates master的组件，来管理node的多个方面。
它在node的生命周期中具有多个角色。
第一、它在node注册的时候为其分配CIDR模块（如果打开了CIDR分配）
第二、保持node controller内部的一系列node与云提供商的可用的计算机保持同步。当运行在云环境里，无论何时，只要是node不健康，那么node controller就会询问云提供商这个node的云提供商是否还可用。如果不可用了，那么node controller就会从他的node列表中将这个node删除了。
第三、监控node的健康状况。当node变得无法访问的时候，会将nodestatus的nodeready状态更新为conditionunknown，然后从node中逐出所有的pod。
node的自我注册：
当kubelet的标志 --register-node为true的时候，kubelet将尝试向apiserver注册自己。在自行注册的时候，可以使用一下选项来启动kubelet：
kubeconfig：用来使apiserver来验证自己的凭证路径
cloud-provider：怎样去告诉云提供商来读取自身的元数据
registe-node：自动注册api server
register-with-taints：使用给定的tains列表进行注册
node-ip：node的ip地址
node-labels：在集群中注册节点时要添加的标签
当Node authorization mode and NodeRestriction admission plugin 启用的时候，kubelet仅仅被授权来创建修改自己的node资源
手动管理节点：
集群管理员可以创建和修改节点对象
如果管理员想要手动创建节点对象，那么要设置kubelet标志 --register-node=false.
管理员可以修改节点资源（无论怎么设置 --register-node）修改包括 在节点上设置标签和将其标记为不可调度
node上的标签可以和pod上的节点选择器结合使用来控制调度。例如可以限制pod只能有资格在nodes的子集上运行。
将node设置为不可调度可以防止新的pod调度到该node，但不会影响node上现有的pod。这在节点准备重启之前是一个很有用的步骤。要将node设置为不可调度,使用命令:
kubectl cordon $NODENAME注意：由deamonset controller创建的pod会绕过kubernates的调度程序，不会遵守node上不可调度的属性。这是假设守护的进程属于机器，即使他准备重启那么它也会被应用程序占用着。（要是node要重启就不能被占用着，被调度着）
node的容量：
node的容量（CPU的数量和内存的占用量）也是节点对象的一部分。通常，当node 对象被创建的时候会node会注册自己并且会报告他们的容量。如果你正在手动进行节点管理，那么你需要在添加节点的时候设置节点容量。
kubernates调度程序确保node上所有的pod都有足够的资源。它会检查node上容器需求的总和不能大于node的容量。包括所有由kubelet启动的所有容器，但是不包括容器在运行的时候启动的容器和容器外部运行 的进程。
如果你要保留非pod的进程，那么你可以创建一个placeholder pod，使用上图的模板。
设置你要保留的cpu和内存资源。将文件放在清单目录（就是--config=DIR ，kubelet的标志）里。在要保留资源的每个kubelet上执行此操作