联 系 我 们
售前咨询
售后咨询
微信关注:星环科技服务号
更多联系方式 >
9.7.2 故障快速诊断
更新时间:9/27/2023, 9:33:48 AM

当业务运行受到中断影响时,您可以通过阅读本节,向用户提供快速诊断思路,帮助用户快速定位并为下一步排查做指导。主要包含以下排查要点:

检查机器状态

检测集群机器是否可以正常登陆,确保在操作系统层面,主机是否正常运行。

  • ping:观察响应时间,正常应在毫秒级。

  • ssh:观察是否有卡顿。

检查 TOS 状态

星环统一管理平台 Manager 中查看 TOS 的状态,若 Manager 无法访问时,则需通过在节点终端进行命令查看。

Manager 访问正常
  1. 登录 Tranwarp Manager 并单击右上角菜单栏打开 Aquila。

    manager open aquila
    图 9.2.1:Manager 中打开 Aquila
  2. 然后选择集群概览界面查看集群状态。

    aquila cluster overview
    图 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 状态

  1. 先确认集群节点上存在 etcdctl 命令:

    docker ps | grep etcd
    复制
  2. 查看 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 状态。

  3. 查看 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 角色,除了不参与投票外,和普通节点一致。

  4. 检查 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 读写是否正常

  1. 使用 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>
    复制
  2. 查看 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>
    复制
  3. 删除 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 整体运行状态
  1. 执行命令获取命名空间:

    kubectl get ns
    复制
  2. 然后按照命名空间分别进行查看

    kubectl get po <pod_name> -n <name_space>
    复制
    • 重点查看以下信息:

      • 状态不是 running 的;

      • ready 的数字不是 n/n;

      • 重启次数很多的

更多 Pod 相关状态信息及排查方式,请参考Pod 异常处理

检查 KunDB 运行状态
  1. 首先检查 Kundb Pod 是否运行正常

    kubectl get po |grep kundb
    
    kubectl logs <kundb-pod-id> # 逐个 pod 查看日志
    
    kubectl describe pod <kundb-pod-id> # 查看 pod 相关信息
    复制
  2. 然后检查 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 则表示该角色健康。

  3. 在 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:

查看 Guardian Server 是否正常
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 的状态。

查看 Guardian ApacheDS 是否正常

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 是否过期:

  1. 进入到 master节点的 /srv/kubernetes/ 目录下:

    cd /srv/kubernetes/
    复制
  2. 运行命令查看 License 过期时间

    openssl x509 -text -in etcd-ca.pem | grep "Not"
    复制
    check license ddl
    图 9.2.3:查看 License 使用期限

在 License 没有过期的情况下,如果存在无法创建 Pod,namespace 的情况,检查 Kubernetes(集群节点数 * 3),和 TOS(集群节点数)组件的节点数是否满足要求。

如果组件 pod 有 license 相关报错导致无法启动,请参考License 异常进行处理。