成功运行处于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镜像的默认存储目录。

  • 1
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
Pod 处于 CrashLoopBackOff 状态通常是由于容器在启动后立即崩溃或退出导致的。kube-proxy 是 Kubernetes 中的一个组件,负责实现集群内部的网络代理和负载均衡功能。当 kube-proxy 所在的 Pod 处于 CrashLoopBackOff 状态时,可能会导致集群内部的网络通信出现问题。 要解决 kube-proxy Pod 的 CrashLoopBackOff 状态,可以按照以下步骤进行排查和修复: 1. 查看 Pod 的日志:使用 kubectl logs 命令查看 kube-proxy Pod 的日志,可以获取更多关于崩溃原因的信息。例如,执行以下命令获取 kube-proxy Pod 的日志: ``` kubectl logs <kube-proxy-pod-name> -n <namespace> ``` 2. 检查容器配置:检查 kube-proxy 容器的配置是否正确。确保容器的启动命令、环境变量和配置文件等都正确设置。 3. 检查资源限制:检查 kube-proxy Pod 的资源限制是否过高,可能导致 Pod 在启动时无法满足资源需求而崩溃。可以尝试调整资源限制或增加集群的资源配额。 4. 检查依赖组件:检查 kube-proxy 所依赖的其他组件(如 kubelet、etcd 等)是否正常运行。如果依赖组件出现故障或配置错误,可能会导致 kube-proxy Pod 无法正常启动。 5. 检查网络配置:检查集群的网络配置是否正确,包括网络插件、网络策略等。错误的网络配置可能导致 kube-proxy Pod 无法正常工作。 6. 重启 kube-proxy Pod:如果以上步骤都没有解决问题,可以尝试删除并重新创建 kube-proxy Pod。执行以下命令删除 kube-proxy Pod: ``` kubectl delete pod <kube-proxy-pod-name> -n <namespace> ``` 以上是解决 kube-proxy Pod 处于 CrashLoopBackOff 状态的一般步骤,具体的解决方法可能因实际情况而异。如果问题仍然存在,建议查看更详细的日志信息或向 Kubernetes 社区寻求帮助。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值