作者： lqbyz 原文来源：https://tidb.net/blog/df0ffa69

出现问题

1.TiDB Dashboard 无法正常使用

现象

修改相关的配置，尤其是超过一个 pd 的时候 dashboard 是无法打开的，需要打开 tidb dashboard

排查步骤

1. 在 pd 上添加如下配置，发现修改相关的配置无法打开 dashboard

  pd:    baseImage: pingcap/pd    config: |      [dashboard]        internal-proxy = true

2. 查看 pd 相关的 pod 发现更新的配置没有滚动更新，该 pod 还是原先，通过 delete 也是如此。

3. 后经排查发现缺少 tc 集群没有滚动更新的配置，添加滚动更新的配置

  enableDynamicConfiguration: true

4. 再次修改改配置的时候，发现 pd 滚动更新 pod，对外也可以正常访问了。

2.dashboard 通过 ingress 对外映射。

客户需要通过映射对外访问 dashboard

解决步骤：

K8S-Ingress 控制器

3.tikv 副本数是 6 后来一台服务器下线维护过程中有一个产生，当维护的服务器上线后，现在副本数是 7 和期望的状态不一致，整个集群是 false。

现象：

dashboard 的状态有个 tikv 是离线状态，整个集群状态是 false

排查步骤：

1. 缩容 tikv，由于一台服务器维护下线，tc 由于设置 tikv 的副本数为 6，由于下线的一台有 tikv 为保证副本数 tc 又拉起了一台 tikv，维护的服务器又再次上线 tikv 也在线了，造成副本数为 7 与期望的 6 不符需要缩容，通过命名 patch 直接缩容成功了，也给客户解释了，防止服务器频繁上下线造成集群写入压力大，影响稳定性，这个 operator 为了防止频繁上下线做的操作。

2. 进入 pd 的 pod 通过命令发现该下线的 pod 没有变成 bonstone，手动删除该下线节点的 id。./pd-ctl store delete 629（通过在 pd 里删除下线的 tikv 的 id，会使该 id 自动下线，集群状态收集状态自动同步，状态变为 True。）

4.pod 出现 CrashLoopBackOff

现象

通过 kubectl get pod -n$ns 时新扩容的 pod 总出现 CrashLoopBackOff

排查步骤：

1. 通过 kubectl describe pod/$pod-n$ns。发现初始化失败重启后失败又重启。

2. 通过查看该 pod 的日志，发现相关的报错，大致就是初始化数据的时候有相关的文件造成初始化数据文件失败。新的 pod 在往里写数据的时候写不进去。

3. 通过解绑 pv 和 pvc，删除 pv 里的数据，然后重新绑定解决。或者直接删除绑定 pv 里的数据，kubelet 过两分钟还会重启该容器，最近该 pod 的状态为 running。

5. 客户直接修改 sts 造成 tc 状态为 false

现象

经查看 tc 的状态为 false，和 sts 的状态不一致。

排查步骤

1. 由于直接修改 sts 造成集群的期望和 tc 的期望不一致，tc 在获取机器的状态时造成不一致。

2. 把修改的 sts 的扩缩容的副本数修改过来，以后通过 tc 对整个集群的管理。

###

小结：

以上均为在实际环境中常出现的问题，及相关的解决步骤和思路，请结合实际环境进行排查，图片如有任何不妥的地方，请私聊会做进一步的处理。

##