对kubeadm进行故障排查

前言

k8s集群在安装过程中会遇到各种问题，很难有一个非常全的QA能将所有问题都囊括进来，K8S集群的部署问题，很多都出现在网络插件相关，因为k8s.io网站镜像需要使用国内源下载，另外网络插件也比较难理解。这里列举几个问题。

Node节点主机名保证唯一性

Node节点之间要保证主机名的唯一性，同时整个k8s集群的版本最好是保持完全一致，比如全部都使用1.28.2，这样就避免非常多不必要的故障报错。同时因为版本不兼容的问题导致浪费大量时间有点浪费，这种故障对技术提升帮助不大。

缺少ebtables或者ethtools可执行文件

yum install ethtool ebtables

停留在waiting for the control plane to become ready

要么是容器运行时和kubelet两者cgroup驱动不一致，要么是网络不通。如果还有问题就需要查看系统日志和容器日志的报错来排错了。

Pod处于CrashLoopBackoff或者RunContainerError

查看容器日志报的是什么错，一般来说要时刻关注日志的输出。正常情况下，k8s和容器的日志都需要保证没有错误才行。

总结

• 在解决kubeadm创建集群中的报错过程中，有两个日志需要格外的关注，一个是kubectl describe pod podname -n namespace来查看pod的详细情况和events报错日志，一个是直接到Node节点上查看报错POD的日志内容。
• k8s的报错中，和网络相关的报错是最多了，因为master和node节点的容器并不是直接使用服