前言
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节点的容器并不是直接使用服务器的网卡进行通信，而是又生成了一个新的网络环境。本来虚拟机就使用的是虚拟网卡，然后又在虚拟机上再次生成虚拟网卡，这样一来就更是乱成一锅粥了。k8s为什么不直接使用服务器上的网卡直接通信呐？我的理解是k8s希望将POD给封装起来，需要对外提供服务的时候是通过统一的接口服务，而不是说直接将POD给暴露出去。另外容器产生的快删除的也快，IP地址频繁的更换，会出现影响现有物理网络的情况。最后还因为如果多台Node节点之间的POD需要通信，就需要让不同Node节点之间的POD处在一个互联互通的网络环境中，于是就需要在物理网络的基础上再生成一个供POD之间互联的网络环境。