成功运行处于CrashLoopBackOff异常状态的kube-controller-manager，错误为Back-off restarting failed container

本来之前搭建好了k8s集群，然后之前的镜像存放在docker的默认目录——/var/lib/docker(这个目录是系统盘的目录)。因为之后要把容器化的应用部署在k8集群上，如果不修改docker镜像的存放位置，那么系统盘的空间肯定不够用，所以将docker镜像存放在数据盘上。

我把docker镜像转存到数据盘的过程是这样的：
1、停掉了docker服务
2、先把docker默认目录即/var/lib/docker下的文件先拷贝到了新的目录下，然后我就把/var/lib/docker下的文件删除了(之后的流程我就不介绍了，因为也失败了)，这时候我的界面是这样的：

其实到这一步，我就已经感觉会出错了(因为我觉得最开始还应该把kuberlet服务关掉)，我还是把流程执行完了。
果不其然，等我把docker镜像的路径配置完之后，我重启了docker服务，就出现了接下来的情况：

这应该是kubelet的服务没有开启或者因为之前的错误操作kubelet启动不起来了，我这里遇到的是后者的原因。然后我使用docker info查看docker镜像的存储路径，发现还是docker镜像的默认存储目录。

这时我就想觉得最后可能会失败了，因为我之前已经把/var/lib/docker目录下的所有镜像删除了，而之前k8s就是从这个目录加载镜像的，所以此时的集群肯定受影响了。但现在集群状态查看不了，因为kubelet服务服务启动不起来，集群中的节点信息和pod信息全都没法通过kubectl命令查看。(这种情况有点儿类似k8s集群搭建好了，但是由于误操作，把docker本地镜像库中的镜像不小心删除了一个或几个)。那我就跟大家分享一下这种情况下如何恢复健康的k8集群。

docker拉取镜像

先把所需镜像拉取到docker本地仓库中，确保docker本地仓库中的镜像与自己机器上kubeadm config images list显示的镜像一致，然后使用systemctl restart docker和systemctl start kubelet重启docker服务并启动 kubelet服务，这个时候就可以通过kubectl查看集群状态了。

可以看到我的k8s的节点和pod信息都处于非正常状态，过了一会儿，集群中的pod状态变成了如下图片展示的情况：

只要把这个pod的运行状态修改为Running，k8s集群应该就能正常运行了。

CrashLoopBackOff异常状态修复

因为我之前在coredns的相关pod上遇到过此类CrashLoopBackOff状态，我当时采取的解决方案就是先把这个pod给删除掉，然后k8s集群会重新创建该pod，然后该pod的状态就变成Running了。然后我先把上图中名称为kube-controller-manager-10-24-2-222的pod删除掉了，但是待其重新创建启动后，该pod还是CrashLoopBackOff状态。
接下来，我使用kubectl logs kube-controller-manager-10-24-2-222 -n kube-system命令看了一下该pod的相关日志信息，看日志信息应该是该pod对应的容器处于创建、运行、启动失败这种情况。

然后我使用docker ps -a看了一下docker容器的情况如下图所示，非常混乱。

可以看到与kube-controller-manager相关的pod也是处于错误的状态，还有其他几个pod因某些原因未能正常运行。
这里我采取的解决方案就是：停掉所有正在运行的容器 + 删除所有已经停止的容器，之后所有的容器会被k8s集群重新构建运行，原先某些处于非正常状态的pod都可以正常运行。
具体的执行步骤是：
1、先暂停kubelet服务。因为这个服务运行的话会有一些容器停不掉，并且也无法删除。执行命令如下：

systemctl stop kubelet

2、停掉或杀死所有正在运行的容器。

docker kill $(docker ps -a -q)

3、删除所有已经停止的容器。

docker rm $(docker ps -a -q)

4、再次查看k8s集群的状态。先通过systemctl start kubelet命令启动kubelet服务，然后通过运行kubectl get nodes和kubectl get pods -n kube-system命令我们发现所有的节点和pod均处于正常的状态，k8s集群再次成功运行。