Kubernetes Pod被驱逐原因详解

Kubernetes官方给出了下属Pod被驱逐的原因:

  • 抢占驱逐 (Preemption and Eviction) [1]
  • 节点压力驱逐 (Node-pressure) [2]
  • 污点驱逐 (Taints) [3]
  • 使用API发起驱逐 (API-initiated) [4]
  • 排出Node上的Pod (drain) [5]
  • 被 controller-manager 驱逐
图片[1]-Kubernetes Pod被驱逐原因详解-不念博客

抢占和优先级

抢占是指当节点资源不足以运行新添加的Pod时,kube-scheduler 会检查低优先级Pod而后驱逐掉这些Pod以将资源分配给优先级高的Pod。

这个过程称为 “抢占” 例如这个实例是 kube-proxy 被驱逐的场景

节点压力驱逐

节点压力驱逐是指,Pod所在节点的资源,如CPU, 内存, inode等,这些资源被分为可压缩资源CPU (compressible resources) 与不可压缩资源 (incompressible resources) 磁盘IO, 内存等,当不可压缩资源不足时,Pod会被驱逐。

对于此类问题的驱逐 是每个计算节点的 kubelet 通过捕获 cAdvisor 指标来监控节点的资源使用情况。

被 controller-manager 驱逐

kube-controller-manager 会定期检查节点的状态,如节点处于 NotReady 超过一定时间,或Pod部署长时间失败,这些Pod由控制平面 controller-manager 创建新的Pod已替换存在问题的Pod

通过API发起驱逐

Kubernetes为用户提供了驱逐的API,用户可以通过调用API来实现自定义的驱逐。

对于 1.22 以上版本,可以通过API policy/v1 进行驱逐

curl -v \
 -H 'Content-type: application/json' \
 https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d '\
 {
        "apiVersion": "policy/v1",
        "kind": "Eviction",
        "metadata": {
            "name": "quux",
            "namespace": "default"
        }
    }'

例如,要驱逐Pod netbox-85865d5556-hfg6v,可以通过下述命令

# 1.22+
$ curl -v 'https://10.0.0.4:6443/api/v1/namespaces/default/pods/netbox-85865d5556-hfg6v/eviction' \
--header 'Content-Type: application/json' \
--cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
--key /etc/kubernetes/pki/apiserver-kubelet-client.key \
--cacert /etc/kubernetes/pki/ca.crt \
-d '{
    "apiVersion": "policy/v1",
    "kind": "Eviction",
    "metadata": {
        "name": "netbox-85865d5556-hfg6v",
        "namespace": "default"
    }
}'

# 1.22-
curl -v 'https://10.0.0.4:6443/api/v1/namespaces/default/pods/netbox-85865d5556-hfg6v/eviction' \
--header 'Content-Type: application/json' \
--cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
--key /etc/kubernetes/pki/apiserver-kubelet-client.key \
--cacert /etc/kubernetes/pki/ca.crt \
-d '{
    "apiVersion": "policy/v1beta1",
    "kind": "Eviction",
    "metadata": {
        "name": "netbox-85865d5556-hfg6v",
        "namespace": "default"
    }
}'

可以看到结果,旧Pod被驱逐,而新Pod被创建,在这里实验环境节点较少,所以体现为没有更换节点

$ kubectl get pods -o wide
NAME                      READY   STATUS        RESTARTS   AGE    IP              NODE             NOMINATED NODE   READINESS GATES
netbox-85865d5556-hfg6v   1/1     Terminating   0          101d   192.168.1.213   master-machine   <none>           <none>
netbox-85865d5556-vlgr4   1/1     Running       0          101d   192.168.0.4     node01           <none>           <none>
netbox-85865d5556-z6vqx   1/1     Running       0          11s    192.168.1.220   master-machine   <none>           <none>

通过API驱逐返回状态

  • 200 OK|201 Success:允许驱逐,Eviction 类似于向Pod URL发送 DELETE 请求
  • 429 Too Many Requests:由于API限速可能会看到该相应,另外也为配置原因,不允许驱逐 poddisruptionbudget (PDB是一种保护机制,将总是确保一定数量或百分比的Pod 被自愿驱逐)
  • 500 Internal Server Error:不允许驱逐,存在错误配置,如多个PDB引用一个 Pod

排出Node上的Pod

drain 是kubernetes 1.5+之后提供给用户维护命令,通过这个命令 (kubectl drain <node_name>) 可以驱逐该节点上运行的所有Pod,已用来对节点主机进行操作(如内核升级,重启)

Notes:kubectl drain <node_name> 一次只能接一个nodename [6]

污点驱逐

污点通常与容忍度同时使用,拥有污点的node,Pod将不会被调度至该节点,而容忍度将允许一定的污点来调度 pod。

在Kubernetes 1.18+后,允许基于污点的驱逐机制,即kubelet在某些情况下会自动添加节点从而进行驱逐:

Kubernetes内置了一些污点,此时 Controller 会自动污染节点:

  • node.kubernetes.io/not-ready: Node故障。对应 NodeCondition 的Ready = False。
  • node.kubernetes.io/unreachable:Node控制器无法访问节点。对应 NodeCondition Ready= Unknown。
  • node.kubernetes.io/memory-pressure:Node内存压力。
  • node.kubernetes.io/disk-pressure:Node磁盘压力。
  • node.kubernetes.io/pid-pressure:Node有PID压力。
  • node.kubernetes.io/network-unavailable:Node网络不可用。
  • node.kubernetes.io/unschedulable:Node不可调度。
© 版权声明
THE END
喜欢就支持一下吧
点赞99赞赏 分享
评论 抢沙发
头像
欢迎光临不念博客,留下您的想法和建议,祝您有愉快的一天~
提交
头像

昵称

取消
昵称

    暂无评论内容