pod eviction

发表于 更新于 分类于 本文字数： 1.4k 阅读时长 ≈ 5 分钟

K8S 的 pod eviction

K8S 有个特色功能叫 pod eviction，它在某些场景下如节点 NotReady，资源不足时，把 pod 驱逐至其它节点。本文首先介绍该功能，最后谈谈落地经验。

介绍

从发起模块的角度，pod eviction 可以分为两类：

  • Kube-controller-manager: 周期性检查所有节点状态，当节点处于 NotReady 状态超过一段时间后，驱逐该节点上所有 pod。
  • Kubelet: 周期性检查本节点资源，当资源不足时，按照优先级驱逐部分 pod。

Kube-controller-manger 发起的驱逐

Kube-controller-manager 周期性检查节点状态，每当节点状态为 NotReady，并且超出 podEvictionTimeout 时间后，就把该节点上的 pod 全部驱逐到其它节点，其中具体驱逐速度还受驱逐速度参数，集群大小等的影响。最常用的 2 个参数如下：

  • –pod-eviction-timeout：NotReady 状态节点超过该时间后，执行驱逐，默认 5 min。
  • –node-eviction-rate：驱逐速度，默认为 0.1 pod/秒

当某个 zone 故障节点的数目超过一定阈值时，采用二级驱逐速度进行驱逐。

  • –large-cluster-size-threshold：判断集群是否为大集群，默认为 50，即 50 个节点以上的集群为大集群。
  • –unhealthy-zone-threshold：故障节点数比例，默认为 55%
  • –secondary-node-eviction-rate：当大集群的故障节点超过 55% 时，采用二级驱逐速率，默认为 0.01 pod／秒。当小集群故障节点超过 55% 时，驱逐速率为 0 pod／秒。

判断是否驱逐的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func (nc *NodeController) monitorNodeStatus() error {
        ......
        if currentReadyCondition != nil {
            // Check eviction timeout against decisionTimestamp
            if observedReadyCondition.Status == api.ConditionFalse &&
                decisionTimestamp.After(nc.nodeStatusMap[node.Name].readyTransitionTimestamp.Add(nc.podEvictionTimeout)) {
                if nc.evictPods(node) {
                    glog.V(2).Infof("Evicting pods on node %s: %v is later than %v + %v", node.Name, decisionTimestamp, nc.nodeStatusMap[node.Name].readyTransitionTimestamp, nc.podEvictionTimeout)
                }
            }
            if observedReadyCondition.Status == api.ConditionUnknown &&
                decisionTimestamp.After(nc.nodeStatusMap[node.Name].probeTimestamp.Add(nc.podEvictionTimeout)) {
                if nc.evictPods(node) {
                    glog.V(2).Infof("Evicting pods on node %s: %v is later than %v + %v", node.Name, decisionTimestamp, nc.nodeStatusMap[node.Name].readyTransitionTimestamp, nc.podEvictionTimeout-gracePeriod)
                }
            }
}

Kubelet 发起的驱逐

Kubelet 周期性检查本节点的内存和磁盘资源，当可用资源低于阈值时，则按照优先级驱逐 pod，具体检查的资源如下：

  • memory.available
  • nodefs.available
  • nodefs.inodesFree
  • imagefs.available
  • imagefs.inodesFree

以内存资源为例，当内存资源低于阈值时，驱逐的优先级大体为 BestEffort > Burstable > Guaranteed，具体的顺序可能因实际使用量有所调整。当发生驱逐时，kubelet 支持 soft 和 hard 两种模式，soft 模式表示缓期一段时间后驱逐，hard 模式表示立刻驱逐。

落地经验

对于 kubelet 发起的驱逐，往往是资源不足导致，它优先驱逐 BestEffort 类型的容器，这些容器多为离线批处理类业务，对可靠性要求低。驱逐后释放资源，减缓节点压力，弃卒保帅，保护了该节点的其它容器。无论是从其设计出发，还是实际使用情况，该特性非常 nice。

对于由 kube-controller-manager 发起的驱逐，效果需要商榷。正常情况下，计算节点周期上报心跳给 master，如果心跳超时，则认为计算节点 NotReady，当 NotReady 状态达到一定时间后，kube-controller-manager 发起驱逐。然而造成心跳超时的场景非常多，例如：

  • 原生 bug：kubelet 进程彻底阻塞
  • 误操作：误把 kubelet 停止
  • 基础设施异常：如交换机故障演练，NTP 异常，DNS 异常
  • 节点故障：硬件损坏，掉电等

从实际情况看，真正因计算节点故障造成心跳超时概率很低，反而由原生 bug，基础设施异常造成心跳超时的概率更大，造成不必要的驱逐。

理想的情况下，驱逐对无状态且设计良好的业务方影响很小。但是并非所有的业务方都是无状态的，也并非所有的业务方都针对 Kubernetes 优化其业务逻辑。例如，对于有状态的业务，如果没有共享存储，异地重建后的 pod 完全丢失原有数据；即使数据不丢失，对于 Mysql 类的应用，如果出现双写，重则破坏数据。对于关心 IP 层的业务，异地重建后的 pod IP 往往会变化，虽然部分业务方可以利用 service 和 dns 来解决问题，但是引入了额外的模块和复杂性。

除非满足如下需求，不然请尽量关闭 kube-controller-manager 的驱逐功能，即把驱逐的超时时间设置非常长，同时把一级／二级驱逐速度设置为 0。否则，非常容易就搞出大大小小的故障，血泪的教训。

  • 业务方要用正确的姿势使用容器，如数据与逻辑分离，无状态化，增强对异常处理等
  • 分布式存储
  • 可靠的 Service／DNS 服务或者保持异地重建后的 IP 不变

通常情况下，从架构设计的角度来说，管理模块的不可用并不会影响已有的实例。例如：OpenStack 计算节点的服务异常，管理节点不会去变动该节点上已经运行虚拟机。但是 kubernetes 的 pod eviction 则打破了这种设计，出发点很新颖，但是落地时，需要充分的考虑业务方的特点，以及业务方的设计是否充分考虑了 kubernetes 的特色。

参考

Configure Out Of Resource Handling
记一次 k8s 集群单点故障引发的血案
容器化RDS——计算存储分离架构下的“Split-Brain”