数据卷挂载问题快速恢复

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本文阐述的是业务快速恢复方案:当Pod因为数据卷挂载重启失败时,暂不去解决节点挂载的问题,而是让pod先在其他节点启动成功,快速恢复业务,待业务恢复后再去分析出问题的节点。

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. 登陆问题节点,分析原因:

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

相关实践学习
基于ECS和NAS搭建个人网盘
本场景主要介绍如何基于ECS和NAS快速搭建个人网盘。
阿里云文件存储 NAS 使用教程
阿里云文件存储(Network Attached Storage,简称NAS)是面向阿里云ECS实例、HPC和Docker的文件存储服务,提供标准的文件访问协议,用户无需对现有应用做任何修改,即可使用具备无限容量及性能扩展、单一命名空间、多共享、高可靠和高可用等特性的分布式文件系统。 产品详情:https://www.aliyun.com/product/nas
相关文章
|
存储 算法 安全
文件系统管理:挂载、格式化、备份和修复你的文件系统
文件系统管理:挂载、格式化、备份和修复你的文件系统
111 0
|
5月前
|
存储 Unix 数据挖掘
服务器数据恢复—DS4800存储lvm信息丢失数据恢复案例
DS4800服务器存储lvm信息丢失,基于DS4800的aix小机卷丢失。
服务器数据恢复—DS4800存储lvm信息丢失数据恢复案例
|
1月前
|
存储 Linux
服务器数据恢复——使用fsck后Ext4文件系统挂载不上的数据恢复案例
关于Ext4文件系统的几个概念: 块组:Ext4文件系统的全部空间被划分为若干个块组,每个块组结构基本上相同。 块组描述符表:每个块组都对应一个块组描述符,这些块组描述符统一放在文件系统的前部,称为块组描述符表。每个块组描述符大小为32字节,主要描述块位图、i-节点位图及i-节点表的地址等信息。 超级块(Superblock):用于存储文件系统的配置参数(块大小、总块数、i-节点数等)和动态信息(当前空闲块数和i-节点数)。Ext4文件系统的超级块始于1024字节处,即2号扇区。 i节点:描述文件的时间、大小、块指针等信息。
|
7月前
|
数据挖掘 Linux
服务器数据恢复—误操作导致xfs文件系统丢失,无法访问的数据恢复案例
一台服务器+MD1200磁盘柜通过RAID卡创建了一组RAID5阵列并分配一个LUN。在Linux系统层面将该LUN划分了sdc1和sdc2两个分区。通过LVM扩容的方式将sdc1分区加入到了卷组中的一个逻辑卷中,sdc2分区格式化为XFS文件系统使用。Linux操作系统采用的xfs文件系统。
服务器数据恢复—误操作导致xfs文件系统丢失,无法访问的数据恢复案例
|
2月前
|
存储 数据挖掘 Linux
服务器数据恢复—ext4文件系统服务器数据恢复案例
服务器数据恢复环境: 某品牌服务器+同品牌存储,Linux centos7+EXT4文件系统。 服务器故障: 意外断电导致服务器操作系统不能正常启动。经过修复后系统可以正常启动,但是挂载的分区无法正常访问。使用fsck修复这个问题分区,虽然修复完成之后文件系统正常,但是发现部分文件丢失,查看后发现缺失的部分文件在lost+found文件夹里,文件名已经发生改变。
|
4月前
|
存储 运维 数据挖掘
服务器数据恢复—修复xfs文件系统导致数据丢失的数据恢复案例
某公司一台服务器,连接了一台存储。该服务器安装linux操作系统,文件系统为xfs。 在运行过程中该服务器出现故障,管理员使用xfs_repair工具试图对xfs文件系统进行修复但失败,服务器中所有数据丢失。
|
6月前
|
Linux KVM 数据库
服务器数据恢复—EXT4文件系统下误删除虚拟机数据恢复案例
服务器数据恢复环境&故障: 1台服务器,Linux操作系统+EXT4文件系统,部署了数台KVM虚拟机,每台虚拟机包含一个qcow2格式的磁盘文件,和一个raw格式的磁盘文件。 工作人员操作失误删除了3台服务器上的KVM虚拟机,需要恢复raw格式的磁盘文件。
服务器数据恢复—EXT4文件系统下误删除虚拟机数据恢复案例
|
7月前
|
存储 数据挖掘
服务器数据恢复—服务器XFS分区丢失的数据恢复案例
服务器数据恢复环境: 一台服务器+MD1200磁盘柜,通过raid卡将15块磁盘组建成一组raid5磁盘阵列。raid5阵列分配了2个lun,操作系统层面对lun进行分区:1个分区采用LVM扩容方式加入到了root_lv中,其余分区格式化为XFS文件系统。 服务器故障: 工作人员为服务器重装操作系统时操作失误导致分区状态改变,一个存放重要数据的分区丢失,无法访问。
服务器数据恢复—服务器XFS分区丢失的数据恢复案例
|
7月前
|
存储 Windows
如何恢复硬盘删除的数据?10个简单实用方法详解
本文介绍了如何恢复硬盘删除的数据,包括删除文件恢复的基本原理和降低恢复可能性的情况,如新数据覆盖、硬盘损坏等。文中列举了10种恢复方法,如使用Ctrl + Z、查看隐藏文件、从回收站还原、利用文件历史、备份还原、网盘下载、数据恢复软件以及专业数据恢复服务等。每种方法都有详细的操作步骤,并附有注意事项。
|
7月前
|
数据挖掘 Linux
服务器数据恢复—XFS文件系统服务器数据恢复案例
服务器数据恢复环境: 服务器使用磁盘柜+RAID卡搭建了一组riad5磁盘阵列。服务器上层分配了一个LUN,划分了两个分区:sdc1分区和sdc2分区。通过LVM扩容的方式,将sdc1分区加入到了root_lv中;sdc2分区格式化为XFS文件系统。服务器安装的Linux系统。 服务器故障: 服务器重装操作系统后sdc磁盘分区发生改变,原sdc2分区丢失,无法访问。
服务器数据恢复—XFS文件系统服务器数据恢复案例