Pod驱逐策略
节点压力驱逐是由各kubelet进程主动终止pod，以回收节点上的内存、磁盘空间等资源的过程，kubelet监控当前node节点的CPU、内存、磁盘空间和文件系统的inde等资源，当这些资源中的一个或者多个达到特定的消耗水平，kubelet就会主动地将节点上一个或者多个pod强制驱逐，以防止当前node节点资源无法正常分配而引发的OOM(OutOfMermory)
官网：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/
1、Kube-controller-manager: 周期性检查所有节点状态，当节点处于 NotReady 状态超过一段时间后，驱逐该节点上所有 pod。停掉kubelet
-
pod-eviction-timeout：NotReady 状态节点超过该时间后，执行驱逐，默认 5 min
2、Kubelet: 周期性检查本节点资源，当资源不足时，按照优先级驱逐部分 pod
vim /var/lib/kubelet/config.yaml
evictionHard:
imagefs.available: 15% 镜像存储盘的可用空间
memory.available: 300Mi 节点可用内存
nodefs.available: 10% 节点根盘可用存储空间
nodefs.inodesFree: 5% 节点inodes可用数量
kubelet 驱逐时 Pod 的选择
如果 kubelet 回收节点级资源的尝试没有使驱逐信号低于条件， 则 kubelet 开始驱逐最终用户 Pod。
kubelet 使用以下参数来确定 Pod 驱逐顺序：
- Pod 的资源使用是否超过其请求
- Pod 优先级
- Pod 相对于请求的资源使用情况
因此，kubelet 按以下顺序排列和驱逐 Pod：
- 首先考虑资源使用量超过其请求的
BestEffort 或 Burstable Pod。 这些 Pod 会根据它们的优先级以及它们的资源使用级别超过其请求的程度被逐出。 - 资源使用量少于请求量的
Guaranteed Pod 和 Burstable Pod 根据其优先级被最后驱逐。
Kubernetes基于是QoS(服务质量等级)驱逐Pod , Qos等级包括目前包括以下三个:
Guaranteed、Burstable、BestEffort
Guaranteed: #limits和request的值相等，等级最高、最后被驱逐
resources:
limits:
cpu: 500m
memory: 256Mi
requests:
cpu: 500m
memory: 256Mi
Burstable: #limit和request不相等，等级折中、中间被驱逐
resources:
limits:
cpu: 500m
memory: 256Mi
requests:
cpu: 256m
memory: 128Mi
BestEffort: #没有限制，即resources为空，等级最低、最先被驱逐
POD更新策略
...
spec:
replicas: 2 #指定Pod副本数
selector: #指定Pod的选择器
matchLabels:
app: myblog
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate #指定更新方式为滚动更新，默认策略，通过get deploy yaml查看
...更新策略
策略控制：
- 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。
以myblog为例，使用默认的策略，更新过程:
- maxSurge 25%，2个实例，向上取整，则maxSurge为1，意味着最多可以有2+1=3个Pod，那么此时会新创建1个ReplicaSet，RS-new，把副本数置为1，此时呢，副本控制器就去创建这个新的Pod
- 同时，maxUnavailable是25%，副本数2*25%，向下取整，则为0，意味着，滚动更新的过程中，不能有少于2个可用的Pod，因此，旧的Replica（RS-old）会先保持不动，等RS-new管理的Pod状态Ready后，此时已经有3个Ready状态的Pod了，那么由于只要保证有2个可用的Pod即可，因此，RS-old的副本数会有2个变成1个，此时，会删掉一个旧的Pod
- 删掉旧的Pod的时候，由于总的Pod数量又变成2个了，因此，距离最大的3个还有1个Pod可以创建，所以，RS-new把管理的副本数由1改成2，此时又会创建1个新的Pod，等RS-new管理了2个Pod都ready后，那么就可以把RS-old的副本数由1置为0了，这样就完成了滚动更新
服务回滚
通过滚动升级的策略可以平滑的升级Deployment，若升级出现问题，需要最快且最好的方式回退到上一次能够提供正常工作的版本。为此K8S提供了回滚机制。
revision：更新应用时，K8S都会记录当前的版本号，即为revision，当升级出现问题时，可通过回滚到某个特定的revision，默认配置下，K8S只会保留最近的几个revision，可以通过Deployment配置文件中的spec.revisionHistoryLimit属性增加revision数量，默认是10。
查看当前：
[root@k8s-deploy ~]# kubectl -n test rollout history deploy nginx-deployment ##CHANGE-CAUSE为空
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
2 <none>
3 <none>
记录回滚
[root@k8s-deploy ~]# kubectl -n test set image deploy nginx-deployment nginx-test=nginx:1.16.1 --record=true
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/nginx-deployment image updated
查看deployment更新历史
[root@k8s-deploy ~]# kubectl -n test rollout history deploy nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
2 <none>
3 kubectl set image deploy nginx-deployment nginx-deployment=nginx:1.16.1 --namespace=test --record=true
4 kubectl set image deploy nginx-deployment nginx-test=nginx:1.16.1 --namespace=test --record=true
回滚到具体的REVISION
[root@k8s-deploy ~]# kubectl -n test rollout undo deploy nginx-deployment --to-revision=3
deployment.apps/nginx-deployment rolled back