每个资源对象都有3大类属性：元数据metadata、规范spec和状态status。
元数据metadata是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；
规范spec是根据资源对象不同，有着各自的结构；
状态status作为资源状态，有别于资源规范的一点，就是状态往往是通过组件去维护的，比如deployment 是通过kube-controller-manager 去维护状态，node 是通过kubelet 去维护。
node
node 作为pod 运行的 主机， 可以是物理机，也可以是虚拟机，但为了管理pod，在node上必须运行 container runtime （docker 或 rkt），以及kubelet 与 kube-proxy。
node，不同于其他资源注册方式，是通过kubelet 主动触发，发送请求给kube-apiserver去创建出来，之后kubelet通过定时心跳去维护node的状态。
每一个node都会包含一下的状态信息，都是通过kubelet 收集：
- address： 包括节点的hostname，内网ip，外网ip
- condition： 包括OutOfDisk、Ready、MemoryPressure 和 DiskPressure
- capacity: Node 上的可用资源，包括 CPU、内存和 Pod 总数
- nodeInfo: 包括内核版本、容器引擎版本、OS 类型等
【拓展】node状态维护
kubelet 根据 --node-status-update-frequency （default 10s）配置，定时维护node的状态（会更新node.status.condition中，保留着最近一次心跳时间）；
在kubelet 出现异常状态，导致无法发送心跳给kube-apiserver的时候， kube-controller-manager的node controller 会根据 --node-monitor-grace-period duration（default 40s）配置，若最后一次心跳时间，超过这个配置， node controller会去将node的状态变为not ready ，并将 node上的pod 状态变为not ready， endpoint controller 就会在endpoint内移除相关not ready pod 的ip；
当kubelet 的一直没有恢复心跳， kube-controller-manager的node controller 会根据--pod-eviction-timeout（default 5m0s）配置，若最后一次心跳时间，超过这个配置， node controller 会去移除掉该node上所有pod。
注意： 大规模节点not ready 现象，超过一定比例，则不会进行移除node 上的pod操作 ，但在大集群的场景下，往往大规模node not ready ，并不会超过比例，这个时候就会出现雪崩式的pod 移除现象，从而pod调度到其他正常节点，就可能会影响正常节点，故在部署应用的时候引入租户概念以及nodeselect，affinity等调度策略是有非常必要性的。
【拓展】节点调度
kubernetes 上的应用创建出来，是处于未调度状态，kube-scheduler 组件这时候就会捕获到这些应用，根据调度策略来为这些应用分配节点（更新 Pod 的 NodeName 字段）
kube-scheduler 调度分为两个阶段，predicate 和 priority
- predicate：过滤不符合条件的节点
- priority：优先级排序，选择优先级最高的节点
kubernetes 调度策略
predicates 策略
- PodFitsPorts：同 PodFitsHostPorts
- PodFitsHostPorts：检查是否有 Host Ports 冲突
- PodFitsResources：检查 Node 的资源是否充足，包括允许的 Pod 数量、CPU、内存、GPU 个数以及其他的 OpaqueIntResources
- HostName：检查 pod.Spec.NodeName 是否与候选节点一致
- MatchNodeSelector：检查候选节点的 pod.Spec.NodeSelector 是否匹配
- NoVolumeZoneConflict：检查 volume zone 是否冲突
- MaxEBSVolumeCount：检查 AWS EBS Volume 数量是否过多（默认不超过 39）
- MaxGCEPDVolumeCount：检查 GCE PD Volume 数量是否过多（默认不超过 16）
- MaxAzureDiskVolumeCount：检查 Azure Disk Volume 数量是否过多（默认不超过 16）
- MatchInterPodAffinity：检查是否匹配 Pod 的亲和性要求
- NoDiskConflict：检查是否存在 Volume 冲突，仅限于 GCE PD、AWS EBS、Ceph RBD 以及 ISCSI
- GeneralPredicates：分为 noncriticalPredicates 和 EssentialPredicates。noncriticalPredicates 中包含 PodFitsResources，EssentialPredicates 中包含 PodFitsHost，PodFitsHostPorts 和 PodSelectorMatches。
- PodToleratesNodeTaints：检查 Pod 是否容忍 Node Taints
- CheckNodeMemoryPressure：检查 Pod 是否可以调度到 MemoryPressure 的节点上
- CheckNodeDiskPressure：检查 Pod 是否可以调度到 DiskPressure 的节点上
- NoVolumeNodeConflict：检查节点是否满足 Pod 所引用的 Volume 的条件
priorities 策略：每条策略有着权重比，节点打分 = sum（每条策略分数*权重）
- SelectorSpreadPriority：优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
- InterPodAffinityPriority：优先将 Pod 调度到相同的拓扑上（如同一个节点、Rack、Zone 等）
- LeastRequestedPriority：优先调度到请求资源少的节点上
- BalancedResourceAllocation：优先平衡各节点的资源使用
- NodePreferAvoidPodsPriority：alpha.kubernetes.io/preferAvoidPods 字段判断, 权重为 10000，避免其他优先级策略的影响
- NodeAffinityPriority：优先调度到匹配 NodeAffinity 的节点上
- TaintTolerationPriority：优先调度到匹配 TaintToleration 的节点上
- ServiceSpreadingPriority：尽量将同一个 service 的 Pod 分布到不同节点上，已经被 SelectorSpreadPriority 替代 [默认未使用]
- EqualPriority：将所有节点的优先级设置为 1[默认未使用]
- ImageLocalityPriority：尽量将使用大镜像的容器调度到已经下拉了该镜像的节点上 [默认未使用]
- MostRequestedPriority：尽量调度到已经使用过的 Node 上，特别适用于 cluster-autoscaler[默认未使用]
kube-scheduler原理
1. 获取还未调度的pods列表，获取当前所有nodes列表
2. 根据predicates 策略，过滤出符合条件的节点
3. 根据priorities 策略，对符合条件的节点进行打分
4. 选取分数最高的节点，更新pod，将pod.spec.nodeName配置成该节点
【拓展】 不可调度node
在node上出现异常的时候，可以设置不可调度，避免其他pod调度到该节点，可以使用命令： kubectl crodon $NODENAME 来使node进入不可调度状态，其本质上是修改node.spec.unschedulable 为 true
