发布时间：2023-01-22 21:00
本文介绍了 Kubernetes 上 TiDB 集群管理常用使用技巧。
当 Pod 处于 CrashLoopBackoff 状态时，Pod 内容器不断退出，导致无法正常使用 kubectl exec，给诊断带来不便。为了解决这个问题，TiDB in Kubernetes 提供了 PD/TiKV/TiDB Pod 诊断模式。在诊断模式下，Pod 内的容器启动后会直接挂起，不会再进入重复 Crash 的状态，此时，便可以通过 kubectl exec 连接 Pod 内的容器进行诊断。
操作方式：
首先，为待诊断的 Pod 添加 Annotation：
kubectl annotate pod ${pod_name} -n ${namespace} runmode=debug
在 Pod 内的容器下次重启时，会检测到该 Annotation，进入诊断模式。
注意
如果 Pod 处于运行中，可以执行以下命令强制让容器重启。
kubectl exec ${pod_name} -n ${namespace} -c ${container} -- kill -SIGTERM 1
等待 Pod 进入 Running 状态即可开始诊断：
watch kubectl get pod ${pod_name} -n ${namespace}
下面是使用 kubectl exec 进入容器进行诊断工作的例子：
kubectl exec -it ${pod_name} -n ${namespace} -- /bin/sh
诊断完毕，修复问题后，删除 Pod：
kubectl delete pod ${pod_name} -n ${namespace}
Pod 重建后会自动回到正常运行模式。
在一些测试场景中，如果你需要单独修改某一个 TiKV 实例配置，而不影响其他的 TiKV 实例，可以参考以下两种方式。
参考文档在线修改 TiKV 配置，使用 SQL 在线更新某一个 TiKV 实例的配置。
注意
这种方式的配置更新是临时的，不会持久化。这意味着，当该 TiKV 的 Pod 重启后，依旧会使用原来的配置。
让 TiKV Pod 进入诊断模式后，可以手动修改 TiKV 的配置文件，并指定使用修改后的配置文件启动 TiKV 进程。
具体操作步骤如下：
从 TiKV 的日志中获取 TiKV 的启动命令，后续步骤中将会使用。
kubectl logs pod ${pod_name} -n ${namespace} -c tikv | head -2 | tail -1
输出类似如下，该行就是 TiKV 的启动命令。
/tikv-server --pd=http://${tc_name}-pd:2379 --advertise-addr=${pod_name}.${tc_name}-tikv-peer.default.svc:20160 --addr=0.0.0.0:20160 --status-addr=0.0.0.0:20180 --data-dir=/var/lib/tikv --capacity=0 --config=/etc/tikv/tikv.toml
注意
如果 TiKV Pod 持续处于 CrashLoopBackoff 状态，无法从日志中获取启动命令，可以按照上述的命令格式来拼接出启动命令。
对 Pod 开启诊断模式，并重启 Pod。
执行以下命令为 Pod 添加 Annotation，等待下一次 Pod 重启。
kubectl annotate pod ${pod_name} -n ${namespace} runmode=debug
如果 Pod 一直处于运行中，你可以执行以下命令强制让 TiKV 容器重启。
kubectl exec ${pod_name} -n ${namespace} -c tikv -- kill -SIGTERM 1
可以通过检查 TiKV 的日志，确认是否进入了诊断模式。
kubectl logs ${pod_name} -n ${namespace} -c tikv
期望的日志内容如下：
entering debug mode.
执行下面命令进入 TiKV 容器。
kubectl exec -it ${pod_name} -n ${namespace} -c tikv -- sh
在 TiKV 容器中，复制 TiKV 的配置文件，然后在新的文件上修改 TiKV 的配置。
cp /etc/tikv/tikv.toml /tmp/tikv.toml && vi /tmp/tikv.tmol
在 TiKV 容器中，根据第 1 步中获取的 TiKV 的启动命令，修改启动参数 --config 为刚刚新创建的配置文件路径后，启动 TiKV 进程。
/tikv-server --pd=http://${tc_name}-pd:2379 --advertise-addr=${pod_name}.${tc_name}-tikv-peer.default.svc:20160 --addr=0.0.0.0:20160 --status-addr=0.0.0.0:20180 --data-dir=/var/lib/tikv --capacity=0 --config=/tmp/tikv.toml
测试完成后，如果要恢复 TiKV Pod，可以直接删除当前的 TiKV Pod，并等待 TiKV Pod 自动被拉起。
kubectl delete ${pod_name} -n ${namespace}
正常情况下，在 TiKV 滚动升级或者修改配置滚动更新过程中，TiDB Operator 会为每个 TiKV 驱逐 Region Leader，并在 Leader 驱逐完成后才开始更新当前 Pod，尽量减小滚动升级或者更新过程对用户请求的影响。在一些测试场景中，如果你不需要在 TiKV 滚动升级或者修改配置滚动更新过程中等待 TiKV 上的 Region Leader 迁移，想要加速升级或者更新过程，可以将 TidbCluster 定义中的 spec.tikv.evictLeaderTimeout 字段设置为一个很小的值。
spec: tikv: evictLeaderTimeout: 10s
关于该字段更多的说明，见配置 TiKV 平滑升级。
警告
该操作会导致部分用户请求失败，不建议在生产环境中使用。