本文介绍了 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 实例,可以参考以下两种方式。
在线更新
参考文档在线修改 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 强制升级
正常情况下,在 TiKV 滚动升级或者修改配置滚动更新过程中,TiDB Operator 会为每个 TiKV 驱逐 Region Leader,并在 Leader 驱逐完成后才开始更新当前 Pod,尽量减小滚动升级或者更新过程对用户请求的影响。在一些测试场景中,如果你不需要在 TiKV 滚动升级或者修改配置滚动更新过程中等待 TiKV 上的 Region Leader 迁移,想要加速升级或者更新过程,可以将 TidbCluster 定义中的 spec.tikv.evictLeaderTimeout
字段设置为一个很小的值。
spec: tikv: evictLeaderTimeout: 10s
关于该字段更多的说明,见配置 TiKV 平滑升级。
警告
该操作会导致部分用户请求失败,不建议在生产环境中使用。