首页 > TAG信息列表 > CrashLoopBackOff
crashloopbackoff排查
CrashLoopBackOff 是k8s中常见报错，表明pod在不断重启 常见故障原因: 1.资源不足 2.容器想要使用的文件已被锁定 3.数据库被锁定 4.容器中引用的脚本或程序不存在 5.pod中init-container报错 6.加载config文件报错 7.文件系统配置错误 8.网络故障，如DNS等 排错和解决 1.kubectl desck8s启动nginx容器错误CrashLoopBackOff
这里主要是因为是自己做的一个的一个nginx镜像（这里就不重复了） ~]# kubectl apply -f mynginx.yaml daemonset.apps/mynginx created CrashLoopBackoff ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODEPod状态异常排查问题集-CrashLoopBackOff状态排查思路
镜像代码有问题：在使用dockerbuild的构建玩镜像，先在本地基于这个镜像docker run先启动容器看看是否可以正常启动，如果能够启动那说明这个镜像是没问题的，如果启动不了说明构建的这个镜像是有问题的。 然后可以去查看dockerfile的语法有没有问题，或者编译打包的时候这个代码有没有编记录一次修复k8s pod长时间处于crashloopbackoff状态问题
前言 这周一，新年后上班第一个完整周，年前一波需求已经评审过了，方案也已经制定好，所以年后就开始了如火如荼的写bug阶段，正在写go bug，突然企业微信，tapd弹出一条消息，提了一个缺陷单，处理人是我，顿时预感不妙，果然5秒后，测试同学那微笑的头像弹出来，嗯，完蛋，bug来了。测试同学告诉我，有一个flannel CrashLoopBackOff原因
系统日志 Feb 25 14:20:31 ubuntu systemd[1]: Started libcontainer container 15b23c11b8fee60349fd84e928d04d6fd26b9f04c0aadbc5aebde97d77765c8f.Feb 25 14:20:31 ubuntu kernel: [166679.978936] IPVS: Creating netns size=2200 id=10507Feb 25 14:20:31 ubuntu kubelet[32kubernetes部署Ubuntu pod提示CrashLoopBackOff
pod信息 apiVersion: v1 kind: Pod metadata: name: my-vm01 spec: containers: - name: vm image: ubuntu imagePullPolicy: IfNotPresent 但是一直无法启动，查看原因是pod的存在时间很短，如果让pod持续运行，需要新增一条指令让他一直运行 参考https://serverfault.ckubernetes使用flannel网络插件服务状态显示CrashLoopBackOff
使用Kubeadm安装K8s集群，在安装flannel网络插件后，发现pod: kube-flannel-ds 一直是CrashLoopBackOff 报错内容如下： log is DEPRECATED and will be removed in a future version. Use logs instead. I0823 03:28:21.342352 1 main.go:514] Determining IP address of defaultkubernetes redis pod CrashLoopBackOff修复心得
前言 实验环境的kubernetes服务器物理机突然断电，重启后helm 部署的harbor出现了启动故障，首先查看harbor 相关容器运行状态： 解决方法 前面两个CrashLoopBackOff的容器，可以的使用命令删除容器，就可以解决，关键的是redis 容器，删除是解决不了的。使用命令查看容器的日志。 [root@master ~