故障一：Coredns CrashLoopBackOff 导致无法成功添加工作节点的问题或者如图一或图二

 解决方法：

先通过这个命令  kubectl get pods -n kube-system -o wide  查看k8s各个服务的状态

出现CrashLoopBackOff,表明容器崩溃，需要进一步查看日志，使用“kubectl logs”：如下

kubectl log -f coredns-5c98db65d4-8wt9z -n kube-system

查看具体错误如     github.com/coredns/coredns/plugin/kubernetes/controller.go:322: Failed to list *v1.Namespace: Get https://10.96.0.1:443/api/v1/namespaces?limit=500&resourceVersion=0: dial tcp 10.96.0.1:443: connect: no route to host

这问题很有可能是防火墙(iptables)规则错乱或者缓存导致的，可以依次执行以下命令进行解决：

systemctl stop kubelet

systemctl stop docker

iptables --flushiptables -t nat --flush

systemctl start kubelet

systemctl start docker

故障二

kubectl 执行命令报“The connection to the server localhost:8080 was refused”

作为集群管理的核心，工作节点上的kubectl可能一上来就崩溃了，如下图，

 出现这个问题的原因是kubectl命令需要使用kubernetes-admin的身份来运行，在“kubeadm init”启动集群的步骤中就生成了“/etc/kubernetes/admin.conf”。

解决方法：

将主节点中的【/etc/kubernetes/admin.conf】文件拷贝到工作节点相同目录下：

#复制admin.conf，请在主节点服务器上执行此命令

scp /etc/kubernetes/admin.conf 172.16.2.202:/etc/kubernetes/admin.conf

scp /etc/kubernetes/admin.conf 172.16.2.203:/etc/kubernetes/admin.conf

最后，分别在工作节点配置环境变量

#设置kubeconfig文件export KUBECONFIG=/etc/kubernetes/admin.conf
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile

以上是基于kubeadm部署k8s出现问题时的解决方法，如果是基于单点式，即各个组件单独下载，部署则用如下方法

node节点都出现这个报错

（kubectl -s 10.0.0.101:8080 get pod）

故障三

网络组件flannel无法完成初始化

网络组件flannel安装完成后，通过命令查看时一直在初始化状态，并且通过日志输出内容如下所示

kubectl get pods -n kube-system -o wide
kubectl logs -f kube-flannel-ds-amd64-hl89n -n kube-system

 具体错误日志如下：

Error from server: Get https://172.16.2.203:10250/containerLogs/kube-system/kube-flannel-ds-amd64-hl89n/kube-flannel?follow=true: dial tcp 172.16.2.203:10250: connect: no route to host

这时，我们可以登录节点所在的服务器，使用以下命令来查看目标节点上的kubelet日志：

journalctl -u kubelet -f

注意：journalctl工具可以查看所有日志，包括内核日志和应用日志。

 通过日志，我们发现是镜像拉取的问题。对此，大家可以参考上文中镜像拉取的方式以及重命名镜像标签来解决此问题，当然也可以通过设置代理来解决此问题

故障四

部分节点无法启动pod

有时候，我们部署了应用之后，发现在部分工作节点上pod无法启动(一直处于ContainerCreating的状态)：

 通过排查日志最终我们得到重要信息如下所示：

NetworkPlugin cni failed to set up pod "demo-deployment-675b5f9477-hdcwg_default" network: failed to set bridge addr: "cni0" already has an IP address different from 10.0.2.1/24

这是由于当前节点之前被反复注册，导致flannel网络出现问题。可以依次执行以下脚本来重置节点并且删除flannel网络来解决：

kubeadm reset    #重置节点systemctl stop kubelet && systemctl stop docker

&& rm -rf /var/lib/cni/ && rm -rf /var/lib/kubelet/* && rm -rf /var/lib/etcd && rm -rf /etc/cni/

&& ifconfig cni0 down && ifconfig flannel.1 down && ifconfig docker0 down

&& ip link delete cni0 && ip link delete flannel.1

systemctl start docker

或者如下报错以及解决办法

Kubernetes之network: failed to set bridge addr: "cni0" already has an IP address different from xxx问题

在使用Kubernetes部署应用时发现有Pod一直不能创建成功，使用kubectl describe pods <pod-name> -n <namespace>得到的结果如下图

 从上面的截图中看到问题出现在给Pod分配IP上，意思是cni0的IP不同于10.244.9.1/24，下面我们进入到node9中使用ifconfig命令查看IP信息，结果如下：

 从上面的图中我们可以看到flannel.1的IP为10.244.9.0，然后我们又使用cat /run/flannel/subnet.env，该文件内容如下

 其实现在的问题就比较明确了，我们使用的Overlay network为Flannel，也就是说Pod的IP地址段应该在Flannel的subnet下，而现在我们看到cni0的IP地址段与flannel subnet地址段不同，所以就出现了问题。

解决方案

• 方法1是将cni0的IP段修改为10.244.9.1。
• 方法2是将这个错误的网卡删除掉，之后会自动重建。
  下面我们删除错误的cni0，然后让它自己重建，操作过程如下：

      1. sudo ifconfig cni0 down
      2. sudo ip link delete cni0

以上两种都是网络flannel出现问题，根源是一致的。