手册下载
H3C 统一数字底盘故障处理手册-E07xx-5W102-整本手册.pdf (1.36 MB)
故障处理手册
资料版本:5W102-20230206
Copyright © 2023 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文档中的信息可能变动,恕不另行通知。
3.3 磁盘空间不足导致容器运行异常,一直处于Evicted状态
3.4 修改巨页配置后导致K8s节点状态异常,一直处于Not Ready状态
3.6 Matrix升级后,kube-apiserver、kube-scheduler或kube-controller-manager服务异常
3.7 calico-node等Pod异常,报错Delegation not available for unit type
5.1 安全策略配置为全部拒绝后,集群拒绝所有访问Matrix服务的请求
6.1 Admin用户输入错误的密码导致登录Matrix失败
8.2 在ETCD非独立磁盘部署环境下,出现客户端请求超时或ETCD集群主备切换频繁
10.2 节点所在服务器下电后重启或网络异常断开,Matrix依赖的文件丢失
10.3 节点所在服务器下电后重启,页面中节点飘红、飘黄或监控页面Pod处于CreateContainerError状态
10.4 节点所在服务器下电后重启,页面中节点飘红、飘黄或监控页面Pod处于Error状态
10.5 节点所在服务器下电后重启,页面中节点飘黄,查看节点详情,Grafana组件健康状态异常
11.1 集群部署失败,查看日志出现错误K8SINSTALL-ERROR
12.1 统一数字底盘部署失败,查看日志显示kubectl exec命令执行失败
13.1 IPv6环境下,节点或现有网卡增加IP后,集群部署失败
15 重启节点或网络变动后,出现部分使用GlusterFS存储的Pod异常
16 卸载/重建Matrix后再次部署GlusterFS应用失败
16.1 GlusterFS组件使用的磁盘或磁盘分区内存在其他数据,导致GlusterFS组件部署失败
16.2 存储卷删除失败,导致使用GlusterFS存储的组件安装失败
16.3 glusterd进程退出,导致使用GlusterFS存储的组件升级失败
16.4 通过ISO方式重建Matrix后GlusterFS服务异常
19 服务器下电重启、网络异常断开或者单机扩集群,出现使用PXC数据库的Pod异常
19.4 PXC数据库启动文件grastate.dat内容全部丢失
本文档介绍统一数字底盘常见故障的诊断及处理措施。
当出现故障时,请尽可能全面、详细地记录现场信息(包括但不限于以下内容),收集信息越全面、越详细,越有利于故障的快速定位。
· 记录您所使用的统一数字底盘版本、Matrix版本、操作系统版本。
· 记录具体的故障现象、故障时间、配置信息。
· 记录完整的网络拓扑,包括组网图、端口连接关系、故障位置。
· 收集日志信息和诊断信息(收集方法见1.2 收集故障运行信息)。
· 记录现场采取的故障处理措施及实施后的现象效果。
您可以通过如下步骤,收集统一数字底盘的运行信息。
(1) 在浏览器中输入统一数字底盘GUI的登录地址(格式为:http://ucenter_ip_address:30000/central/index.html),回车后打开统一数字底盘GUI的登录界面。输入用户名和密码后,单击<登录>按钮进入统一数字底盘GUI首页。
(2) 在统一数字底盘GUI界面中,单击[系统>日志管理>运行日志列表]菜单项,进入运行日志列表页面,如图1-1所示。然后单击“全局日志”或“节点日志”页签,可进行如下操作:
¡ 通过“所在目录(相对路径)、“日期(起)”和“日期(止)”可查看指定目录和日期区间的全局日志或节点日志文件信息。
¡ 在搜索栏输入指定的文件或者目录名称,可搜索相应的日志。
¡ 勾选指定日志或勾选“全选”复选框,单击<导出>按钮,将导出的全局或节点运行日志信息保存到本地。
当故障无法自行解决时,请准备好设备运行信息、故障现象等材料,发送给技术支持人员进行故障定位分析。
用户支持邮箱:service@h3c.com
技术支持热线电话:400-810-0504(手机、固话均可拨打)
在操作系统中选择磁盘进行分区操作时,默认勾选所有磁盘。但在实际应用中,存在只需勾选部分磁盘的情况。例如,实际现场环境使用U盘安装操作系统,此时,则需取消勾选U盘所在的磁盘。
取消第二块磁盘或仅保留第一块磁盘后,自动加载的分区方案中缺少/var/lib/etcd分区。
图2-1 取消勾选第二、三块磁盘
图2-2 自动加载的分区缺少/var/lib/etcd分区
造成故障的原因:分区方案默认按照所有磁盘都勾选的情况制定,存在多块磁盘时,系统分区放在第一块磁盘上,ETCD分区放在第二块磁盘上。若第二块磁盘不勾选,则自动分区中将缺少/var/lib/etcd分区。
故障处理步骤如下:
若自动加载的分区方案中缺少/var/lib/etcd分区,手动挂载该分区即可,详细步骤如下。
(1) 单击图标,在弹出窗口增加/var/lib/etcd挂载点,期望容量设置为50GiB。
(2) 配置完成后,单击<添加挂载点>按钮。
(3) 所有分区配置完成后,单击<完成>按钮。
集群中的某个节点因为硬件故障无法恢复,需要更换新的节点服务器。
集群中的某个节点因为硬件故障无法恢复,需要更换新的节点服务器,可按如下步骤处理:
(1) 配置替换节点服务器,使其与原故障节点完全相同的主机名、网卡名称、节点IP地址、用户名、密码、RAID模式以及磁盘分区。
(2) 在替换节点服务器中安装与集群节点相同版本的Matrix软件,具体请参见《统一数字底盘部署指导》。
(3) 登录Matrix界面,在[部署/集群]页面下,单击故障节点右上角的按钮,选择[重建]菜单项重建该节点,即可完成更换服务器的操作。
以下问题全部存在时,即可通过该章节进行故障处理。
· 统一数字底盘页面无法登录。
· 进入Matrix页面,存在Master节点异常(节点飘红)且异常节点无法ping通。
· 异常节点上存在处于Running状态的Pod。
· 执行kubectl get endpoints -nservice-software itom-central-login-svc命令查看itom-central-login服务对应的endpoints。若endpoints依然保留异常节点上Pod IP地址,则视为异常。
图3-1 查看itom-central-login服务对应的endpoints
(1) 登录异常节点后台,执行kubectl drain nodeName --ignore-daemonsets --force --delete-local-data --timeout=1800s命令将所有Pod从异常节点上驱逐。其中,nodeName为异常节点的名称。
(2) 执行kubectl delete node nodeName命令删除异常节点。其中,nodeName为异常节点的名称。
(3) 修复异常断联的节点。若是服务器硬件故障无法恢复,必须更换节点服务器进行修复。
(4) 修复节点之后,登录Matrix界面,在[部署>集群]页面下,单击故障节点右上角的按钮,选择[重建]菜单项重建该节点。
(5) 如果上述操作完成后故障仍无法排除,请联系技术支持工程师。
集群中某个节点磁盘空间已满,在该节点主机中使用kubectl get pods --all-namespaces命令,出现大量处于Evicted状态的容器,手动清理磁盘后容器仍保持该状态。
造成故障的原因:节点服务器磁盘空间不足的情况下,K8S自动清理机制会产生大量处于Evicted状态的容器。
(2) 登录Matrix GUI界面,进入集群部署页面。在该页面选择待修复的节点并单击节点右上角的按钮,选择“修复”选项进行节点修复,修复完成后K8S会自动删除节点服务器中处于Evicted状态的容器。
修改操作系统巨页配置,如将/etc/default/grub文件中GRUB_CMDLINE_LINUX参数值从"crashkernel=auto rhgb quiet default_hugepagesz=2M hugepagesz=2M hugepages=8192"改为"crashkernel=auto rhgb quiet default_hugepagesz=1G hugepagesz=1G hugepages=16"后,引起K8s节点状态异常(Not Ready状态),重启系统后仍然无法恢复。
造成故障的原因:default_hugepagesz=1G时Linux内核在/sys/kernel/mm/hugepages/目录下仅保留了hugepages-1048576kB目录,Kubelet可以根据该目录读取系统巨页配置,并以patch方式添加新巨页,配置到集群。
若集群之前配置过2M巨页,则patch操作后,1G和2M两种巨页配置值将同时存在。而目前Kubelet并不支持同时存在1G和2M两种巨页配置,从而导致K8s节点状态同步失败,K8s节点状态变为Not Ready状态。
通过同时指定1G和2M的巨页数量(hugepages),并把其中一个巨页配置的巨页数量指定为0,如default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M hugepages=0,可以解决两种巨页配置同时存在的问题。故障处理步骤如下:
(1) 修改巨页配置文件。
a. 通过vi编辑器打开巨页配置文件。
[root@node1 ~]# vi /etc/default/grub
b. 按[i]键进入编辑模式,按照如下所示修改文件配置。修改完成后,按[ESC]键退出编辑模式,再输入:wq,按回车,保存巨页配置文件并退出vi编辑器。
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet default_hugepagesz=1G
hugepagesz=1G hugepages=16 hugepagesz=2M hugepages=0"
GRUB_DISABLE_RECOVERY="true"
(2) 使配置生效并重启节点服务器
¡ 若系统以UEFI模式启动,请使用如下方式保存配置并重启。
[root@node1 ~]# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-862.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-862.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f2e062c5077847ae837b2f1cdb91104f
Found initrd image: /boot/initramfs-0-rescue-f2e062c5077847ae837b2f1cdb91104f.img
Done
[root@node1 ~]# reboot
¡ 若系统以Legacy模式启动,请使用如下方式保存配置并重启。
[root@node1 ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-862.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-862.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f2e062c5077847ae837b2f1cdb91104f
Found initrd image: /boot/initramfs-0-rescue-f2e062c5077847ae837b2f1cdb91104f.img
Done
[root@node1 ~]# reboot
(3) 验证巨页是否配置成功。若配置成功,则将显示default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M hugepages=0。
[root@node1 ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-862.el7.x86_64 root=UUID=f47e3128-e888-499e-b370-2b381b6f3134 ro crashkernel=auto rhgb quiet default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M hugepages=0。
在Matrix集群参数页面修改集群网络模式失败。
造成故障的原因:主用Master节点ETCD服务异常,修改集群网络模式时需要请求两次ETCD,服务,一次请求用于修改calico中的网络模式,另一次请求用于修改页面上显示的网络模式,此时分为两种情况:
· 第一种情况:页面显示集群网络模式已修改,但提示“修改失败”。
该种情况的原因为:由于ETCD服务异常导致两次请求一次成功一次失败,calico和页面显示的数据不一致。
以当前环境为单子网环境,需要修改网络模式为多子网模式为例,如果页面提示修改失败,但是集群参数配置页已修改为多子网模式,可以通过下述步骤进行故障处理。
故障处理步骤如下:
a. 进入主用Master节点服务器,查看主用Master节点的ETCD服务是否已经恢复正常。若已恢复正常可继续进行下列操作;若没有恢复正常请联系技术支持工程师。
[root@name1 1.0.0]# etcdctl cluster-health
member fb58b3b32bac01c is healthy: got healthy result from http://10.99.212.82:2379
member aa6e53b313aa741f is healthy: got healthy result from http://10.99.212.81:2379
member d1fcbe1f6db25390 is healthy: got healthy result from http://10.99.212.83:2379
b. 若主用Master节点的ETCD服务已恢复正常,请将集群网络模式修改为集群原有网络模式,例如上述环境需要改为“单子网”模式,单击应用后将提示修改失败,但是集群参数页面已经显示改为“单子网”模式。
c. 再次将网络模式修改为“多子网”模式,修改成功,即该故障已恢复。
· 第二种情况:页面显示集群网络模式没有修改,且提示“修改失败”。
该种情况的原因为:由于ETCD服务异常导致两次请求都没有成功。
故障处理步骤如下:
a. 进入主用Master节点服务器,查看主用Master节点的ETCD服务是否已经恢复正常。若已恢复正常可继续进行下列操作;若没有恢复正常请联系技术支持工程师。
[root@name1 1.0.0]# etcdctl cluster-health
member fb58b3b32bac01c is healthy: got healthy result from http://10.99.212.82:2379
member aa6e53b313aa741f is healthy: got healthy result from http://10.99.212.81:2379
member d1fcbe1f6db25390 is healthy: got healthy result from http://10.99.212.83:2379
b. 再次修改集群网络模式,页面显示和提示都为修改成功,即该故障已恢复。
Matrix升级(单机或集群)后节点飘红,查看异常节点的详情信息,显示kube-apiserver、kubeScheduler或kubeControllerManager异常。登录异常节点后台,使用kubectl get pod -A -owide命令,异常节点上存在处于CrashLoopBackOff状态的Pod。
该故障现象及故障处理步骤有以下两种。
· 故障现象
在异常Pod所在节点上执行netstat -anlp | grep -w 6443、netstat -anlp | grep -w 10251或netstat -anlp | grep -w 10252命令,存在kube-apiserver、kube-scheduler或kube-controller-manager服务端口被占用且存在处于LISTEN连接的现象。
· 故障原因
Matrix升级后,由于老的进程未正常退出,kube-apiserver的6443端口、kube-scheduler的10251端口或kube-controller-manager的10252端口未释放,导致新的Pod无法正常启动。后台执行kubectl logs -n kube-system $pod_name或docker logs $container_id命令可以查看端口被占用的相关日志。
· 故障处理步骤
以kube-scheduler Pod异常为例,在问题节点后台执行如下命令进行恢复。其他异常Pod(例如:kube-apiserver、kube-controller-manager)可参照如下步骤进行恢复。
a. 移除kube-scheduler Pod及容器。
[root@name ~]# mv /etc/kubernetes/manifests/kube-scheduler.yaml /opt/
b. 检查kube-scheduler容器是否全部退出,若已查询不到kube-scheduler容器,则进行下一步。若长时间查询仍然不退出,可尝试执行docker rm -f $container_id强制删除容器、或执行systemctl restart docker命令重启Docker服务。
[root@name ~]# docker ps | grep kube-scheduler
c. 执行netstat -anlp | grep -w 10251命令查询端口是否被释放,已释放现象为:命令查询结果中不存在LISTEN状态的连接。若已释放则进行下一步。
d. 启动kube-scheduler Pod。
[root@name ~]# mv /opt/kube-scheduler.yaml/etc/kubernetes/manifests/
e. 执行kubectl get pod -n kube-system -o wide 命令查询Pod状态
f. 如果上述操作完成后故障仍无法排除,请联系技术支持工程师。
· 故障现象
在异常Pod所在节点上执行netstat -anlp | grep -w 6443、netstat -anlp | grep -w 10251或netstat -anlp | grep -w 10252命令,存在端口被占用且只存在TIME_WAIT状态的连接,且占用端口的不是kube-apiserver、kube-scheduler或kube-controller-manager进程。
· 故障原因
Matrix升级过程中,由于kube-apiserver、kube-scheduler或kube-controller-manager Pod重启,导致6443、10251或10252端口被GlusterFS抢占,进而导致Pod异常。
· 故障处理步骤
请联系技术支持工程师。
页面上进行修改节点IP等操作后,节点飘红。登录异常节点后台,使用kubectl get pod -A -owide命令,发现集群中calico-node、calico-kube-controller等Pod异常。
kubelet日志中打印如下错误:
Error syncing pod 991e112f-c3a3-4c46-9a9b-dfde4ca0a27b ("calico-node-vlpz8_kube-system(991e112f-c3a3-4c46-9a9b-dfde4ca0a27b)"), skipping: failed to ensure that the pod: 991e112f-c3a3-4c46-9a9b-dfde4ca0a27b cgroups exist and are correctly applied: failed to create container for [kubepods burstable pod991e112f-c3a3-4c46-9a9b-dfde4ca0a27b] : Delegation not available for unit type
· 造成故障的原因:
containerd低版本开源问题导致该故障。
该问题从containerd-v1.3.0版本开始,已被解决。若存在该故障的环境中,containerd版本低于v1.3.0,则属于该故障。containerd版本查询方式为:后台执行containerd -v命令。
· 故障处理步骤
在异常Pod所在节点执行systemctl restart kubelet.service命令重启Kubelet服务即可。
单机模式扩容为集群模式失败后,原节点显示正常,新增加的节点显示“部署失败”且“开始部署”按钮为可单击状态。
造成故障的原因:单机模式扩容为集群模式失败后,节点将会自动回滚至单机模式时的状态,若“开始部署”按钮为可单击状态,表示节点回滚成功。
故障处理步骤如下:
· 登录Matrix界面,在[部署>集群]页面下,单击<开始部署>按钮开始扩容集群,所有节点的部署进度达到100%时,表示集群部署成功。
· 登录Matrix界面,在[部署>集群]页面下,单击部署失败节点右上角的按钮,删除该节点。再单击加号按钮,重新增加节点。单击<开始部署>按钮开始扩容集群,所有节点的部署进度达到100%时,表示集群部署成功。
单机模式扩容为集群模式失败后,原节点显示正常,新增加的节点显示“部署失败”且“开始部署”按钮为灰色不可单击状态。
造成故障的原因:单机模式扩容为集群模式失败后,节点将会自动回滚至单机模式时的状态,若“开始部署”按钮为灰色不可单击状态,表示节点回滚失败。
故障处理步骤如下:
(1) 卸载所有Master节点的Matrix软件包。
(2) 在原单机节点上重新安装Matrix软件包。
(3) 重新登录Matrix进行集群备份恢复操作,集群恢复后应用需要重新安装再进行配置恢复。
在安全策略页面,基本设置区域的默认动作设置为“拒绝”且删除规则信息区域的默认规则后,集群拒绝所有访问Matrix服务的请求。
造成故障的原因:默认动作为“拒绝”的情况下,Matrix默认放开8443端口的规则也被删除。
故障处理步骤如下:
(1) 登录任意一台Master服务器。
(2) 进入脚本目录。
[root@node1 ~]# cd /opt/matrix/k8s/disaster-recovery/
(3) 执行恢复安全策略脚本。
¡ root用户执行如下命令:
[root@node1 ~]# bash recover-security-policies.sh
¡ 非root用户执行如下命令:
[admin@node1 ~]$ sudo bash -c "source /etc/profile;bash recover-security-policies.sh"
(4) 脚本执行完成后,重新登录Matrix页面。
在登录Matrix页面,如果admin用户忘记登录密码等原因导致登录Matrix失败。
请根据集群情况执行对应脚本,进行重置密码的操作。
· 集群运行正常时重置密码。
a. 进入某一个Master节点的脚本存放目录,使用命令bash resetMatrixUserPassword.sh reset_password执行该脚本,其中resetMatrixUserPassword.sh为脚本名称,reset_password为新密码,例如:bash resetMatrixUserPassword.sh Pwd@123456。
[root@node1 ~]# cd /opt/matrix/k8s
[root@node1 k8s]# bash resetMatrixUserPassword.sh Pwd@123456
+ MATRIX_ADMIN_PASSWD=Pwd@123456
++ curl -k -g -X POST -H Content-Type:application/json -d '{"password": "Pwd@123456"}' https://localhost:8443/matrix/rsapi/v1.0/usermanage/reset_password
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 110 0 84 100 26 251 77 --:--:-- --:--:-- --:--:-- 252
+ return_info='{"token":"3ac4fd9b-35d7-4f66-97b0-2b4ef0a368d1","username":"admin","expireTime":600}'
+ [[ {"token":"3ac4fd9b-35d7-4f66-97b0-2b4ef0a368d1","username":"admin","expireTime":600} =~ admin ]]
+ echo 'Password reset succeeded.'
Password reset succeeded.
b. 脚本执行完成后,使用新密码重新登录Matrix页面即可。
· 集群紧急模式下重置密码。
a. 进入某一个Master节点的脚本存放目录,使用命令bash resetMatrixUserPassword_emergency.sh reset_password执行该脚本,其中resetMatrixUserPassword_emergency.sh为脚本名称,reset_password为新密码,例如:bash resetMatrixUserPassword_emergency.sh Pwd@123456。
[root@node1 ~]# cd /opt/matrix/k8s
[root@node1 k8s]# bash resetMatrixUserPassword_emergency.sh Pwd@123456
+ MATRIX_ADMIN_PASSWD=Pwd@123456
++ curl -k -g -X POST -H Content-Type:application/json -H X-Access-Mode:emergen cy -d '{"password": "Pwd@123456"}' https://localhost:8443/matrix/rsapi/v1.0/use rmanage/reset_password
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 110 0 84 100 26 253 78 --:--:-- --:--:-- --:--:-- 253
+ return_info='{"token":"d90753f5-cd2c-4c1c-b178-45cdb18c6261","username":"admi n","expireTime":600}'
+ [[ {"token":"d90753f5-cd2c-4c1c-b178-45cdb18c6261","username":"admin","expire Time":600} =~ admin ]]
+ echo 'Password reset succeeded.'
Password reset succeeded.
b. 脚本执行完成后,使用新密码重新登录Matrix页面即可。
在集群中某个节点的命令行界面,使用ifconfig命令对网卡进行重启后,默认路由丢失。
(1) 进入故障节点操作系统的命令行界面,使用命令systemctl restart network重启network服务即可。
[root@node01 ~]# systemctl restart network
(2) 使用命令route -n查看节点默认路由是否恢复。以下返回结果为举例,不同的环境默认路由将会不同。
[root@node01 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.99.212.1 0.0.0.0 UG 0 0 0 eth0
10.99.212.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
出现如下任意现象,均是由于ETCD存储数据文件在节点重启后损坏或者文件丢失,导致ETCD服务启动失败。可按照相应故障处理步骤进行操作。
现象一:
节点所在服务器下电后重启,ETCD服务由于数据库db文件损坏而启动失败,最终导致集群异常。查看/var/log/matrix-diag/Matrix/etcd/etcd.log日志有以下信息:
panic: freepages: failed to get all reachable pages (page 1407374894039040: out of bounds: 1264)
goroutine 116 [running]:
panic(0x55a1d6cce4a0, 0xc420202ef0)
/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/panic.go:551 +0x3c5 fp=0xc42006bf60 sp=0xc42006bec0 pc=0x55a1d5f0ae25
github.com/coreos/bbolt.(*DB).freepages.func2(0xc42020c180)
…
现象二:
正常情况下,ETCD中/var/lib/etcd/default.etcd/member/snap日志(快照日志)文件的最大日志索引值大于wal日志(预写日志)文件的最小日志索引值。
节点所在服务器下电后重启,若ETCD中wal日志文件的最大日志索引值大于snap日志文件的最大日志索引值,ETCD会由于丢失必要的操作日志数据,无法恢复数据,导致文件损坏。以下图为例。
现象三:
节点所在服务器下电后重启,ETCD服务由于数据库snap日志(快照日志)文件丢失而启动失败,最终导致集群异常。查看日志有以下信息:
etcdserver: recovering backend from snapshot error: database snapshot file path error: snap: snapshot file doesn't exist
现象四:
ETCD服务由于数据文件损坏而启动失败,导致节点状态异常。登录ETCD服务异常的节点查看日志有以下信息:
"error":"walpb: crc mismatch"
登录各节点服务器,通过命令systemctl status etcd查看各节点的ETCD服务状态,running为正常状态。若为不正常状态,可根据下列步骤进行故障恢复。
[root@node01 ~]# systemctl status etcd
· 如果仅有一个节点的ETCD服务出现上述现象,请登录Matrix界面,在[部署>集群]页面单击出现问题节点右上角的按钮,选择“重建”,可对指定节点进行重建操作,重建完成后故障即可恢复。
· 如果二个节点ETCD服务出现db文件损坏情况,此时Matrix页面会进入紧急模式状态,可通过节点重建方式逐个恢复问题节点。
· 如果单机环境或者三个节点的ETCD服务出现上述现象,有以下故障恢复方法:
¡ 方法一:通过8.1.2 1. 单机故障恢复和8.1.2 2. 集群故障恢复。
¡ 方法二:
- 卸载所有节点的Matrix软件包。
- 重新安装Matrix软件包。
- 登录页面,根据Matrix备份文件进行集群恢复,并进行重新安装应用再配置恢复,具体步骤请参考《统一数字底盘部署指导》的“备份恢复”章节。
出现上述ETCD服务启动失败场景。
(1) 登录节点服务器,通过systemctl status etcd查看节点的ETCD服务状态,running为正常状态。若为不正常状态,可根据下列步骤进行故障恢复。
[root@master1 ~]# systemctl status etcd
(2) root用户通过systemctl stop matrix停止节点上Matrix服务。
[root@master1 ~]# systemctl stop matrix
非root用户通过sudo /bin/bash -c "systemctl stop matrix"停止节点上Matrix服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl stop matrix"
(3) 通过mv /etc/kubernetes/manifests/kube-apiserver.yaml /opt/matrix停止kube-apiserver
[root@master1 ~]# mv /etc/kubernetes/manifests/kube-apiserver.yaml /opt/matrix
(4) root用户通过systemctl stop etcd完全停止etcd服务,并且通过命令rm -rf /var/lib/etcd/default.etcd/删除etcd数据目录,确保/var/lib/etcd下面没有数据目录
[root@master1 ~]# systemctl stop etcd
[root@master1 ~]# rm -rf /var/lib/etcd/default.etcd/
[root@master1 ~]# ll /var/lib/etcd/
非root用户通过sudo /bin/bash -c "systemctl stop etcd"完全停止etcd服务,并且通过命令sudo /bin/bash -c "rm -rf /var/lib/etcd/default.etcd/"删除etcd数据目录,确保/var/lib/etcd下面没有数据目录
[admin@node4 ~]$ sudo /bin/bash -c "systemctl stop etcd"
[admin@node4 ~]$ sudo /bin/bash -c "rm -rf /var/lib/etcd/default.etcd/"
[admin@node4 ~]$ ll /var/lib/etcd/
[root@master1 ~]# cd /opt/matrix/k8s/disaster-recovery/
(6) 执行etcd恢复脚本前,在etcd备份目录/opt/matrix/backup/etcd_backup_snapshot/选择最新的备份数据文件,脚本会校验etcd备份目录是否存在备份文件,否则会报错。
root用户执行恢复操作命令如下
[root@master1 ~]# bash etcd_restore.sh Etcd_Snapshot_V900R001B06D012_20210805091547.db
2021-08-06 03:16:19.500144 I | mvcc: restore compact to 109069
2021-08-06 03:16:19.506086 I | etcdserver/membership: added member 91651d28c8465c86 [http://10.99.212.125:2380] to cluster db6c09f0e7b9702b
非root用户执行恢复操作命令如下
[admin@node4 ~]$ sudo bash etcd_restore.sh Etcd_Snapshot_V900R001B06D012_20210805091547.db
2021-08-06 03:16:19.500144 I | mvcc: restore compact to 109069
2021-08-06 03:16:19.506086 I | etcdserver/membership: added member 91651d28c8465c86 [http://10.99.212.125:2380] to cluster db6c09f0e7b9702b
(7) root用户通过systemctl restart etcd重启etcd服务
[root@master1 ~]# systemctl restart etcd
非root用户通过sudo /bin/bash -c "systemctl restart etcd"重启etcd服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl restart etcd"
(8) root用户通过systemctl restart matrix重启matrix服务
[root@master1 ~]# systemctl restart matrix
非root用户通过sudo /bin/bash -c "systemctl restart matrix"重启matrix服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl restart matrix"
(9) 恢复kube-apiserver
[root@master1 ~]# mv /opt/matrix/kube-apiserver.yaml /etc/kubernetes/manifests/
(1) 使用北向业务虚IP登录Matrix平台的GUI界面。
(2) 点击“部署”页签,在弹出的菜单中选择“集群”,进入集群部署页面。
图8-1 1个Master节点正常状态
(3) 点击“监控”页签,在弹出的菜单中选择“Pods”,进入监控Pods页面。
图8-2 Pods中所有Pod都处于Running状态
集群中三个节点都出现上述ETCD服务启动失败场景。
· 1个节点出现ETCD服务启动失败,请使用重建方式恢复节点
· 2个节点出现ETCD服务启动失败,请登录剩下那台ETCD服务正常节点,使用紧急模式重建恢复其他两个节点
(1) 登录所有Master节点服务器,通过systemctl status etcd查看节点的ETCD服务状态,running为正常状态。若为不正常状态,可根据下列步骤进行故障恢复。
[root@master2 ~]# systemctl status etcd
(2) root用户通过systemctl stop matrix停止所有Master节点上Matrix服务。
[root@master2 ~]# systemctl stop matrix
非root用户通过sudo /bin/bash -c "systemctl stop matrix"停止节点上Matrix服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl stop matrix"
(3) 停所有Master节点的kube-apiserver,通过mv /etc/kubernetes/manifests/kube-apiserver.yaml /opt/matrix停止kube-apiserver
[root@master2 ~]# mv /etc/kubernetes/manifests/kube-apiserver.yaml /opt/matrix
(4) root用户通过systemctl stop etcd完全停止所有Master节点上etcd服务,并且通过命令rm -rf /var/lib/etcd/default.etcd/删除etcd数据目录,确保/var/lib/etcd下面没有数据目录
[root@master2 ~]# systemctl stop etcd
[root@master2 ~]# rm -rf /var/lib/etcd/default.etcd/
[root@master2 ~]# ll /var/lib/etcd/
非root用户通过sudo /bin/bash -c "systemctl stop etcd"完全停止etcd服务,并且通过命令sudo /bin/bash -c "rm -rf /var/lib/etcd/default.etcd/"删除etcd数据目录,确保/var/lib/etcd下面没有数据目录
[admin@node4 ~]$ sudo /bin/bash -c "systemctl stop etcd"
[admin@node4 ~]$ sudo /bin/bash -c "rm -rf /var/lib/etcd/default.etcd/"
[admin@node4 ~]$ ll /var/lib/etcd/
(5) 进入ETCD恢复脚本目录。
[root@master1 ~]# cd /opt/matrix/k8s/disaster-recovery/
(6) 在所有Master节点执行etcd恢复脚本前,在etcd备份目录/opt/matrix/backup/etcd_backup_snapshot/选择最新的备份数据文件,脚本会校验etcd备份目录是否存在备份文件,否则会报错。所有节点请使用相同备份数据文件,保持备份恢复数据一致,如果节点没有文件,可从其他节点拷贝etcd备份文件到节点。
root用户执行恢复操作命令如下
[root@master2 ~]# bash etcd_restore.sh Etcd_Snapshot_V900R001B06D012_20210805091653.db
2021-08-06 06:33:14.788657 I | mvcc: restore compact to 273930
2021-08-06 06:33:14.802137 I | etcdserver/membership: added member 312131d4535cc53f [http://10.99.212.124:2380] to cluster cd6d5adc1bfd16f5
2021-08-06 06:33:14.802189 I | etcdserver/membership: added member 5fc2f82d74297956 [http://10.99.212.123:2380] to cluster cd6d5adc1bfd16f5
2021-08-06 06:33:14.802206 I | etcdserver/membership: added member ad12c65048f444bd [http://10.99.212.120:2380] to cluster cd6d5adc1bfd16f5
非root用户执行恢复操作命令如下
[admin@node4 ~]$ sudo bash etcd_restore.sh Etcd_Snapshot_V900R001B06D012_20210805014548.db
2021-08-06 01:22:10.876952 I | mvcc: restore compact to 12660679
2021-08-06 01:22:10.906116 I | etcdserver/membership: added member ac2cefc4cae84e25 [http://[2000::100:2000]:2380] to cluster ced7b5d5ee633b40
2021-08-06 01:22:10.906174 I | etcdserver/membership: added member b4689a44b8c1f191 [http://[2000::100:2001]:2380] to cluster ced7b5d5ee633b40
2021-08-06 01:22:10.906197 I | etcdserver/membership: added member c328a554c1ca84f4 [http://[2000::100:2002]:2380] to cluster ced7b5d5ee633b40
(7) 在上述所有操作完成后,然后在所有Master节点依次root用户通过systemctl restart etcd重启etcd服务
[root@master2 ~]# systemctl restart etcd
非root用户通过sudo /bin/bash -c "systemctl restart etcd"重启etcd服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl restart etcd"
(8) 在所有Master节点依次root用户通过systemctl restart matrix重启matrix服务
[root@master2 ~]# systemctl restart matrix
非root用户通过sudo /bin/bash -c "systemctl restart matrix"重启matrix服务
[admin@node4 ~]$ sudo /bin/bash -c "systemctl restart matrix"
(9) 在所有Master节点依次恢复kube-apiserver
[root@master2 ~]# mv /opt/matrix/kube-apiserver.yaml /etc/kubernetes/manifests/
(1) 使用北向业务虚IP登录Matrix平台的GUI界面。
(2) 点击“部署”页签,在弹出的菜单中选择“集群”,进入集群部署页面。
图8-3 三个Master节点+1个Worker节点正常状态
(3) 点击“监控”页签,在弹出的菜单中选择“Pods”,进入监控Pods页面。
图8-4 Pods中所有Pod都处于Running状态
出现如下任意现象,可能是由于ETCD非独立磁盘部署环境,磁盘IO性能差导致的故障现象。可按照相应故障处理步骤进行操作。
现象一:
ETCD客户端如K8s、Matrix等访问ETCD数据库超过800ms,分别登录各Master节点后台,在/var/log/matrix-diag/Matrix/etcd路径下查看etcd.log日志有以下信息:
2020-11-15 12:36:42.013987 W | etcdserver: read-only range request "key:\"/registry/services/specs/default/kubernetes\" " with result "range_response_count:1 size:295" took too long (877.352309ms) to execute
2020-11-15 12:36:54.026221 W | etcdserver: read-only range request "key:\"/registry/pods/base-service/\" range_end:\"/registry/pods/base-service0\" " with result "range_response_count:42 size:107232" took too long (1.767232614s) to execute)
…
现象二:
ETCD集群频繁主备切换,可能是由于ETCD集群因心跳超时导致。
(1) 若上述现象出现在应用安装升级、配置下发等操作过程,并导致操作失败的情况,则可以尝试再次进行安装升级、配置下发操作进行恢复(由于首次操作已完成部分数据同步,再次操作对磁盘IO影响减弱,会提高升级成功的概率)。
(2) 若上述现象出现稳态运行过程,则可以通过配置定制文件/opt/matrix/confi/navigator_config.json的主备切换参数"matrixLeaderLeaseDuration"(租约老化时间)和"matrixLeaderRetryPeriod"(租约检测周期)来延迟主备切换超时时间,但修改后也会影响节点故障切换时间。
(3) 如果因磁盘IO差导致无法写入或数据丢失的情况,有几种故障恢复方法:
¡ 方法一:
- 若出现Pod状态或通讯异常,可通过kubectl delete pod -n namespace podName命令删除异常Pod操作,删除后将自动创建Pod恢复ETCD数据资源。
¡ 方法二:通过8.1.2 1. 单机故障恢复和8.1.2 2. 集群故障恢复。
¡ 方法三:
- 卸载所有节点的Matrix软件包。
- 重新安装Matrix软件包。
- 登录页面,根据Matrix备份文件进行集群恢复,并进行重新安装应用再配置恢复,具体步骤请参考《统一数字底盘部署指导》的“备份恢复”章节。
执行docker ps、docker images、docker inspect、docker rmi等命令后,长时间无响应。
(1) 重启Docker服务。
¡ root用户执行如下命令重启Docker服务。
[root@master1 ~]# systemctl restart docker
¡ 非root用户执行如下命令重启Docker服务。
[admin@master1 ~]$ sudo /bin/bash -c "systemctl restart docker"
(2) 验证Docker服务是否已恢复正常。
¡ root用户执行docker images命令查看Docker服务。
¡ 非root用户执行sudo /bin/bash -c " docker images "命令查看Docker服务。
(3) 若回显结果中存在当前节点的镜像信息,则表示Docker恢复正常。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器下电后重启,如果出现如下任意现象,均是由节点下电导致的问题。
· /usr/lib/systemd/system目录下chronyd.service、docker.service、containerd.service文件内容丢失。
· /etc/下chrony.conf、docker、etcd、hosts、ssh配置文件内容丢失。
· /var/log下的日志文件或其中的内容丢失。
· chronyd.service、docker.service、containerd.service的内容丢失故障处理步骤
a. 通过ls /usr/lib/systemd/system/service-name.service命令查看所有节点上的service文件是否存在或内容是否为空。
b. 若某些节点上存在该文件且内容正常,可通过scp命令将该文件拷贝到丢失该文件或文件内容为空的节点上。
c. 若所有节点上都不存在该文件,请联系技术工程师或重新安装操作系统。
· /etc/和/var/log下的文件或其中的内容丢失故障处理步骤
由于各节点的文件内容不一致,自行修改可能存在问题,请联系技术工程师处理或重新安装操作系统。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器下电后重启或网络异常断开,如果出现如下任意现象,均是由节点下电导致的问题。
· etcd、matrix等服务的service文件或其中的内容丢失。
· /opt/matrix/下的配置文件或其中的内容丢失。配置文件如定制化配置文件navigator_config.json。
· /opt/matrix/下的脚本文件或其中的内容丢失。脚本文件如docker.sh。
· /var/lib/docker下的Docker镜像文件损坏,如:
现象1:部分pod处于ImagePullBackOff状态,describe pod看事件日志,提示错误如下:
error creating overlay mount to /var/lib/ /overlay2/698028ac124c9d0ef831f7d2d9506acd01faddaae6ea06a0a169fb352e0eddf4/merged: too many levels of symbolic links
现象2:time="2021-05-10T18:05:50.518918884+08:00" level=error msg="Handler for GET /containers/2494c1172314e37bd8250be06a24e0636b7427f89b3b5a5398ecfad7c2fe171d/json returned error: readlink /var/lib/docker/overlay2/l: invalid argument" 。
· /opt/matrix/下的Yaml文件或文件中的内容丢失。
· service文件或其中的内容丢失、/opt/matrix/下的文件或其中的内容丢失故障处理步骤
a. 通过ls命令查看所有节点上的相关文件是否存在或其中的内容是否为空。
b. 若某些节点上存在该文件且内容正常,可通过scp命令将该文件拷贝到丢失该文件的节点上。
c. 若所有节点上都不存在该文件,请联系技术工程师或重新安装操作系统。
· /var/lib/docker下的Docker镜像文件损坏
¡ 请通过上传Matrix版本包的方式重建节点。
¡ 联系技术工程师处理。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器重启,出现如下现象:
· 若Matrix相关Pod异常,页面中节点可能会飘红或飘黄。
· 若产品相关Pod异常,在[监控>Pods]页面下存在CreateContainerError状态的Pod。
登录任一Master节点后台,使用kubectl get pod -A -owide | grep CreateContainerError命令可以查看所有处于CreateContainerError状态的Pod。
[root@node1 home]# kubectl get pod -A -owide | grep CreateContainerError
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system calico-kube-controllers-cd96b6c89-hfz7s 0/1 CreateContainerError 0 29d 10.99.212.164 node1 <none> <none>
方法一:
(1) 登录异常Pod所在节点,使用docker ps | grep podname | grep -v POD | grep Up|awk '{print $1}'命令获取其处于UP状态容器ID。其中,podname为异常Pod的名称。
[root@node1 home]# docker ps |grep calico-kube-controllers-cd96b6c89-hfz7s | grep -v POD|grep Up|awk '{print $1}'
c755b7812380
(2) 执行docker stop containerid && docker rm containerid命令删除该UP状态的容器。其中,containerid为容器ID。例如,docker stop c755b7812380 && docker rm c755b7812380。
(3) 删除成功后,使用kubectl get pod -A -owide | grep CreateContainerError命令查询是否依然存在处于CreateContainerError状态的Pod,若依然存在,则需登录Matrix页面重建该节点。
方法二:
登录Matrix页面重建异常Pod所在节点。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器重启,出现如下现象:
· 若Matrix相关Pod异常,页面中节点可能会飘红或飘黄。
· 若产品相关Pod异常,在[监控>Pods]页面下存在Error状态的Pod。
登录任一Master节点后台,使用kubectl get pod -A -owide | grep -w Error命令查看所有处于Error状态的Pod。
登录异常Pod所在节点后台,使用cat /var/log/matrix-diag/Matrix/kubelet/kubelet.log | grep "unexpected end of JSON input"
命令查看该节点的kubelet日志,若出现如下报错信息,则该问题的原因为:重启节点导致Pod数据损坏,Pod无法正常启动。
Multus: failed to load netconf: unexpected end of JSON input
方法一(当异常Pod较少时可以使用该方法):
(1) 登录任一Master节点后台,使用kubectl get pod -A -owide | grep -w Error命令查看Error状态Pod的命名空间和名称。
(2) 执行kubectl delete pod -n namespace podName命令删除异常Pod。其中namespace为上一步查询出的异常Pod的命名空间,podName为异常Pod的名称。
说明:该命令用于删除指定节点上某个异常Pod,包括Error、CreateContainerError等异常状态,当存在多个异常Pod时,需多次执行该命令。
方法二(当异常Pod较多时可以使用该方法):
登录任一Master节点后台,执行kubectl get pod -A -owide | grep -w Error| awk '{print $1 " " $2}'| xargs kubectl delete pod -n命令。
说明:该命令用于批量删除所有处于异常状态的Pod。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器重启,出现如下现象:
· Matrix存在节点飘黄,点击查看节点详情,显示grafana组件健康状态异常。
· 登录飘黄节点后台,使用kubectl get pod -n kube-system -o wide | grep grafana 命令查看Pod状态,显示存在Grafana Pod处于CrashLoopBackOff状态。
· 登录飘黄节点后台,使用ll /opt/matrix/k8s/conf/grafana 命令查看Grafana配置文件夹下文件数量,显示为total 0。
故障由服务器断电重启导致grafana配置文件丢失导致,需要重新生成配置文件,登录飘黄节点后台执行恢复操作步骤如下:
· 执行 sh /opt/matrix/k8s/monitor/preInstallGrafana.sh 命令重新生成配置文件。
· 执行kubectl delete pod -n kube-system grafana-xxx 命令删除并重启处于CrashLoopBackOff状态的Pod。
注意:请确保集群所有节点的Grafana配置文件夹下配置文件存在。
集群部署失败,单击节点右上角按钮,选择[日志]菜单项查看节点日志,提示K8SINSTALL-ERROR。
造成故障的原因:
节点存在两个及以上网卡且都为UP状态,但其中一张网卡未配置IP地址。
当操作系统中arp_ignore参数设置为0(默认值)时,系统会响应任意网卡上接收到的对本机IP地址的ARP请求(包括环回网卡上的地址)。此时,Matrix节点间通信时可能会将无IP地址但状态UP的网卡MAC作为ARP应答消息进行返回,进而导致集群节点间因网络不通出现部署失败。
故障排查及处理步骤:
(1) 若业务场景需要多张网卡,在部署/升级/重建集群前,请通过ifconfig命令查看网卡的排序,在Matrix集群使用的节点IP所在网卡前的所有物理网卡均已配置IP地址或配置为ONBOOT=no,否则会导致集群部署失败。例如,网卡排序为:ens190>ens191,若节点IP所在网卡为ens191,则需确保ens190也已配置IP地址。
(2) 集群中不应存在未接线但配置文件中ONBOOT=yes,未配置IP地址且ONBOOT=yes等异常配置。
(3) 如果集群采用bond作为Matrix主网卡,请确保在Matrix集群中的所有非bond成员的物理网卡均已配置IP地址或者配置为ONBOOT=no.
(4) 修改网卡配置后,需重启网络服务。
统一数字底盘部署失败,日志显示由于某一个节点上执行kubectl exec命令失败(命令执行回显error报错)导致创建gfs卷不成功。登录节点后台执行kubectl exec -it pod bash命令发现该节点上的所有Pod都无法进入。
(1) 登录无法执行kubectl exec命令的节点后台。
(2) 执行systemctl restart kubelet.service命令重启该节点上的kubelet服务即可。
IPv6环境下,在其中一个节点上增加一张新网卡,并配置IP地址或者在现有网卡上增加新IP地址,由于其它节点的IP地址和新IP地址不在同一网段,导致重建、升级等操作失败。在增加新IP的节点后台执行ping6 pod_ip命令,提示无法ping通。其中pod_ip为容器IP地址,可以使用kubectl get pod -n kube-system -o wide命令查询。
在节点上增加新IP后由于该IP地址和其他节点的IP地址不在同一网段,集群无法正常建立,最终导致重建、升级等操作失败。
故障处理步骤:
· 将新增的不同网段的IP地址修改为和其他节点同一网段的IP地址。
· 在其它节点上配置路由策略,使节点间可以正常通信。
统一数字底盘页面无法访问。
查看ETCD日志,存在如下提示:
context deadline exceeded、waiting for ReadIndex response took too long, retrying,
查看apiserver日志,存在如下提示:
stopped listening on [::]:6443
造成故障的原因:由于ETCD IO延迟,导致API Server多次从ETCD获取数据失败,从而停止监听6443端口。组件通过6443端口调用K8s API失败。
故障处理步骤:
(1) 测试磁盘IO性能:若磁盘IO性能均值在10000及以上,则磁盘性能达标;若IO性能均值在10000以下,则磁盘存在性能问题,ETCD处理请求将会缓慢,请提高磁盘IO性能。
测试磁盘IO性能方法:
¡ Root用户:执行bash /opt/matrix/tools/env_check.sh –p命令。
¡ 非Root用户:执行sudo bash /opt/matrix/tools/env_check.sh -p命令。
(2) 执行kubectl get pod -n service-software | grep stolon-keeper命令查询所有stolon-keeper Pod的名称。
(3) 执行kubectl delete pod -n service-software pod_name命令依次重启stolon-keeper Pod。
(4) stolon-keeper Pod恢复Running状态后重新访问统一数字底盘页面。
在宿主机或业务容器中的挂载GFS目录(查看业务容器yaml配置的主机映射目录)里执行ls -l命令,在查看挂载目录时出现“???”的文件,且该文件无法访问。
造成故障的原因:由于GlusterFS存储卷三副本的节点上所剩余的磁盘空间不一致,导致在写入数据后,三副本内数据不一致,出现Glusterfs存储卷数据文件脑裂。
故障处理步骤如下:
(1) 通过命令kubectl get po -A |grep glusterfs查询GlusterFS组件相关Pod的名称及其所在的命名空间。
(2) 通过命令kubectl exec进入GlusterFS容器,再使用命令`gluster volume heal VolumeName info`查看输出信息中是否包含Is in split-brain的字样,然后记录其对应的文件路径,其中,VolumeName为故障的存储卷名,存储卷名可通过kubectl exec –it {gfs pod命名空间+gfs pod名称} - gluster volume list | grep {业务数据卷名称} 命令查询。
(3) 推荐如下两种策略解决该故障:
¡ 一种是根据文件大小,以大文件为准,使用命令gluster volume heal VOLNAME split-brain bigger-file filepath解决。其中,VOLNAME为存储卷名称,filepath为文件全路径。
¡ 一种是根据更新时间,以最新文件为准,使用命令gluster volume heal VOLNAME split-brain latest-mtime filepath解决。其中,VOLNAME为存储卷名称,filepath为文件全路径。
(4) 更多恢复流程请查看GlusterFS官网中glusterfs存储卷数据文件脑裂恢复方式。
https://docs.gluster.org/en/latest/Troubleshooting/resolving-splitbrain/
查看Matrix日志,有如下提示,GlusterFS组件使用的磁盘或磁盘分区内存在其他数据。
Device include vg , nodename:node1, device:/dev/vda3
造成故障的原因:GlusterFS组件的heketi需要空白磁盘或空白磁盘分区,但是GlusterFS组件使用的磁盘或磁盘分区内存在其他数据,导致GlusterFS组件部署失败,需要用户手动清空磁盘。
故障处理步骤如下:
(1) 进入清理磁盘脚本的存放路径。
[root@m2 ~]# cd /opt/matrix/app/install/metadata/gluster/gluster/scripts/tools/
(2) 使用命令bash clearDisk.sh disks执行该脚本,其中disks为需要清空的磁盘,需要注意的是,disk必须带双引号,且如果清除多个磁盘或磁盘分区需要以空格隔开,例如,bash clearDisk.sh “/dev/vdb /dev/vdc”。
[root@m2 ~]# bash clearDisk.sh "/dev/vdb /dev/vdc"
[clear_disk] CAUTION: Please confirm whether to erase the disk /dev/vdb /dev/vdc
Continue anyway? (Y/N) : y
[clear_disk] CAUTION: Please confirm whether to clear glusterfs config file
Continue anyway? (Y/N) : y
[clear_disk] Disk erase complete.
清除磁盘有风险,请仔细确认要删除的磁盘或磁盘分区。
(3) 在所有Master节点执行完脚本后,重新部署GlusterFS组件。
使用GlusterFS存储的组件安装失败。查看Matrix日志,出现安装脚本调用volume.sh脚本时,无法删除储存卷的问题。将删除储存卷的命令单独在主用Master节点所在服务器上执行,依然报错,无法删除存储卷。
造成故障的原因:安装使用GlusterFS存储的组件时,组件安装脚本会调用GlusterFS heketi命令,对GlusterFS存储卷进行先删除再创建的操作。由于开源问题,删除存储卷时提示如下错误:存储卷被mount使用。查询操作系统mount信息,存储卷并未发现mount信息,使得存储卷删除失败,最终导致组件安装失败。
故障处理步骤如下:
(1) 依次登录各节点后台,重启节点所在服务器。建议先重启备用Master节点,再重启主用Master节点。
(2) 等待集群恢复正常。集群恢复正常后重新部署使用GlusterFS存储的组件。
(1) 使用GlusterFS存储的组件升级失败,登录节点后台,查看Matrix日志。日志显示使用GlusterFS存储的组件多次升级失败。
(2) 登录任一Master节点后台,使用kubectl get po -A -owide | grep glusterfs命令查看所有处于Running状态的GlusterFS Pod的名称。
[root@matrix ~]# kubectl get po -A -owide | grep glusterfs
glusterfs-example glusterfs-l6fcr 1/1 Running 0 3d23h 10.99.212.200 matrix <none> <none>
glusterfs-example heketi-848f8f7dd6-nc2kq 1/1 Running 0 3d23h 177.177.95.77 matrix <none> <none>
glusterfs-example monitor-84964d7cd7-2wjrr 1/1 Running 0 3d23h 177.177.95.78 matrix <none> <none>
(3) 使用kubectl exec -it -n glusterfs-example glusterfs-l6fcr /bin/bash命令进入GlusterFS pod的容器。
(4) 使用ps -aux | grep /usr/sbin/glusterd | grep -v grep命令,发现glusterd进程不存在。
造成故障的原因:升级使用GlusterFS存储的组件时,概率出现GlusterFS Pod中glusterd进程异常退出,导致组件升级执行存储相关脚本失败。
故障处理步骤如下:
(1) 使用kubectl get po -A -owide | grep glusterfs命令,查看所有处于GlusterFS Pod的名称。例如,GlusterFS Pod的名称为glusterfs-l6fcr。
(2) 使用kubectl exec -it -n glusterfs-example glusterfs-l6fcr /bin/bash命令进入GlusterFS Pod的容器。
(3) 执行systemctl restart glusterd命令重新拉起glusterd进程。
(4) 使用ps -aux | grep /usr/sbin/glusterd | grep -v grep命令查看glusterd进程是否被拉起。
(5) glusterd进程启动后,重新升级使用GlusterFS存储的组件。
通过重新安装ISO的方式重建节点,但是重建节点上通过lsblk命令查询不到GFS的相关数据,创建卷等操作失败。
造成故障的原因:GlusterFS组件的heketi需要空白磁盘或空白磁盘分区,但是GlusterFS组件使用的磁盘或磁盘分区内存在其他数据,导致GlusterFS组件的数据不能同步到重建节点上,需要用户手动清空磁盘;GFS的分区号与重建前节点的分区号不一致。
故障处理步骤如下:
· 针对GlusterFS组件使用的磁盘或磁盘分区内存在其他数据的情况请参考如下内容:
(1) 进入清理磁盘脚本的存放路径。
[root@m2 ~]# cd /opt/matrix/app/install/metadata/gluster/gluster/scripts/tools/
(2) 使用命令bash clearDisk.sh disks执行该脚本,其中disks为需要清空的磁盘,需要注意的是,disk必须带双引号,且如果清除多个磁盘或磁盘分区需要以空格隔开,例如,bash clearDisk.sh “/dev/vdb /dev/vdc”。
[root@m2 ~]# bash clearDisk.sh "/dev/vdb /dev/vdc"
[clear_disk] CAUTION: Please confirm whether to erase the disk /dev/vdb /dev/vdc
Continue anyway? (Y/N) : y
[clear_disk] CAUTION: Please confirm whether to clear glusterfs config file
Continue anyway? (Y/N) : y
[clear_disk] Disk erase complete.
清除磁盘有风险,请仔细确认要删除的磁盘或磁盘分区。
(3) 在所有Master节点执行完脚本后,重新重建节点。
· 针对GFS的分区号与重建前节点的分区号不一致的情况请参考如下内容:
(1) 获取重建前GFS的分区信息。
[root@c1 ~]# cat /opt/matrix/app/install/metadata/gluster/gluster/heketi/config/cluster.json
{
"node" : [ {
"nodename" : "c1",
"device" : [ "/dev/vdc" ]
}, {
"nodename" : "c2",
"device" : [ "/dev/vdc" ]
}, {
"nodename" : "c3",
"device" : [ "/dev/vdc" ]
} ]
(2) 根据分区信息对待重建节点重新安装ISO。
· 更多恢复流程请查看GlusterFS官网中glusterfs存储卷数据文件异地复制方式。
https://docs.gluster.org/en/latest/Troubleshooting/troubleshooting-georep/
在Matrix的[部署>集群>集群参数>修改集群参数]页面下,勾选“高级”复选框后,对虚IP进行修改。单击<应用>按钮后虚IP修改失败。查看Matrix日志,存在如下日志报错:
2022-02-16T10:33:52,207 | INFO | DeployResource-11-thread-1 | K8sClientHelper.getConfigMapByName:2120 | [K8sClientHelper] get configmap by name param: namespace kube-system, configmapName kube-proxy
2022-02-16T10:33:52,227 | ERROR | DeployResource-11-thread-1 | DefaultUncaughtExceptionHandler.uncaughtException:18 | uncaught exception in Thread[DeployResource-11-thread-1,5,main], stack: [java.lang.Thread.getStackTrace(Thread.java:1559), com.h3c.matrix.util.DefaultUncaughtExceptionHandler.uncaughtException(DefaultUncaughtExceptionHandler.java:18), java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1057), java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1052), java.lang.Thread.dispatchUncaughtException(Thread.java:1959)]
java.util.ServiceConfigurationError: io.fabric8.kubernetes.api.KubernetesResourceMappingProvider: Provider io.fabric8.kubernetes.internal.InternalResourceMappingProvider not found
由于Fabric8开源问题,获取configmap失败,导致虚IP修改失败。
故障处理步骤:
使用systemctl restart matrix命令重启当前操作节点后,再次进行虚IP修改操作。
· 现象1:Pod处于ImagePullBackOff状态,使用kubectl describe pod -n namespace podName命令查看事件日志,提示如下。其中,namespace和podName为处于该状态Pod的命名空间及名称。
too many levels of symbolic links
· 现象2:Pod处于ImageInspectError状态,使用kubectl describe pod -n namespace podName命令查看事件日志,提示如下。其中,namespace和podName为处于该状态Pod的命名空间及名称。
readlink /var/lib/docker/overlay2/l: invalid argument"
出现上述两种现象,则为镜像损坏的故障。
· 方法一
请依次执行以下命令,删除故障Pod所在节点的所有容器及镜像。
[root@master1 ~]# systemctl restart docker
[root@master1 ~]# docker system prune
[root@master1 ~]# docker rm -f $(docker ps -aq)
[root@master1 ~]# docker rmi -f $(docker images -q)
· 方法二
若使用方式一无法消除该故障,请登录Matrix页面,重建故障Pod所在节点。
服务器下点后重启,应用服务启动失败,运行日志中提示数据库连接异常。或者手工执行数据库登录命令未能成功登录。
数据库正常登录应如下图所示:
(1) 执行如下命令批量删除数据库集群的Pod:
kubectl get pod -n service-software -o wide | grep pxc-node | awk '{print $1}' | xargs kubectl -n service-software delete pod
(2) 执行kubectl logs -f 命令查看数据库容器的启动日志。
¡ 三机或多机环境下当日志最后出现“all pxc node start up.”说明数据库集群修复完毕。
¡ 单机环境下当日志中出现“mysql state is Synced”即可说明数据库修复完毕。
三机或多机环境下,服务器下电并重启,PXC数据库无法正常运行,关联数据库的业务Pod启动异常,重启PXC数据库的Pod依旧无效。
(1) 执行kubectl logs -f命令查看各PXC数据库容器的启动日志,观察哪个容器提示Starting MySQL (Percona XtraDB Cluster) database server 失败。
(2) 停止启动失败的pxc-node容器,执行命令:
kubectl delete -f /opt/matrix/app/install/metadata/UCENTER/portal/portal/common/k8s-resources/pxc-node{1/2/3}.yaml
(3) 清除已损坏容器的持久化目录,pxc-noe1、pxc-node2以及pxc-node3分别绑定了Matrix 的master1、master2以及master3节点,其持久化目录为/var/lib/ssdata/pxc/pxc/{1/2/3},执行rm命令清空此目录:rm -rf /var/lib/ssdata/pxc/pxc/{1/2/3}/
建议:建议先将持久化目录下的文件转移到其他路径下,待修复成功后再将其删除。
(4) 重启停止的pxc-node容器,执行命令:
kubectl apply -f /opt/matrix/app/install/metadata/UCENTER/portal/portal/common/k8s-resources/pxc-node{1/2/3}.yaml
(5) 执行kubectl logs -f 命令查看数据库容器的启动日志,三机或多机环境下当日志最后出现“all pxc node start up.”说明数据库集群修复完毕。
场景一:
关联数据库的业务能正常连接数据库,但无法正常使用数据库,例如可能会收到类似“WSREP has not yet prepared node for application use”的响应。
场景二:
关联数据库的业务能正常连接数据库,但无法正常使用数据库,日志中可能会收到等待锁超需要重新尝试提交事务的响应。
场景三:
关联数据库的业务能正常连接数据库,但无法正常使用数据库,数据库无响应。
· 场景一的故障原因:
可能由于数据库集群脑裂导致,大部分情况下数据库集群可以自愈,可通过登录数据库查看wsrep_local_state_comment、wsrep_ready以及wsrep_incoming_addresses确认
数据库正常情况下查询结果应如截图所示:
若查询的结果与此不同,比如wsrep_local_state_comment的结果是Initialized或是Joining: receiving State Transfer;或者查询wsrep_ready的结果是OFF,则说明登录的这个pxc-node不可用。若wsrep_incoming_addresses未包含所有的pxc-node的IP,则说明所有的pxc-node容器未在一个数据库集群中。出现以上情况可以通过重启pxc-node容器解决。
· 场景二的故障原因:
数据库中出现了死锁,可能是元数据锁metadata lock,也可能是排它锁。
· 场景二的故障原因:
一般是数据库集群数据一致性过程收到阻碍导致。出现以上情况也可以通过重启pxc-node容器解决。
可通过重启pxc-node解决该故障,具体步骤如下:
(1) 执行如下命令批量删除数据库集群的Pod:
kubectl get pod -n service-software -o wide | grep pxc-node | awk '{print $1}' | xargs kubectl -n service-software delete pod
(2) 执行kubectl logs -f 命令查看数据库容器的启动日志。
· 三机或多机环境下当日志最后出现“all pxc node start up.”说明数据库集群修复完毕。
· 单机环境下当日志中出现“mysql state is Synced” 即可说明数据库修复完毕。
单机环境下,服务器突然下电,重启服务器后PXC数据库无法正常启动,导致依赖PXC数据库的业务Pod启动异常。重启PXC数据库的Pod依旧无效。
故障现象:
· 登录节点后台,查看PXC的grastate.dat文件内容,发现该文件内容为空,文件内容丢失。
· 数据库无法连接。
· 使用数据库服务的业务Pod异常:
· PXC Pod日志打印如下错误:
(1) 执行如下命令,停止启动失败的pxc-node1容器。
kubectl delete -f /opt/matrix/app/install/metadata/UCENTER/portal/portal/common/k8s-resources/pxc-node1.yaml
(2) 执行vim grastate.dat命令,在文件中增加如下内容,并保存。
# GALERA saved state
version: 2.1
uuid: 2013b697-a063-11ed-b00e-d340082886cf
seqno: -1
safe_to_bootstrap: 1
图19-1 查看grastate.dat文件内容
(3) 执行如下命令,重启停止的pxc-node1容器。
kubectl apply -f /opt/matrix/app/install/metadata/UCENTER/portal/portal/common/k8s-resources/pxc-node1.yaml
(4) 执行kubectl logs -f 命令查看数据库容器的启动日志,单机环境下当日志最后出现“mysql state is Synced”说明数据库修复完毕,测试数据库连接正常。