手册下载
H3C 统一数字底盘故障处理手册-E07xx-5W105-整本手册.pdf (2.44 MB)
故障处理手册
资料版本:5W105-20240228
Copyright © 2024 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文档中的信息可能变动,恕不另行通知。
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
3.8 系统节点长时间断电或异常致其他节点PostgreSQL数据目录占用大量磁盘空间
3.9 灾备环境主站点网络断开一段时间再恢复后,主站点中的部分节点状态为NotReady、大量Pod异常
4.1 安全策略配置为全部拒绝后,集群拒绝所有访问Matrix服务的请求
5.1 admin用户输入错误的密码导致登录Matrix失败
5.2 除admin之外的其他用户输入错误的密码导致登录Matrix失败
7.2 在ETCD非独立磁盘部署环境下,出现客户端请求超时或ETCD集群主备切换频繁
9.2 节点所在服务器下电后重启或网络异常断开,Matrix依赖的文件丢失
9.3 节点所在服务器下电后重启,页面中节点飘红、飘黄或监控页面Pod处于CreateContainerError状态
9.4 节点所在服务器下电后重启,页面中节点飘红、飘黄或监控页面Pod处于异常状态
9.5 节点所在服务器下电后重启,prometheus数据文件损坏导致Pod状态异常
9.6 节点服务器断电重启,MACVLAN附加网络IPv6网卡不可用
9.7 节点所在服务器下电后重启,使用附加网络的Pod反复重启
10.1 集群部署失败,查看日志出现错误K8SINSTALL-ERROR
11.1 统一数字底盘部署失败,查看日志显示kubectl exec命令执行失败
12.1 IPv6环境下,节点或现有网卡增加IP后,集群部署失败
14 重启节点或网络变动后,出现部分使用GlusterFS存储的Pod异常
15 卸载/重建Matrix后再次部署GlusterFS应用失败
15.1 GlusterFS组件使用的磁盘或磁盘分区内存在其他数据,导致GlusterFS组件部署失败
15.2 存储卷删除失败,导致使用GlusterFS存储的组件安装失败
15.3 glusterd进程退出,导致使用GlusterFS存储的组件升级失败
15.4 通过ISO方式重建Matrix后GlusterFS服务异常
18 服务器下电重启、网络异常断开或者单机扩集群,出现使用PXC数据库的Pod异常
18.4 PXC数据库启动文件grastate.dat内容全部丢失
19.2 异常断电导致三个节点的ZooKeeper数据无法同步
19.3 异常断电导致PXC数据库启动需要用到的磁盘文件内容全部丢失
19.4 服务器异常断电后XFS文件和Vertica数据库损坏
19.6 掉电导致var/lib/docker系统文件损坏,docker服务status异常
19.7 重启后概率出现ZooKeeper数据不同步,导致Kafka无法启动
19.8 强制断电,导致服务器重启后操作系统XFS分区损坏,系统异常
20.1 统一数字底盘升级后,k-eureka Pod等异常,处于Pending状态
21.1 主备断连后,在主站点上删除灾备系统,导致备站点上配置残留
21.2 升主降备过程中,主备之间网络异常,导致降备站点无法访问
21.3 自动倒换模式下出现备用站点接管成功,主用站点无法自动降备
22 服务器下电重启、Pod重启、网络异常断开,出现Kafka异常
本文档介绍统一数字底盘常见故障的诊断及处理措施。
当出现故障时,请尽可能全面、详细地记录现场信息(包括但不限于以下内容),收集信息越全面、越详细,越有利于故障的快速定位。
· 记录您所使用的统一数字底盘版本、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节点异常(节点飘红)。
以下问题全部存在时,即可通过该章节进行故障处理。
· 后台执行 export ETCDCTL_API=2 && etcdctl cluster-health命令短暂性或持续性返回其中一个或多个member unhealthy状态。该故障多见于集群中一个或多个节点网络延迟大(延迟10ms以上)或性能不足(CPU频率低、磁盘IO负载高、IOPS性能低等)。
· 执行 kubectl get endpoints -nservice-software itom-central-login-svc 命令查看itom-central-login 服务对应的endpoints。若endpoints 依然保留异常节点上Pod IP 地址,则视为异常。
图3-1 查看itom-central-login服务对应的endpoints
(1) 找到异常节点:在三台Master节点后台执行curl http://localhost:2379/health命令,若只有1~2个节点命令返回{"health":"false","reason":"xxx"}、则认为该节点异常,若三个节点均返回{"health":"false","reason":"xxx"}、则认为ETCD集群主节点异常。
ETCD集群主节点查询方式:
a. 执行 export ETCDCTL_API=2 && etcdctl member list 命令查询成员列表,isLeader=true的为ETCD集群的主节点,如下matrix-node1为主节点。
[root@name3 tools]# etcdctl member list
2fb4df4b48851734: name=etcd2 peerURLs=http://matrix-node2:2380 clientURLs=http://matrix-node2:2379 isLeader=false
36bce94b1f1c6222: name=etcd3 peerURLs=http://matrix-node3:2380 clientURLs=http://matrix-node3:2379 isLeader=false
c7366883276d5740: name=etcd3 peerURLs=http://matrix-node1:2380 clientURLs=http://matrix-node1:2379 isLeader=true
b. 执行cat /etc/hosts 看节点IP域名映射关系,找到 a)中matrix-node1对应的节点IP,如下ETCD主节点IP为10.99.212.83。
[root@name3 tools]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 name3
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 name3
10.99.212.83 matrix-apiserver
10.99.212.83 matrix-registry.h3c.com
10.99.212.83 etcd.matrix
10.99.212.87 matrix-node2
10.99.212.84 matrix-node3
10.99.212.83 matrix-node1
若集群中只有一个节点异常,则进行后续故障恢复,若集群中有2个及以上节点异常,请勿使用该故障恢复方式进行处理,否则可能导致集群无法恢复。
(2) 登录异常节点后台,执行systemctl stop etcd命令停掉问题节点的ETCD服务。
(3) 登录主节点后台,执行kubectl drain nodeName --ignore-daemonsets --force --delete-emptydir-data --timeout=1800s命令将所有Pod从异常节点上驱逐。其中,nodeName为异常节点的名称。
(4) 执行kubectl delete node nodeName命令删除异常节点。其中,nodeName为异常节点的名称。
(5) 修复异常断联的节点。若是服务器硬件故障无法恢复,必须更换节点服务器进行修复。
(6) 修复节点之后,登录Matrix界面,在[部署>集群]页面下,单击故障节点右上角的按钮,选择[重建]菜单项重建该节点。
(7) 如果上述操作完成后故障仍无法排除,请联系技术支持工程师。
集群中某个节点磁盘空间已满,在该节点主机中使用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]# export ETCDCTL_API=2&&etcdctl cluster-health
member fb58b3b32bac01c is healthy: got healthy result from http:// matrix-node1:2379
member aa6e53b313aa741f is healthy: got healthy result from http:// matrix-node2:2379
member d1fcbe1f6db25390 is healthy: got healthy result from http:// matrix-node3:2379
b. 若主用Master节点的ETCD服务已恢复正常,请将集群网络模式修改为集群原有网络模式,例如上述环境需要改为“单子网”模式,单击应用后将提示修改失败,但是集群参数页面已经显示改为“单子网”模式。
c. 再次将网络模式修改为“多子网”模式,修改成功,即该故障已恢复。
· 第二种情况:页面显示集群网络模式没有修改,且提示“修改失败”。
该种情况的原因为:由于ETCD服务异常导致两次请求都没有成功。
故障处理步骤如下:
a. 进入主用Master节点服务器,查看主用Master节点的ETCD服务是否已经恢复正常。若已恢复正常可继续进行下列操作;若没有恢复正常请联系技术支持工程师。
[root@name1 1.0.0]# export ETCDCTL_API=2&&etcdctl cluster-health
member fb58b3b32bac01c is healthy: got healthy result from http:// matrix-node1:2379
member aa6e53b313aa741f is healthy: got healthy result from http:// matrix-node2:2379
member d1fcbe1f6db25390 is healthy: got healthy result from http:// matrix-node3: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服务即可。
集群环境某节点长时间不启动或节点异常,可能会引起某节点PostgreSQL实例Pod的数据目录占用磁盘空间不断增长。尤其在如果某节点因为宕机或者关闭长期不启动,同时另外两个节点正常提供服务,且PostgreSQL数据库进行大量插入、更新、删除等操作的情况。
PostgreSQL数据库集群因为备库需要从主库不断的同步数据,而同步的数据依赖主库上的wal日志,目前为了数据库集群各备库Pod的正常同步数据,主库虽然开启了wal日志的自动清理,但是也会保留备库一直未同步的wal日志,这样如果一个备库所在节点长时间处于未启动状态,并且当前PostgreSQL数据库不断进行insert、delete、udpate等操作,那么主库所在节点的wal日志目录占用磁盘会不断的增长。如下图所示,wal日志目录大小由原先的97M增长到11G。
如下图所示,wal日志目录大小由原先的97M增长到11G。
本身PostgreSQL主库保留wal日志是为了备库的正常同步数据以及正常运行,所以此时只要启动当前关闭的节点,然后节点正常处于服务状态,同时该节点PostgreSQL 实例Pod正常运行,随着该节点备库Pod不断同步数据,主库会自动清理wal日志,然后所占用磁盘空间会慢慢降下来。如下图所示,wal日志所占用磁盘大小随着宕机节点的重启,逐渐由11G降到657M。
断开灾备环境主站点的网络,等待一段时间后恢复网络,主站点中的部分节点状态持续为NotReady,该节点上大量Pod异常、且无法自行恢复。
异常节点Docker日志中有大量的锁请求和等待,在网络恢复后,主站点恢复过程中,Docker执行Pod的terminating、启动等发生了进程、Pod的互锁,导致节点状态异常。该问题出现概率极低。
在异常节点后台执行systemctl restart docker.service命令重启Docker服务即可。
在安全策略页面,基本设置区域的默认动作设置为“拒绝”且删除规则信息区域的默认规则后,集群拒绝所有访问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
WARNING: Input userName is empty, use default userName "admin".
Password reset to Pwd@123456 for user admin 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
WARNING: Input userName is empty, use default userName "admin".
Password reset to Pwd@123456 for user admin succeeded
b. 脚本执行完成后,使用新密码重新登录Matrix页面即可。
在登录Matrix页面,如果除admin之外的其他用户忘记登录密码等原因导致登录Matrix失败。
请根据集群情况执行对应脚本,进行重置密码的操作。
· 集群运行正常时重置密码。
a. 进入某一个Master节点的脚本存放目录,使用命令bash resetMatrixUserPassword.sh username reset_password执行该脚本,其中resetMatrixUserPassword.sh为脚本名称,username为用户名称,reset_password为新密码,例如:bash resetMatrixUserPassword.sh test Pwd@123456。
[root@node1 ~]# cd /opt/matrix/k8s
[root@name0 k8s]# bash resetMatrixUserPassword.sh test Pwd@12345
Password reset to Pwd@12345 for user test succeeded.
b. 脚本执行完成后,使用新密码重新登录Matrix页面即可。
· 集群紧急模式下重置密码。
a. 请先根据5.1 admin用户输入错误的密码导致登录Matrix失败章节重置admin用户密码并修复集群,待集群恢复正常后再根据该章节内“集群运行正常时重置密码”操作方式重置用户的密码。
在集群中某个节点的命令行界面,使用ifconfig interface_name down和ifconfig interface_name up命令对网卡进行重启后,默认路由丢失。
(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日志(快照日志)文件的最大日志索引值(13d62e)大于wal日志(预写日志)文件的最小日志索引值(d4bf2)。以下图为例。
节点所在服务器下电后重启,若ETCD中wal日志文件的最小日志索引值(e6fac)大于snap日志文件的最大日志索引值(e37fd),ETCD会由于丢失必要的操作日志数据,无法恢复数据,导致文件损坏。以下图为例。
现象三:
节点所在服务器下电后重启,ETCD服务由于数据库snap日志(快照日志)文件丢失而启动失败,最终导致集群异常。查看/var/log/matrix-diag/Matrix/etcd/etcd.log日志有以下信息:
etcdserver: recovering backend from snapshot error: database snapshot file path error: snap: snapshot file doesn't exist
现象四:
ETCD服务由于数据文件损坏而启动失败,导致节点状态异常。登录ETCD服务异常的节点查看日志有以下信息:
"error":"walpb: crc mismatch"
现象五:
集群环境节点重启后ETCD服务正常启动,但是由于某一个或多个节点上的ETCD数据文件损坏导致ETCD集群数据不同步,主要有两种现象:
· 在其中一个Master节点后台执行“watch kubectl get pod -A -owide | grep -v Running”命令,发现多次回显的Pod状态不一致。
· 查看三台Master节点ETCD服务的日志(日志目录:/var/log/matrix-diag/Matrix/etcd/),发现某一个或多个节点上该日志有以下信息:“failed to publish local member to cluster through raft”。存在该日志的节点为db文件损坏、ETCD服务异常节点,故障处理时请处理该异常节点。
登录各节点服务器,通过命令systemctl status etcd查看各节点的ETCD服务状态,running为正常状态。如下图所示。
若为不正常状态,可根据下列步骤进行故障恢复。
[root@node01 ~]# systemctl status etcd
· 如果仅有一个节点的ETCD服务出现上述现象,请登录Matrix界面,在[部署>集群]页面单击出现问题节点右上角的按钮,选择“重建”,可对指定节点进行重建操作,重建完成后故障即可恢复。
· 如果两个节点ETCD服务出现db文件损坏情况,此时Matrix页面会进入紧急模式状态,可通过节点重建方式逐个恢复问题节点。故障描述中的现象五不会进入紧急模式,也可通过节点重建方式逐个恢复问题节点。
· 如果单机环境或者三个节点的ETCD服务出现上述现象,有以下故障恢复方法:
¡ 方法一:通过7.1.2 1. 单机故障恢复和7.1.2 2. 集群故障恢复。
¡ 方法二:
- 卸载所有节点的Matrix软件包。
- 重新安装Matrix软件包。
- 登录页面,根据Matrix备份文件进行集群恢复,并进行重新安装应用再配置恢复,具体步骤请参考《统一数字底盘部署指导》的“备份恢复”章节。
出现上述ETCD服务启动失败场景。
(1) 登录节点服务器,通过systemctl status etcd查看节点的ETCD服务状态,running为正常状态。若为不正常状态,可根据下列步骤进行故障恢复。
[root@master1 ~]# systemctl status etcd
(2) root用户通过systemctl stop matrix停止节点上Matrix服务。使用命令systemctl status matrix验证Matrix服务是否已经停止。若停止成功,则将在Active字段后显示运行信息为inactive (dead)。
[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。使用命令docker ps | grep kube-apiserver验证kube-apiserver服务是否已经停止。若无回显表示服务已停止。
[root@master1 ~]# mv /etc/kubernetes/manifests/kube-apiserver.yaml /opt/matrix
[root@master1 ~]# docker ps | grep kube-apiserver //查询是否已停止kube-apiserver
[root@master1 ~]# //无回显表示服务已停止
(4) root用户通过systemctl stop etcd完全停止etcd服务,使用命令systemctl status etcd验证etcd服务是否已经停止。若停止成功,则将在Active字段后显示运行信息为inactive (dead)。通过命令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_Snapshot_V900R001B06D012_20210805091547.db。
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) 点击“部署”页签,在弹出的菜单中选择“集群”,进入集群部署页面查看Master节点状态,Master节点状态正常,如下图所示。
图7-1 1个Master节点正常状态
(3) 点击“观测”页签,在弹出的菜单中选择“工作负载”,查看Pod状态,所有Pod都处于Running状态,如下图所示。
图7-2 Pod页签中所有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) 点击“部署”页签,在弹出的菜单中选择“集群”,进入集群部署页面查看Master节点状态,Master节点状态正常,如下图所示。
图7-3 三个Master节点+1个Worker节点正常状态
(3) 点击“观测”页签,在弹出的菜单中选择“工作负载”,查看Pod状态,所有Pod都处于Running状态,如下图所示。
图7-4 Pod页签中所有Pod都处于Running状态
出现如下任意现象,可能是由于ETCD非独立磁盘部署环境,磁盘IO性能差导致的故障现象。可按照相应故障处理步骤进行操作。
现象一:
ETCD客户端如K8s、Matrix等访问ETCD数据库超过800ms,分别登录各Master节点后台,在/var/log/matrix-diag/Matrix/etcd路径下查看etcd.log日志有以下信息。
[root@master2 etcd]# cat etcd.log |grep "took too long"
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集群频繁主备切换(多次执行etcdctl member list命令,若isLeader=true字段反复出现在不同节点,即为频繁主备切换),可能是由于ETCD集群因心跳超时导致。
图7-5 ETCD集群的主一直在etcd3上
(1) 若上述现象出现在应用安装升级、配置下发等操作过程,并导致操作失败的情况,则可以尝试再次进行安装升级、配置下发操作进行恢复(由于首次操作已完成部分数据同步,再次操作对磁盘IO影响减弱,会提高升级成功的概率)。
(2) 若上述现象出现稳态运行过程(即当前页面无用户操作),则可以通过配置定制文件/opt/matrix/config/navigator_config.json的主备切换参数"matrixLeaderLeaseDuration"(租约老化时间)和"matrixLeaderRetryPeriod"(租约检测周期)来延迟主备切换超时时间,但修改后也会影响节点故障切换时间。
(3) 如果因磁盘IO差导致无法写入或数据丢失的情况,有几种故障恢复方法:
¡ 方法一:
- 若出现Pod状态或通讯异常,可通过kubectl delete pod -n namespace podName命令删除异常Pod操作,删除后将自动创建Pod恢复ETCD数据资源。
¡ 方法二:通过7.1.2 1. 单机故障恢复和7.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配置文件内容丢失;/opt/matrix/k8s/下的deployenv.sh文件丢失。
· /var/log下的日志文件或其中的内容丢失。
· chronyd.service、docker.service、containerd.service的内容丢失故障处理步骤
a. 通过ls /usr/lib/systemd/system/service-name.service命令查看所有节点上的service文件是否存在或内容是否为空。
b. 若某些节点上存在该文件且内容正常,可通过scp命令将该文件拷贝到丢失该文件或文件内容为空的节点上。
c. 若所有节点上都不存在该文件,请联系技术工程师或重新安装操作系统。
· /etc/和/var/log下的文件或其中的内容丢失故障处理步骤
由于各节点的文件内容不一致,自行修改可能存在问题,请联系技术工程师处理或重新安装操作系统。
· /opt/matrix/k8s/下的deployenv.sh文件丢失故障处理步骤
集群环境从其他有deployenv.sh文件的Master节点拷贝该文件到本节点,若均不存在,尝试重建;单机环境请联系技术工程师或重装Matrix。
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. 若所有节点上都不存在该文件,请联系技术工程师或重新安装Matrix。
· /var/lib/docker下的Docker镜像文件损坏
¡ 请通过上传Matrix版本包的方式重建节点。
¡ 联系技术工程师处理。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器重启,出现如下现象:
· 若Matrix相关Pod异常,页面中节点可能会飘红或飘黄。
· 若产品相关Pod异常,在[观测>工作负载]页面下存在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异常,在[观测>工作负载]页面下存在非Running、Completed和Succeeded状态的Pod。
登录任一Master节点后台,使用kubectl get pod -A -owide | grep -Evw "Running|Completed|Succeeded"命令查看所有处于异常状态的Pod。
现象1:登录异常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
现象2:登录异常Pod所在节点后台,使用cat /var/log/matrix-diag/Matrix/kubelet/kubelet.log | grep "device or resource busy"命令查看该节点的kubelet日志,若出现如下报错信息,则该问题的原因为:重启节点导致Pod占用的cgroup资源无法清理,Pod无法正常删除。
msg="Failed to removecgroup" error="rmdir/sys/fs/cgroup/perf_event/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod19477284_c12f_45ca_b1f7_e44567957829.slice/docker-39dee0c5f2b0333af7ce921b03cad9dee06b6b949c4a55a80fca31b48305d001.scope:device or resource busy"
方法一(当异常Pod较少时可以使用该方法):
(1) 登录任一Master节点后台,使用kubectl get pod -A -owide | grep -Evw "Running|Completed|Succeeded"命令查看异常状态Pod的命名空间和名称。
(2) 执行kubectl delete pod -n namespace podName --grace-period=0 --force 2>/dev/null命令删除异常Pod。其中namespace为上一步查询出的异常Pod的命名空间,podName为异常Pod的名称。
说明:该命令用于删除指定节点上某个异常Pod,包括Error、CreateContainerError等异常状态,当存在多个异常Pod时,需多次执行该命令。
方法二(当异常Pod较多时可以使用该方法):
登录任一Master节点后台,执行kubectl get pod -A -owide --no-headers=true| grep -Evw "Running|Completed|Succeeded"| awk '{print $1 " " $2}'|xargs -I {} sh -c 'kubectl delete pod -n$1 $2 --grace-period=0 --force 2>/dev/null' sh {}命令。
说明:该命令用于批量删除所有处于异常状态的Pod。
通过kubectl get pod -n monitor -owide | grep prometheus命令查看prometheus Pod名称及状态,发现存在crashloopbackoff状态的Pod。使用kubectl logs -f -n monitor prometheus-podname prometheus-server命令查看日志,显示errorerr="opening storage failed: /data/xxx信息。
(1) 使用rm -rf /var/lib/ssdata/imonitor/prometheus_data/命令删除异常Pod所在节点的prometheus数据文件。
(2) 拷贝正常Pod所在节点的prometheus_data文件至异常Pod所在节点。若Pod都异常,则删除所有节点的prometheus_data文件。
(3) 重启异常Pod。
已部署Matrix集群,当应用所在节点的服务器下电重启后,网卡不可用,具体现象如下:
使用命令kubectl exec -it -n kube-system harbor-master1-6mvlb /bin/bash进入容器
输入ip a命令查看容器内所有网卡IP,查看MACVLAN附加网络中的IPv6网卡,网卡名称以“eth2@if3”为例,状态显示为“tentative dadfailed”状态,则表示此IPv6网卡不可用。
[root@vdhcpsrc1-6658fb96f4-j4n4f /]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if914: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 6e:e7:ed:2c:ed:5e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 177.177.204.216/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd00:177:177:0:d416:1f2a:c3a4:ccac/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::6ce7:edff:fe2c:ed5e/64 scope link
valid_lft forever preferred_lft forever
4: eth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether d6:ae:4e:73:38:8d brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 110.1.0.105/24 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::d4ae:4eff:fe73:388d/64 scope link
valid_lft forever preferred_lft forever
5: eth2@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether a2:23:c0:8f:ac:46 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 130::105/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
inet6 fe80::a023:c0ff:fe8f:ac46/64 scope link
valid_lft forever preferred_lft forever
应用所在的节点服务器下电重启后,可能出现由于操作系统无法回收使用MACVLAN附加网络且子网为IPv6协议栈的应用进程,导致应用进程残留,此时需要再次重启容器所在的节点服务器进行恢复。
Matrix正常运行或集群/应用部署过程中(如集群部署、升级、恢复、重建、应用部署和升级等),节点所在服务器重启,出现如下现象:
登录任一Master节点后台,使用kubectl get pod -A -o wide | grep -v Running命令查看Pod状态,显示使用附加网络的Pod反复重启,使用kubectl describe pod -n namespace podName命令查看Pod的事件。其中namespace为异常Pod的命名空间,podName为异常Pod的名称。报错信息如下:
Err adding pod to network"net-dtn-sim203": Multus: error in invoke Delegate add -"macvlan": failed to allocate for range 0: requested IP address172.30.128.140 is not available in range set3.2.27.1-3.2.27.254,172.30.128.1-172.30.128.254
故障由服务器断电重启导致附加网络的配置文件内容丢失导致,需要清理配置文件,使用root用户登录异常Pod所在节点后台执行恢复操作步骤如下:
(1) 使用cd /var/lib/cni/networks/${macvlan-name}/命令进入配置目录,其中macvlan-name为报错信息中的network名称,如示例中的net-dtn-sim203。
(2) 使用rm -rf ${IP}命令删除损坏的配置文件,其中IP为报错信息中的IP地址,如示例中的172.30.128.140。
集群部署失败,单击节点右上角按钮,选择[日志]菜单项查看节点日志,提示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 -it -n namespace pod_name bash命令失败(命令执行回显error报错)导致创建gfs卷不成功。登录节点后台执行kubectl exec -it -n namespace pod_name bash命令发现该节点上的所有Pod都无法进入。
图11-1 报错举例
(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 -d /var/lib/etcd命令。
¡ 非root用户:执行sudo bash /opt/matrix/tools/env_check.sh -p -d /var/lib/etcd命令。
(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状态后重新访问统一数字底盘页面。
若用户丢失密码,将无法登录统一数字底盘。
造成故障的原因:用户丢失密码。
可通过如下步骤重置密码:
(1) 登录主节点后台的/opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset/目录。
[root@node1 ~]# cd /opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset/
(2) 执行reset_admin_password.sh脚本重置密码。
[root@node1 reset]# ./reset_admin_password.sh
+++ readlink -f ./reset_admin_password.sh
++ dirname /opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset/reset_admin_password.sh
+ curDir=/opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset
+ echo /opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset
/opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset
+ cd /opt/matrix/app/install/metadata/UCENTER/portal/portal/portal/scripts/reset
++ kubectl get pod -nservice-software
++ grep stolon-proxy
++ grep Running
++ awk 'NR==1{print $1}'
+ proxy=stolon-proxy-2tp4v
+ kubectl cp ./reset_admin_password.sql -nservice-software stolon-proxy-2tp4v:/tmp
++ base64 -d
++ kubectl get secret -nservice-software stolon '-ojsonpath={.data.password}'
+ pg_admin_password=Or10TL+hRs.=N@0l54
+ kubectl exec -it -nservice-software stolon-proxy-2tp4v -- bash -c 'export PGPASSWORD=Or10TL+hRs.=N@0l54;psql -U kong -d central_db -h 127.0.0.1 -p 5432 -f /tmp/reset_admin_password.sql'
UPDATE 1
+ exit 0
(3) 密码重置为“Pwd@12345”。
在宿主机或业务容器中执行ls -l dir,其中,dir表示业务挂载的GFS目录,在查看挂载目录时出现“???”的文件,且该文件无法访问。
造成故障的原因:由于GlusterFS存储卷三副本的节点上所剩余的磁盘空间不一致,导致在写入数据后,三副本内数据不一致,出现Glusterfs存储卷数据文件脑裂。
故障处理步骤如下:
(1) 通过命令kubectl get pod -A |grep glusterfs查询GlusterFS组件相关Pod的名称及其所在的命名空间。
(2) 通过命令kubectl exec -it -n glusterfs-example pod_name bash(例如:kubectl exec -it -n glusterfs-example glusterfs-j9vnt bash)进入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为需要清空的磁盘,需要注意的是,disks必须带双引号,且如果清除多个磁盘或磁盘分区需要以空格隔开,例如,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启动同步数据任务时,重建节点的Glusterfs pod 中的glusterd服务还处在异常状态。
故障处理步骤如下:
· 针对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) 确认重建前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" ]
} ]
(4) 重启已重建节点的glusterfs pod。例如:删除hostname为c3的glusterfs pod
[root@c3 ~]# kubectl get pod -A -owide |grep glusterfs |grep c3
glusterfs-example gfs-exporter-php62 1/1 Running 0 46m 10.99.212.72 c3 <none> <none>
glusterfs-example glusterfs-fh2cc 1/1 Running 0 46m 10.99.212.72 c3 <none> <none>
glusterfs-example heketi-75d6c7db69-vhzh2 1/1 Running 0 26m 177.177.240.5 c3 <none> <none>
glusterfs-example monitor-5f9bd8ccb4-54mrn 1/1 Running 0 26m 177.177.240.4 c3 <none> <none>
[root@c3 ~]# kubectl delete pod -n glusterfs-example glusterfs-fh2cc
pod "glusterfs-fh2cc" deleted
· 更多恢复流程请查看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"
· 现象3:节点kubelet服务频繁重启,引起K8S节点状态异常(Not Ready状态),页面上节点飘红,查看节点详情,kubelet、coreDNS等检查项异常。查看故障节点的kubelet日志(/var/log/matrix-diag/Matrix/kubelet/kubelet.log),频繁打印异常日志“Image garbage collection failed once. Stats initialization may not have completed yet" err="failed to get imageFs info: unable to find data in memory cache.”。
出现上述三种现象,则为镜像损坏的故障。
· 方法一
请依次执行以下命令,删除故障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 -n namespace pod_name命令查看各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
图18-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”说明数据库修复完毕,测试数据库连接正常。
VMware虚机部署控制组件,虚拟化异常,重启服务器后由于ETCD存储数据文件在节点重启后损坏或者丢失,导致ETCD服务启动失败。
只有一个节点故障是可以线上修复的,处理步骤如下:
(1) 登录Matrix界面,进入[部署>集群]页面。
(3) 选择“重建”,即可对指定节点进行重建操作,重建完成后故障即可恢复。
重建节点会重启该节点所有Pod,请现场申请重启的时间段,以免影响业务。
表19-1 集群部署页面
三节点发生异常断电,异常断电导致三个节点的ZooKeeper数据无法同步,恢复供电并重启服务后,无法确保三个节点的ZooKeeper同时启动,导致ZooKeeper持久化数据不同步。
通过重建ZooKeeper来解决,依次将三个ZooKeeper Pod删除后重启。如下图所示。
图19-1 重建zk
异常断电导致PXC数据库启动需要用到的磁盘文件内容全部丢失(grastate.dat文件内容被清空),异常的Pod连接不上PXC数据库。
grastate.dat修复步骤:
(1) 连接到异常Pod所在节点后台(如果是非root用户部署,请sudo -i切换成root用户)。
(2) 执行cd /var/lib/ssdata/pxc/pxc/*命令进入该PXC数据目录。
(3) 执行cat grastate.dat命令查看该文件是否为空,该文件正常情况下应如下图所示:
图19-2 查看文件
(4) 如果查看文件内容是空的,则可以执行如下命令将文件内容(红色部分是该文件内容)补全:
[root@mmp-001 1]# cat > grastate.dat <<- EOF
# GALERA saved state
version: 2.1
uuid: 938a614c-8c38-11ee-a589-8a75c3c33cea
seqno: -1
safe_to_bootstrap: 0
EOF
如果是单机环境,文件格式正确即可,uuid等值不需要修改,启动后会自动生成;如果是集群环境,可以从其他正常节点获取该文件内容。
(5) 文件修复后,执行如下命令批量删除数据库集群的Pod,重启pxc-node。
kubectl get pod -n service-software -o wide | grep pxc-node | awk '{print $1}' | xargs kubectl -n service-software delete pod
图19-3 命令视图
服务器断电重启后台无法ssh登录,重启sshd服务提示进入紧急模式,判断是服务器异常断电后XFS文件系统损坏。verticaluanch与verticaluanch-10s频繁重启,判断是Vertica数据库异常
XFS文件系统修复步骤如下:
(1) 使用lsblk命令查找挂载路径,使用umount命令将其卸载,确保分区处于umount 状态。
图19-4 查看挂载路径
(2) 执行 xfs_repair –n命令检查文件系统是否损坏。
(3) 执行xfs_repair -L /dev/sda1修复文件系统。
(4) 执行 xfs_ncheck /dev/sda1检查文件系统是否修复成功。
xfs_repair带 –L参数 是修复 xfs 文件系统的最后手段,慎重选择,它会清空日志,会丢失用户数据和文件。
(5) 结果验证
a. 修复文件损坏的磁盘并重启后节点SSH登录恢复正常,Pod恢复正常。
b. 数据库异常与19.1 Etcd的db文件损坏有关,导致节点启动依赖的任务无法启动,重新修复节点的数据库后恢复正常。
安装环境不稳定,服务器每晚都异常断电,引发Kafka数据丢失,Pod异常。
重启Kafka中间件。
图19-5 重启kafka中间件
迁移过程中掉电导致var/lib/docker系统文件损坏,docker服务status 异常。
需要重装iso镜像,重建节点进行恢复。
图19-6 重建节点
集群掉电导致Kafka异常,导致Campus通过WebSocket跟设备交互时无法从Kafka获取回复,所有Leaf与Spine的互联链路拓扑飘红。
执行以下步骤进行恢复:
(1) 清除所有节点的/var/lib/ssdata/zookeeper、/var/lib/ssdata/kafka目录下的数据。
图19-7 清除数据
(2) 重启Kafka、ZooKeeper相关Pod。
将Kafka和ZooKeeper的Pod依次执行删除命令即可。
图19-8 重启Pod
客户现场强制断电,导致服务器重启后操作系统XFS分区损坏,系统异常,无法进入操作系统或进入了紧急模式。
进入紧急模式或单用户视图强制修复损坏分区,修复完成后重启服务器可正常进入操作系统。
XFS文件系统修复方法:
(1) 使用lsblk命令查找挂载路径,使用umount命令将其卸载,确保分区处于umount状态。
图19-9 查看挂载路径
(2) 检测文件系统是否损坏:执行 xfs_repair -n,检查文件系统是否损坏。
(3) 修复文件系统,如执行xfs_repair -L /dev/sda1。
(4) 执行 xfs_ncheck /dev/sda1检查文件系统是否修复成功。
xfs_repair带 –L参数 是修复 xfs 文件系统的最后手段,慎重选择,它会清空日志,会丢失用户数据和文件。
统一数字底盘升级后,执行kubectl get pod -A | grep eure命令查看Pod状态后,出现处于Pending状态的k-eureka Pod 等。
图20-1 k-eureka-2 Pod状态为Pending
执行kubectl describe pod命令,报错为:k-eureka Pod所在节点不满足Pod亲和性/反亲和性规则配置。不满足:
图20-2 Pod affinity/anti-affinity不满足
但实际查询Pod所在节点的亲和性/反亲和性规则配置时,发现该节点满足其要求。
该问题的原因为:删除k-eureka Pod时概率性出现kube-scheduler cache中残留该Pod相关信息,再次启动相同名称的Pod时,将出现调度异常。
重启各Master节点的kube-scheduler pod。
在其中一个Master节点后台操作即可,故障处理步骤如下:
(1) 执行kubectl get pod -A -owide | grep kube-scheduler命令查询kube-scheduler Pod名称。
图20-3 查看kube-scheduler Pod名称
(2) 执行kubectl delete pod -n kube-system pod-name命令,其中,pod-name为步骤(1)查询到的Pod名称。集群环境下多个kube-scheduler Pod可以同时删除,pod-name替换成三个kube-scheduler Pod名称,并以空格相隔即可。
图20-4 集群环境下删除多个kube-scheduler Pod
(3) Kube-scheduler Pod重启完成后,过一段时间异常Pod将恢复正常。若未恢复正常请联系技术工程师处理。
灾备场景下,当备站点宕机或者和主站点网络异常时,此时用户在主站点上操作删除灾备系统,由于备站点无法接收主站点信息,此时会导致备站点上灾备相关配置残留,备站点相关组件还是处于灾备模式。
由于备站点和主站点之间网络异常或者备站点宕机,导致备站点无法收到和执行主站点请求,从而导致配置残留。
可以通过执行删除备站点配置脚本进行修复。具体操作如下:
在备站点任意一个节点上执行如下命令,脚本执行日志提示success表示修复成功。
sh /opt/matrix/app/install/metadata/UCENTER/general/rdr/scripts/clearMemberRdrConfig.sh
灾备场景下,在升主降备的过程中,主备站点之间网路异常,导致降备站点(原主)无法访问,页面显示异常。
由于升主降备过程中网络异常,降备站点执行降备操作时,无法和新主建立连接,导致数据库异常。
(1) 如果新主灾备页面显示状态为升主失败,确保主备网络恢复正常后,登录新主用站点的统一数字底盘页面,进入[系统>应急管理>异地容灾]页面,单击容灾关系中组件的按钮,等待升主成功即可。
(2) 如果新主灾备页面显示状态为主用状态,确保主备网络恢复正常后,在备站点上任意一个节点上执行sh /opt/matrix/app/install/metadata/UCENTER/general/rdr/scripts/forceDropProduct.sh命令,脚本执行日志提示如图即可说明修复成功。
在带仲裁的自动倒换模式下,主用站点出现异常,备用站点自动接管成功。原主用站点异常恢复后,无法自动降备,出现双主状态。
故障处理步骤如下:
(1) 确保原主用站点恢复正常后,登录新主用站点的统一数字底盘页面,进入[系统>应急管理>异地容灾]页面,修改倒换模式为手动模式后,单击容灾关系中组件的按钮,等待降备成功即可。
(2) 如果上述操作完成后故障仍无法排除,请联系技术支持工程师。
主备站点上的组件都是主用状态。登录主备站点的统一数字底盘页面,主备站点上的控制组件菜单均显示正常。
· 故障可能的原因:
手动模式下,主备之间网络中断,手动在备站点页面上点击升主,备用组件接管成功,原主用站点由于网络原因未收到降备请求,导致未降备,最终出现“双主”状态。
· 故障处理步骤如下:
确保原主用站点恢复正常后,登录新主用站点的统一数字底盘页面,进入[系统>应急管理>异地容灾]页面,修改倒换模式为手动模式后,单击容灾关系中组件的按钮,等待降备成功即可。
场景一:
Kafka Pod持续输出大量错误日志,可以执行kubectl logs -nservice-software -f 异常Kafka Pod名称 | grep "Error processing append operation on partition __consumer_offsets"命令,或者进入到异常Kafka Pod的后台节点目录/var/lib/ssdata/log/kafka/broker2(假如当前为kafka-2 pod服务异常),找到最新的server.log或kafka-server.log文件,查看是否包含着大量的“Error processing append operation on partition __consumer_offsets”或者“java.nio.BufferOverflowException”错误日志,如果上述错误现象一直持续存在,说明当前Kafka Pod服务存在异常。
场景二:
如果Kafka Pod状态正常,但是关联的业务服务均无法消费,比如业务可能会报出“org.apache.kafka.common.errors.TimeoutException: Failed to update metadata”错误。
场景三:
如果Kafka Pod状态正常,但是关联的业务服务部分无法消费,比如业务可能会报出“Offset commit failed on partition”错误。
三个场景的故障原因:由于Kafka和ZooKeeper之间的通信问题,导致部分Kafka Server节点在ZooKeeper中注册的临时节点消失或者Kafka自身的控制器存在切换,相关元数据无法及时更新到ZooKeeper或者更新到Kafka缓存里,这样就会存在ZooKeeper中元数据和各个Kafka Server节点的元数据不一致问题,元数据损坏,进而导致Kafka服务Pod全部或部分不能提供服务。
可通过重启 Kafka Pod解决该故障,具体如下:
对于场景一:直接执行kubectl delete pod -nservice-software 异常kafka-pod名称命令解决。
对于场景二或者场景三:需要分别delete三个(单节点集群为一个)Kafka Pod解决。通过执行如下三条命令:
kubectl delete pod -nservice-software kafka-0-xxxxx
kubectl delete pod -nservice-software kafka-1-xxxxx
kubectl delete pod -nservice-software kafka-2-xxxxx
xxxxx代表Kafka各实例Pod名称的后缀,操作示例如下图所示。
图22-1 执行Delete Kafka Pod命令
在节点系统断电或者系统重启后,Kafka服务会偶现非Running状态的Pod,该Pod会处于不断重启的状态,重启次数不断增加,并且Pod状态会在CrashLoopBackOff和Running状态不停切换。下图为正常运行情况下的Kafka状态。
图22-2 正常运行情况下的Kafka状态
故障可能的原因:在节点系统断电或者系统重启后,致使该节点上运行的Kafka实例数据文件损坏,进而导致对应Pod一直处于不断重启的状态。
可以通过kubectl logs -nservice-software -f 异常kafka-pod名称 | grep "Found a corrupted index file"命令确认是否存在Kafka数据文件损坏。
(1) 执行kubectl get pod -nservice-software -owide | grep kafka命令获取异常Pod所在的节点。
图22-3 获取异常Pod所在节点
(2) 执行cd /var/lib/ssdata/kafka/broker2/kafka-log-data命令进入有文件损坏的节点目录。
(3) 按顺序执行如下命令:
sudo rm -rf *
ubectl delete pod -nservice-software 异常kafka-pod名称
(4) 等待该异常Pod恢复正常即可。
注意:如果Kafka为三个实例pod集群环境,一个节点文件损坏,不影响Kafka正常运行,多于一个节点文件损坏可能会影响Kafka服务运行;如果Kafka为单节点实例Pod环境,发生文件损坏,无法根本上保证Kafka服务正常运行和数据不丢失,通过上述操作恢复后,Kafka可以恢复正常,同时可能会损失部分数据。