驱逐导致服务中断

TODO 优化

案例

TKE 一客户的某个节点有问题,无法挂载nfs,通过新加节点,驱逐故障节点的 pod 来规避,但导致了业务 10min 服务不可用,排查发现其它节点 pod 很多集体出现了重启,主要是连不上 kube-dns 无法解析 service,业务调用不成功,从而对外表现为服务不可用。

为什么会中断?驱逐的原理是先封锁节点,然后将旧的 node 上的 pod 删除,replicaset 控制器检测到 pod 减少,会重新创建一个 pod,调度到新的 node上,这个过程是先删除,再创建,并非是滚动更新,因此更新过程中,如果一个deployment的所有 pod 都在被驱逐的节点上,则可能导致该服务不可用。

那为什么会影响其它 pod?分析kubelet日志,kube-dns 有两个副本,都在这个被驱逐的节点上,所以驱逐的时候 kube-dns 不通,影响了其它 pod 解析 service,导致服务集体不可用。

那为什么会中断这么久?通常在新的节点应该很会快才是,通过进一步分析新节点的 kubelet 日志,发现 kube-dns 从拉镜像到容器启动之间花了很长时间,检查节点上的镜像发现有很多大镜像(1~2GB),猜测是拉取镜像有并发限制,kube-dns 的镜像虽小,但在排队等大镜像下载完,检查 kubelet 启动参数,确实有 --registry-burst 这个参数控制镜像下载并发数限制。但最终发现其实应该是 --serialize-image-pulls 这个参数导致的,kubelet 启动参数没有指定该参数,而该参数默认值为 true,即默认串行下载镜像,不并发下载,所以导致镜像下载排队,是的 kube-dns 延迟了很长时间才启动。

解决方案

  • 避免服务单点故障,多副本,并加反亲和性
  • 设置 preStop hook 与 readinessProbe,更新路由规则

「真诚赞赏,手留余香」

roc

请我喝杯咖啡?

使用微信扫描二维码完成支付