k8s node大量不可用

问题

假期第一天,早上6点50,大量node节点不可用告警发出,伴随应用异常,业务方、SRE均开始响应。

定位与解决

  • 4台节点不可用,20分钟后蔓延到35台节点。
  • etcd,k8s-api-server正常,不可用节点的docker存在异常,docker ps会hang住,且异常日志:
    ( Warning ContainerGCFailed 41s (x11 over 30m) kubelet, prod-k8s-node-9-86 rpc error: code = DeadlineExceeded desc = context deadline exceeded,同时伴随docker ps hang住现象)
    
  • 部分节点有系统级OOM异常报错日志
  • 业务方尝试重启应用B(在云平台上进行一次紧急上线)
  • 停止感染,异常节点范围得到控制。
  • 重启大法,尝试重启5台不可用节点,恢复。
  • 重启其他机器,直到全部恢复。

原因

  • 对比应用B在上线前后的配置,差异在于上线后的配置中取消了对glusterfs的挂载。(云平台会在应用重新发布时更新deployment等,说明应用长时间未发布过)
  • glusterfs已停用但尚未下线,数据迁移完成并不再维护。某几个gfs节点磁盘空间报警,导致节点负载较高。但因计划下线暂无处理。
  • 应用B是个老服务,未按要求下线对GlusterFS的使用,导致还有写入需求。
  • server端没空间负载高,导致gfs-client调用时iO响应延迟,而且docker中有容器挂载相关目录导致docker daemon不响应,继而导致kubelet自检异常,node变为notready,
  • 一旦节点被确认为不可调度Unschedulable,过5分钟则开始驱逐,应用B被重新调度到其他节点,其他节点上重复上述动作
  • 最终造成连锁反应。

GlusterFS的使用血泪史

  • 同事在更新GFS白名单时,不小心做成了覆盖,导致gfs大量连接被拒……
  • 对小文件性能不好,之前不小心将日志写入gfs直接导致应用太慢而unhealthy

反思

  • 要下线的服务,如果还没正式下,异常告警还是要多关注。
  • 容器调度策略也需关注,如果再有这么一个Pod–它能扰乱docker或node的状态,在当前的调度模式下,将很快影响到所有node,不是吗?