troubleshooting

包括 DOK 以及任何服务、组件的问题，请非常仔细地查看日志或者事件，这是排查问题的最基础的思路，可以通过 DOK 提供的 dok longAnalyze 命令对日志进行分析，可以针对一些关键词如 Error, Warn 等等进行问题的检索。

DOK 使用到的一些 App 对系统软件有一定要求，比较常见的问题是 Longhorn 使用的 iscsi 软件没有安装成功。发生这种问题的可能性很多，比如系统软件依赖冲突、版本冲突等等，属于比较棘手的问题，DOK 是无法保障不同类型的机器和系统可以100%安装成功的，所以出现问题的话，需要针对性分析一下。

可能会遇到Longhorn一直没有创建成功，依赖Longhorn提供存储的Minio, Prometheus, Harbor, n9e等也无法正常创建

可以看到DOK安装各种App的时候，会报一些超时的错误

这里可以看到DOK安装iscsi遇到问题

一般 iscsi 遇到问题的话，需要在所有 worker 节点执行下面的命令，这个命令也不是100%能够正常安装成功的，取决于机器本身的软件以及内网 yum 源里的软件源等等，如果遇到进一步的问题，需要更多的分析。

yum install -y bash curl iscsi-initiator-utils util-linux-ng

安装完 iscsi 之后，需要先卸载所有安装失败的 App，一般就是 helm uninstall，如果涉及到 PV/PVC 的话，还需要手动删除，最后重新再安装一次，相关的内容，可以查看文档的 helm 章节。

这个也是典型的 ssh 问题，请检查集群的几个机器是否能够正常通过 ssh 访问，如下图，这个 ip 的机器明显已经有问题了。

这个是典型的 ssh 命令超时的报错，遇到这种情况，DOK 能否直接重跑，需要参考本文里的 「DOK遇到错误能否直接重跑」 这一节，如果某个进程已经启动了，最好是把进程停掉再重跑 DOK。

可以先通过命令 kubectl get node -o wide 查看第一个 controlplane 是否已经安装成功，如下图，说明第一个 controlplane 已经部署完毕了，发生的错误可能是因为第二个 controlplane 或者是安装 worker 的时候再报错，这时候 DOK 就不支持直接重跑了，如果第一个 controlplane 都没有安装成功，那么 DOK 才可以直接重跑。

如果在 controlplane 已经安装完成了至少一个的情况下，还想重跑 DOK，可以先在各个 controlplane 节点上执行 yes | kubeadm reset，并且删除各个节点上的 DOK 安装包，然后方可直接重跑 DOK。

如果不希望再重跑了，就得卡在哪个步骤然后手动去完成后面的部署工作，比如手动安装网络插件 Flannel，手动安装各种 Helm 应用。

# 在worker节点操作，仅仅是举个例子，具体的命令在dok的日志输出会给出
kubeadm join 127.0.0.1:8443 --token 0n05f6.hpdp60u0m7jxr9vb --discovery-token-ca-cert-hash sha256:37227e3bc98db919b156f74ac1b1691018b3202e530e2242051d31ae034bf985 --certificate-key 0037c3eedc51e918b671ce77beb3198a9716e11119389a1fffceca5f4e2aec73
# 在master0
# 手动安装flannel
cd /root/dok-release/network/
kubectl apply -f kube-flannel.yml
# 手动安装各种helm组件，举个例子，手动安装ingress-nginx
cd /root/dok-release/app
helm install ingress-nginx -n ingress-nginx --create-namespace ingress-nginx --wait -f ingress-nginx/dok-values.yaml

DOK 执行过程中，会尝试会修改一些内核参数，以满足 kubeadm 的需求，但是依然不能100%确定能完全修改成功（原因可能是一些机器运维会有一些强制手段来确保内核参数不被修改），因此如果在安装过程中报错了，查看日志，可以去对应的主机上进行内核参数的修改，或者与机器运维协商一些参数的配置问题，下图展示的是 /proc/sys/net/bridge/bridge-nf-call-iptables 无法被正常修改成1的错误。

如果是在 kubeadm 的层面报错，可以查看对 kubeadm 进行故障排查。

节点一直处于 NotReady 的状态，查看 Kubelet 的日志，发现一直在报错，可以检查一下 Containerd 的日志，如果有关于 CNI 的报错，可以检查一下 /opt/cni/bin/ 和 /etc/cni/net.d 两个目录，如果都正常的安装了 CNI 的组件，重启一下 Containerd 即可。

Grafana 上没有找到 Minio 等组件的监控面板，可能是 ConfigMap 没有创建成功，可以查询一下 DOK 的日志，相关的配置是否已经生产。

使用 kubectl-view-allocations 报错，原因是插件默认不支持 Centos7，kubectl-view-allocations#135, 暂时没有重新编译和修复的计划。

kubeadm 会检测主机名，如果不符合规则，这一步是会报错的，改好主机名之后，重新执行 dok createCluster 即可。

dok 展示的日志会同时在终端以及写入文件 /tmp/dok.log，执行 dok 命令的终端退出也不会影响进程的执行，可以通过 tailf /tmp/dok.log 继续查看，dok 进程会在后台一直执行直到成功或者遇到错误退出。

默认情况下 DOK 会尝试进行 Nginx 的安装，DOK 中自带的 rpm 包 Nginx 的版本是1.20.1，如果无法正常安装 Nginx，可以在日志中查看并且定位，有可能是本机已经安装有 Nginx 了，并且版本低于 1.10，建议升级。

DOK 默认会对集群机器进行一系列的检查，按照报错的信息整改主机的配置即可，如果不希望做检查，可以加上 --noCheck。

主机的 swap 没有关闭，从报错中找到问题主机，在主机上执行 swapoff -a。

DOK 默认会对集群机器进行一系列的检查，按照报错的信息整改主机的配置即可，如果不希望做检查，可以加上 --noCheck，不建议直接跳过机器检查，否则创建的集群可能会因为不标准化而出现各种问题。

这是主机密码填错了，目前 DOK 如果通过密码安装的话，所有主机的密码都必须一致。

免密模式下，很容易忽略，如果 master0 同时作为执行机，master0 也要可以免密 localhost。

如果不填密码，DOK 会默认读取 /root/.ssh/id_rsa，如果又没有配置好机器免密，就会报错，可以加上 --password 或者配置免密解决，具体查看 dok createCluster -h 查看具体的选项。