
当业务运行受到中断影响时,您可以通过阅读本节,向用户提供快速诊断思路,帮助用户快速定位并为下一步排查做指导。主要包含以下排查要点:
检查机器状态
检测集群机器是否可以正常登陆,确保在操作系统层面,主机是否正常运行。
-
ping:观察响应时间,正常应在毫秒级。
-
ssh:观察是否有卡顿。
检查 TOS 状态
星环统一管理平台 Manager 中查看 TOS 的状态,若 Manager 无法访问时,则需通过在节点终端进行命令查看。
Manager 访问正常
-
登录 Tranwarp Manager 并单击右上角菜单栏打开 Aquila。
图 9.2.1:Manager 中打开 Aquila -
然后选择集群概览界面查看集群状态。
图 9.2.2:集群概览
Manager 无法访问
集群节点状态
$ kubectl get nodes #输出如下: NAME STATUS ROLES AGE VERSION idc1 Ready <none> 6d5h v2.1.0-tos-final-build-20220805-tdh idc2 Ready <none> 6d5h v2.1.0-tos-final-build-20220805-tdh idc3 Ready <none> 6d5h v2.1.0-tos-final-build-20220805-tdh
复制
-
如果上述命令无法执行,则说明 API Server 无法正常访问,可以登陆其他 TOS Master 节点执行。如果只是当前 TOS Master 节点执行有问题,执行以下命令检查 haproxy
$ systemctl status haproxy #输出如下: ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled) Active: active (running) since 四 2023-04-20 09:35:29 CST; 6 days ago Main PID: 48400 (haproxy-systemd) CGroup: /system.slice/haproxy.service ├─48400 /usr/sbin/haproxy-systemd-wrapper -f /etc/tos/conf/haproxy.cfg -p /run/haproxy.pid ├─48402 /usr/sbin/haproxy -f /etc/tos/conf/haproxy.cfg -p /run/haproxy.pid -Ds └─48403 /usr/sbin/haproxy -f /etc/tos/conf/haproxy.cfg -p /run/haproxy.pid -Ds 4月 20 09:35:29 idc1 haproxy-systemd-wrapper[48066]: haproxy-systemd-wrapper: SIGTERM -> 48069. 4月 20 09:35:29 idc1 haproxy-systemd-wrapper[48066]: haproxy-systemd-wrapper: exit, haproxy RC=143 4月 20 09:35:29 idc1 systemd[1]: haproxy.service: main process exited, code=exited, status=143/n/a 4月 20 09:35:29 idc1 systemd[1]: Stopped HAProxy Load Balancer. 4月 20 09:35:29 idc1 systemd[1]: Unit haproxy.service entered failed state. 4月 20 09:35:29 idc1 systemd[1]: haproxy.service failed. 4月 20 09:35:29 idc1 systemd[1]: Started HAProxy Load Balancer. 4月 20 09:35:29 idc1 haproxy-systemd-wrapper[48400]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/t... -Ds Hint: Some lines were ellipsized, use -l to show in full.
复制 -
如果出现节点 not ready,进入到问题节点中进行故障排查。
检查 etcd 状态
-
先确认集群节点上存在 etcdctl 命令:
docker ps | grep etcd
复制 -
查看 etcd 的成员:
ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 member list ## 返回案例 927b6f42f6b4e231, started, ETCD7, https://tw-node2:4002, https://tw-node2:4001 b24570d67a787b3e, started, ETCD8, https://tw-node3:4002, https://tw-node3:4001 d25c0d36cc26e1a9, started, ETCD6, https://tw-node1:4002, https://tw-node1:4001
复制-
<node1> ~ <node3>:集群中的所有节点对应的 hostname。
-
正常时应该所有 etcd 都为
started
状态。
-
-
查看 etcd 状态
ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 endpoint status ## 返回案例 https://tw-node1:4001, d25c0d36cc26e1a9, 3.3.10, 27 MB, false, 1430, 24944142 https://tw-node2:4001, 927b6f42f6b4e231, 3.3.10, 27 MB, false, 1430, 24944142 https://tw-node3:4001, b24570d67a787b3e, 3.3.10, 27 MB, true, 1430, 24944142
复制-
<node1> ~ <node3>:集群中的所有节点对应的 hostname。
-
输出结果中,false 指改节点不是 learner 角色,除了不参与投票外,和普通节点一致。
-
-
检查 etcd 的健康状态:
ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 endpoint health ## 返回案例 https://tw-node2:4001 is healthy: successfully committed proposal: took = 1.487483ms https://tw-node3:4001 is healthy: successfully committed proposal: took = 935.141µs https://tw-node1:4001 is healthy: successfully committed proposal: took = 2.55937ms
复制-
<node1> ~ <node3>:集群中的所有节点对应的 hostname。
-
正常运行时所有 etcd 都可以正常连接,当出现 etcd 不健康时报错
unhealthy cluster
且连接失败connection refused
。
-
检查 etcd 读写是否正常
-
使用 etcd 进行写入操作(put),运行成功返回
OK
:ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 put <text>
复制 -
查看 etcd 写入的内容(get),返回查询结果,如果不存在则返回空:
ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 get <text>
复制 -
删除 etcd 的内容(del),运行成功返回
1
:ETCDCTL_API=3 etcdctl --cacert /srv/kubernetes/etcd-ca.pem --cert /srv/kubernetes/etcd.pem --key /srv/kubernetes/etcd-key.pem --endpoints https://<node1>:4001,https://<node1>:4001,https://<node1>:4001 del <text>
复制
<node1> ~ <node3>:集群中的所有节点对应的 hostname。 <text>:写入、查看或删除的信息。
检查 Pod 整体运行状态
-
执行命令获取命名空间:
kubectl get ns
复制 -
然后按照命名空间分别进行查看
kubectl get po <pod_name> -n <name_space>
复制-
重点查看以下信息:
-
状态不是 running 的;
-
ready 的数字不是 n/n;
-
重启次数很多的
-
-
更多 Pod 相关状态信息及排查方式,请参考Pod 异常处理。
检查 KunDB 运行状态
-
首先检查 Kundb Pod 是否运行正常
kubectl get po |grep kundb kubectl logs <kundb-pod-id> # 逐个 pod 查看日志 kubectl describe pod <kundb-pod-id> # 查看 pod 相关信息
复制 -
然后检查 Kundb 角色的健康情况
curl --connect-timeout 15 --max-time 15 http://<ip>:<port>/check/status
复制-
<ip>:Kundb 服务角色 KunGate 所在节点的 IP 地址。
-
<port>:端口参数
kungate.debug.port
的值,默认为 15001。 -
返回
Client sent an HTTP request to an HTTPS server
则表示该角色健康。
-
-
在 Manager 中查看 Kundb 的相关端口,并确定端口是否存在异常。
检查租户 Guardian 运行状态
检查 Guardian Pod
kubectl get po |grep guardian kubectl logs <guardian-pod-id> # 逐个查看 pod 日志 kubectl describe pod <guardian-pod-id> # 查看 pod 相关信息
复制
检查 Guardian 业务
其中与业务相关的角色主要是 Guardian Server 与 Guardian ApacheDS:
curl -ivk 'https://<ip>:<port>/api/v2/health'
复制
-
<ip>:Guardian Server 角色对应的 IP 地址,如在本体 pod 中,可使用 localhost 或 127.0.0.1 代替。
-
<port>:端口参数
guardian.server.port
的值,一般默认为 8380。 -
目前该 API 会检查以下两个部分:
-
检查 Guardian ApadheDS 是否可连接(通过 LDAP 接口)。
-
在数据库中执行 SELECT 1。
-
-
如果在 10s 内返回了如下结构体,则说明 pod 健康:
{"status":"UP","details":{"Database":"UP","ApacheDs":"UP"}
复制如果请求被拒绝、卡住或没有在 10 秒内响应,则可认为 pod 处于不健康的状态,相应的,guardian server 的 pod 会显示成
0/1 Running
的状态。
ApacheDS 有单独的命令可以检查可用性,但需要执行的节点安装了 ldapsearch 命令(该命令在 Guardian 所有镜像中是预置的)
ldapsearch -h <ip> -p <port> -x -D "uid=admin,ou=system" -w Transwarp! -b "uid=admin,ou=system"
复制
-
<ip>:为 Guardian ApacheDS 节点的 IP,如果 pod 处于 Running 状态,则可在 pod 中使用 localhost 或127.0.0.1。
-
<port>:端口参数
guardian.apacheds.ldap.port
的值,一般默认为 10389。
检查 License 状态
检查 License 是否过期:
-
进入到 master节点的 /srv/kubernetes/ 目录下:
cd /srv/kubernetes/
复制 -
运行命令查看 License 过期时间
openssl x509 -text -in etcd-ca.pem | grep "Not"
复制图 9.2.3:查看 License 使用期限
在 License 没有过期的情况下,如果存在无法创建 Pod,namespace 的情况,检查 Kubernetes(集群节点数 * 3),和 TOS(集群节点数)组件的节点数是否满足要求。
如果组件 pod 有 license 相关报错导致无法启动,请参考License 异常进行处理。