持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第 16 天，点击查看活动详情 \
只使用Pod, 将会面临如下需求:
- 业务应用启动多个副本
- Pod重建后IP会变化，外部如何访问Pod服务
- 运行业务Pod的某个节点挂了，可以自动帮我把Pod转移到集群中的可用节点启动起来
- 我的业务应用功能是收集节点监控数据,需要把Pod运行在k8集群的各个节点上
Workload (工作负载)
控制器又称工作负载是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。
Pod驱逐策略
K8S 有个特色功能叫 pod eviction，它在某些场景下如节点 NotReady，或者资源不足时，把 pod 驱逐至其它节点，这也是出于业务保护的角度去考虑的。
- Kube-controller-manager: 周期性检查所有节点状态，当节点处于 NotReady 状态超过一段时间后，驱逐该节点上所有 pod。停掉kubelet
pod-eviction-timeout：NotReady 状态节点超过该时间后，执行驱逐，默认 5 min
- Kubelet: 周期性检查本节点资源，当资源不足时，按照优先级驱逐部分 pod
memory.available：节点可用内存nodefs.available：节点根盘可用存储空间nodefs.inodesFree：节点inodes可用数量imagefs.available：镜像存储盘的可用空间imagefs.inodesFree：镜像存储盘的inodes可用数量
策略控制：
- maxSurge：最大激增数, 指更新过程中, 最多可以比replicas预先设定值多出的pod数量, 可以为固定值或百分比,默认为desired Pods数的25%。计算时向上取整(比如3.4，取4)，更新过程中最多会有replicas + maxSurge个pod
- maxUnavailable： 指更新过程中, 最多有几个pod处于无法服务状态 , 可以为固定值或百分比，默认为desired Pods数的25%。计算时向下取整(比如3.6，取3)
在Deployment rollout时，需要保证Available(Ready) Pods数不低于 desired pods number-maxUnavailable; 保证所有的非异常状态Pods数不多于 desired pods number + maxSurge。
为何要控制Pod应该如何调度
- 集群中有些机器的配置高（SSD，更好的内存等），我们希望核心的服务（比如说数据库）运行在上面
- 某两个服务的网络传输很频繁，我们希望它们最好在同一台机器上
- ......
NodeSelector
label是kubernetes中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，POD 的调度可以根据节点的 label 进行特定的部署。
