Kubernetes 上的 TiDB 常见部署错误

创建集群后，如果 Pod 没有创建，则可以通过以下方式进行诊断：

创建备份恢复任务后，如果 Pod 没有创建，则可以通过以下方式进行诊断：

kubectl get backups -n ${namespace}
kubectl get jobs -n ${namespace}
kubectl describe backups -n ${namespace} ${backup_name}
kubectl describe jobs -n ${namespace} ${backupjob_name}
kubectl describe restores -n ${namespace} ${restore_name}

Pod 处于 Pending 状态，通常都是资源不满足导致的，比如：

使用持久化存储的 PD、TiKV、TiFlash、Pump、Monitor、Backup、Restore Pod 使用的 PVC 的 StorageClass 不存在或 PV 不足
Kubernetes 集群中没有节点能满足 Pod 申请的 CPU 或内存
PD 或者 TiKV Replicas 数量和集群内节点数量不满足 tidb-scheduler 高可用调度策略

此时，可以通过 kubectl describe pod 命令查看 Pending 的具体原因：

kubectl describe po -n ${namespace} ${pod_name}

如果是 CPU 或内存资源不足，可以通过降低对应组件的 CPU 或内存资源申请，使其能够得到调度，或是增加新的 Kubernetes 节点。

PVC 的 StorageClass 不存在

如果是 PVC 的 StorageClass 找不到，可采取以下步骤：

通过以下命令获取集群中可用的 StorageClass：
使用下述方式更新配置文件：
- 如果是启动 tidbcluster 集群，运行 kubectl edit tc ${cluster_name} -n ${namespace} 进行集群更新。
- 如果是运行 backup/restore 的备份/恢复任务，首先需要运行 kubectl delete bk ${backup_name} -n ${namespace} 删掉老的备份/恢复任务，再运行 kubectl apply -f backup.yaml 重新创建新的备份/恢复任务。
将 Statefulset 删除，并且将对应的 PVC 也都删除。
```
kubectl delete pvc -n ${namespace} ${pvc_name}
```

可用 PV 不足

如果集群中有 StorageClass，但可用的 PV 不足，则需要添加对应的 PV 资源。对于 Local PV，可以参考本地 PV 配置进行扩充。

tidb-scheduler 针对 PD 和 TiKV 定制了高可用调度策略。对于同一个 TiDB 集群，假设 PD 或者 TiKV 的 Replicas 数量为 N，那么可以调度到每个节点的 PD Pod 数量最多为 M=(N-1)/2（如果 N<3，M=1），可以调度到每个节点的 TiKV Pod 数量最多为 M=ceil(N/3)（ceil 表示向上取整，如果 N<3，M=1）。

如果 Pod 因为不满足高可用调度策略而导致状态为 Pending，需要往集群内添加节点。

Pod 处于 CrashLoopBackOff 状态意味着 Pod 内的容器重复地异常退出（异常退出后，容器被 Kubelet 重启，重启后又异常退出，如此往复）。定位方法有很多种。

查看 Pod 内当前容器的日志

kubectl -n ${namespace} logs -f ${pod_name}

查看 Pod 内容器上次启动时的日志信息

确认日志中的错误信息后，可以根据，tikv-server 启动报错，中的指引信息进行进一步排查解决。

在确认该 TiKV 应作为新节点加入集群、且 PV 上的数据应该删除后，可以删除该 TiKV Pod 和关联 PVC。TiKV Pod 将自动重建并绑定新的 PV 来使用。集群本地存储配置中，应对机器上的本地存储删除，避免 Kubernetes 使用机器上遗留的数据。集群运维中，不可强制删除 PV ，应由 local volume provisioner 程序管理。用户通过创建、删除 PVC 以及设置 PV 的 reclaimPolicy 来管理 PV 的生命周期。

ulimit 不足

另外，TiKV 在 ulimit 不足时也会发生启动失败的状况，对于这种情况，可以修改 Kubernetes 节点的 /etc/security/limits.conf 调大 ulimit：

root        soft        nofile        1000000
root        soft        core          unlimited
root        soft        stack         10240

PD Pod `nslookup domain failed`

你可以在 PD Pod 看到如下类似日志：

Thu Jan 13 14:55:52 IST 2022
;; Got recursion not available from 10.43.0.10, trying next server
;; Got recursion not available from 10.43.0.10, trying next server
;; Got recursion not available from 10.43.0.10, trying next server
Address: 10.43.0.10#53
** server can't find basic-pd-0.basic-pd-peer.default.svc: NXDOMAIN
nslookup domain basic-pd-0.basic-pd-peer.default.svc failed

当集群同时满足以下两个条件时，这种错误会出现：

在 /etc/resolv.conf 有两个 nameserver，并且第二个不是 CoreDNS 的 IP。
PD 版本是以下版本：
- 不小于 v5.0.5 的版本。
- 不小于 v5.1.4 的版本。
- 全部 5.3 版本.

解决这个问题需要在 TidbCluster 添加 startUpScriptVersion：

出现这个问题的原因是镜像里的 nslookup 版本发生了变化（详情参考 #4379）。当配置了 startUpScriptVersion 为 v1 时，TiDB Operator 会使用 dig 替换 nslookup 来检查 DNS。

假如通过日志无法确认失败原因，ulimit 也设置正常，那么可以通过进行进一步排查。

部署错误