数据卷挂载问题快速恢复

Pod挂载、卸载数据卷出现问题的原因很多,有存储卷设计的缺陷、有相关组件实现的bug、有使用方式不当的可能,面对复杂的应用、存储交互系统,我们需要从两个方面对待数据卷问题:

  • 尽量别出问题:减少存储组件的自身稳定性 && 规范的使用方式。
  • 如何面对问题:首要是快速恢复业务,然后分析问题。

本文阐述的是业务快速恢复方案:当Pod因为数据卷挂载重启失败时,暂不去解决节点挂载的问题,而是让pod先在其他节点启动成功,快速恢复业务,待业务恢复后再去分析出问题的节点。

更新一个Pod,卡在了 ContainerCreating 状态:

例如:你在Deployment类型应用中挂载NAS数据卷,Pod在启动的时候报错为挂载失败:

Warning  FailedMount  18s   kubelet, cn-shenzhen.192.168.1.24  Unable to mount volumes for pod "nas-static-796b49b5f8-svbvh_default(2d483078-1400-11ea-a9b7-00163e084110)": 
timeout expired waiting for volumes to attach or mount for pod "default"/"nas-static-796b49b5f8-svbvh". 
list of unmounted volumes=[pvc-nas]. list of unattached volumes=[pvc-nas default-token-9v9hl]

更新前数据卷使用是正常的,而更新后pod启动不了,并有上述信息显示数据卷挂载不上,有一个可能性为:当前pod所在节点对此pv/pvc出现状态异常。具体异常原因暂不深究。

通过把pod调度到其他节点快速启动pod,参考如下步骤:

1. 确定pod所在节点:

根据上述错误信息即可拿到节点为:cn-shenzhen.192.168.1.24

也可以通过下面步骤拿到:
# podname="nas-static-796b49b5f8-svbvh"
# namespace="default"
#  kubectl describe pod $podname -n $namespace | grep Node: | awk '{print $2}'
cn-shenzhen.192.168.1.24/192.168.1.24

2. 设置节点不可调度:

您可以使用控制台来配置节点调度状态,参考

也可以使用下面命令行执行给当前挂载有问题的节点打上污点标签,确保pod不会再往这个节点调度:

# kubectl taint nodes cn-shenzhen.192.168.1.24 key=value:NoSchedule
node/cn-shenzhen.192.168.1.24 tainted

3. 重启问题Pod:

这时重启问题Pod,新建的Pod就不会调度到刚才有问题的节点了:

删除问题Pod:
# kubectl delete pod nas-static-796b49b5f8-svbvh
pod "nas-static-796b49b5f8-svbvh" deleted

新的pod启动成功,且调度到新节点:
# kubectl get pod
NAME                          READY   STATUS        RESTARTS   AGE
nas-static-857b99fcc9-vvzkx   1/1     Running       0          14s
# kubectl describe pod nas-static-857b99fcc9-vvzkx | grep Node
Node:               cn-shenzhen.192.168.1.25/192.168.1.25

4. 后续处理:

上述步骤目的是保证您您的业务快速恢复,但问题节点的问题还存在,您可以通过[存储常见问题]()进行排查分析。

如果您无法解决节点问题,可以联系阿里云容器服务技术支持。节点问题解决后,您可以通过控制台或者命令行将问题节点配置为可调度状态;

# kubectl taint nodes cn-shenzhen.192.168.1.24 key:NoSchedule-
node/cn-shenzhen.192.168.1.24 untainted

更新一个pod,卡在 Terminating 状态:

例如:你使用statefulset创建应用,并挂载了云盘数据卷;当更新应用的时候,pod一直处于Terminating状态从而导致新的pod无法正常启动。

# kubectl delete pod web-0

# kubectl get pod
NAME    READY   STATUS        RESTARTS   AGE
web-0   0/1     Terminating   0          47m

到pod所在节点查看下面日志文件:

# tailf /var/log/alicloud/flexvolume_disk.log
# tailf /var/log/messages | grep kubelet

如果发现报错原因为数据卷Umount/Detach等失败,例如:

unmount command failed, status: Failure, reason:

device is busy 字样
或
target is busy 字样
或
Orphan Pod字样
等等

如果在没有找到如何解决问题时急于恢复业务,可以先将问题pod强制删除,优先恢复业务。

1. 使用强制删除命令结束当前pod:

# kubectl delete pod web-0 --force=true --grace-period=0
pod "web-0" force deleted

此命令会强制删除Etcd数据库中的pod信息,从而为创建新pod提供可能(StatefulSet中,老pod没有删除前新pod不会重建)。

2. 如果新建pod启动的时候失败,卡在 ContainerCreating:

可以参考 “更新一个Pod,卡在了 ContainerCreating 状态” 做法,为node配置不可调度,快速恢复pod运行。

3. 登陆问题节点,分析原因:

登陆问题所在节点,通过[存储常见问题]()进行排查分析。无法解决时可能联系阿里云容器服务技术支持。

上一篇:lua元表和元方法 《lua程序设计》 13章 读书笔记


下一篇:带返回值的函数,闭包,沙箱,递归详解