Node是Kubernetes中的工作节点，最开始被称为minion。一个Node可以是VM或物理机。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy。
节点的状态信息包含如下几个:
Addresses
这些字段的使用取决于云提供商或裸机配置。
Condition
描述所有Running节点的状态, 有以下几种值类型
Capacity: 描述节点上可用的资源：CPU、内存和可以调度到节点上的最大pod数。
Info: 关于节点的一些基础信息，如内核版本、Kubernetes版本（kubelet和kube-proxy版本）、Docker版本（如果有使用）、OS名称等。信息由Kubelet从节点收集。
节点的容量(cpu数量和内存数量)是节点对象的一部分。通常，节点在创建节点对象时注册并通知其容量。如果是手动管理节点，则需要在添加节点时设置节点容量。
Kubernetes调度程序可确保节点上的所有pod都有足够的资源。它会检查节点上容器的请求的总和不大于节点容量。
如果要明确保留非pod过程的资源，可以创建一个占位符pod。使用以下模板：
apiVersion: v1
kind: Pod
metadata:
name: resource-reserver
spec:
containers:
- name: sleep-forever
image: gcr.io/google_containers/pause:0.8.0
resources:
requests:
cpu: 100m
memory: 100Mi
将cpu和内存值设置为你想要保留的资源量，将文件放置在manifest目录中(--config=DIR flag of kubelet)。在要预留资源的每个kubelet上执行此操作。
如果Ready condition的Status是Unknown 或 False，比pod-eviction-timeout的时间长，则会传递给 kube-controller-manager，该节点上的所有Pod都将被节点控制器删除。默认的pod-eviction-timeout时间为5分钟。而在某些情况下，当节点无法访问时，apiserver将无法与kubelet通信，删除Pod的需求不会传递到kubelet，直到重新与apiserver建立通信，这种情况下，计划删除的Pod会继续在划分的节点上运行。
在Kubernetes 1.5之前的版本中，节点控制器将强制从apiserver中删除这些不可达（上述情况）的pod。但是，在1.5及更高版本中，节点控制器在确认它们已经停止在集群中运行之前，不会强制删除Pod。可以看到这些可能在不可达节点上运行的pod处于Terminating或 Unknown。如果节点永久退出集群，Kubernetes 是无法从底层基础架构辨别出来，则集群管理员需要手动删除节点对象，从Kubernetes删除节点对象会导致运行在上面的所有Pod对象从apiserver中删除，最终将会释放names。