kubernetes redis pod CrashLoopBackOff修复心得 精选 原创 喵来个鱼 2019-01-18 22:12:32 博主文章分类:kubernetes ©著作权 文章标签 kubernetes k8s redis CrashLoopBackOff 文章分类 运维 ©著作权归作者所有:来自51CTO博客作者喵来个鱼的原创作品,请联系作者获取转载授权,否则将追究法律责任 前言 实验环境的kubernetes服务器物理机突然断电,重启后helm 部署的harbor出现了启动故障,首先查看harbor 相关容器运行状态: 解决方法 前面两个CrashLoopBackOff的容器,可以的使用命令删除容器,就可以解决,关键的是redis 容器,删除是解决不了的。 使用命令查看容器的日志。 [root@master ~]# kubectl logs hub-redis-master-0 Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename> 简单理解:文件格式损坏,做个备份,使用命令修复。 ** 关键问题是pod启动不起来,不能直接进去修复,所以关键问题还是让redis的容器启动起来,想让pod起来就必须不让容器加载之前的appendonly.aof文件,找到appendonly.aof重命名,让redis容器重新生成appendonly.aof。** 查找appendonly.aof 接着查看容器的描述: # kubectl describe po hub-redis-master-0 可以获取到需要的信息: /bitnami/redis/data #aof在容器上的路径 Volumes: #redis pod的pvc信息 redis-data: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: redis-data-hub-redis-master-0 确认redis 容器使用的 pv,获取pv的创建信息: [root@master ~]# kubectl get pv | grep redis pv006 100Gi RWO Recycle Bound default/redis-data-hub-redis-master-0 [root@master ~]# kubectl describe pv pv006 Name: pv006 Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-cOnfiguration={"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"pv006","namespace":""},"spec":{"accessModes":["ReadWriteOnce"],"capac... pv.kubernetes.io/bound-by-cOntroller=yes Finalizers: [kubernetes.io/pv-protection] StorageClass: Status: Bound Claim: default/redis-data-hub-redis-master-0 Reclaim Policy: Recycle Access Modes: RWO Capacity: 100Gi Node Affinity: <none> Message: Source: Type: NFS (an NFS mount that lasts the lifetime of a pod) Server: 192.168.2.4 Path: /volume1/harbor/nfs6 ReadOnly: false Events: <none> 这里可以找到nfs对应的路径,直接进入nfs服务器对应路径下重命名appendonly.aof,redis的pod就立即启动状态为running了,接下来就是修复appendonly.aof。 修复appendonly.aof 进入到容器: [root@master ~]# kubectl exec -it hub-redis-master-0 bash I have no name!@hub-redis-master-0:/$ ls /bitnami/redis/data/ appendonly.aof appendonly.bak.aof dump.rdb 修复 redis-check-aof --fix /bitnami/redis/data/appendonly.bak.aof 0x 10f69: Expected prefix '*', got: ' AOF analyzed: size=10316900, ok_up_to=69481, diff=10247419 This will shrink the AOF from 10316900 bytes, with 10247419 bytes, to 69481 bytes Continue? [y/N]: y Successfully truncated AOF 现在就可以把正在使用的appendonly.aof 重命名,把修复后的aof命名为appendonly.aof ,删除容器,kubernetes自动重新创建redis容器,如果其它容器还是CrashLoopBackOff,这可能是redis没有启动导致的,redis修复好后,删除CrashLoopBackOff的容器,kubernetes自动重新建立就可以了。 赞 收藏 评论 分享 举报 上一篇:kubernetes之helm部署harbor 下一篇:kubernetes 部署 lnmp+discuz 提问和评论都可以,用心的回复会被更多人看到 评论 发布评论 全部评论 () 最热 最新 相关文章 kubernetes-dashboard crashloopbackoff 你好,小白!欢迎来到K8S的世界。K8S,也就是Kubernetes,是当今最流行的开源容器编排平台。你在使用中遇到了【kubernetes-dashboard crashloopbackoff】的问题,这是一个相对常见的问题。别担心,我会帮助你解决它。一、整体流程在解决问题之前,我们先简单了解一下涉及的步骤和整体流程:确认问题:确认Kubernetes Dashboard的状态,查看Pod的日志 Pod 错误信息 不兼容 flannel CrashLoopBackOff原因 系统日志Feb2514:20:31ubuntusystemd[1]:Startedlibcontainercontainer15b23c11b8fee60349fd84e928d04d6fd26b9f04c0aadbc5aebde97d77765c8f.Feb2514:20:31ubuntukernel:[166679.978936]IPVS:Creatingnetnssize=2200id=10 codedns kubernetes flannel kubeadm coredns CrashLoopBackOff 报错 1.kubectl logs -f coredns-99b9bb8bd-47mvf -n kube-system 从这篇文章得到提示,coredns pod会取宿主机的/etc/resolv.conf里面定义的nameserver作为自己的upstream server。而ubuntu的这个文件定义 ubuntu linux 自动生成 k8s crashloopbackoff Kubernetes (K8S)是一个用于管理容器化应用程序的开源平台。在开发和部署应用程序时,可能会遇到一些问题,例如应用程序经常重启且无法正常运行。其中一种常见的问题是`crashloopbackoff`。在本篇科普文章中,我将详细介绍`crashloopbackoff`的定义、原因和解决方案,并提供相应的代码示例。### 什么是crashloopbackoff?当一个容器在启动后立即崩 应用程序 Pod 解决方案 k8s错误CrashLoopBackOff 序言2020年1月1日就收到一个故障,注定不是平凡的一年。所以呢,决定年后戒烟。。。至于是哪一年的年后,我没说。。。哈哈哈CrashLoopBackoff在创建一个pod之后,出现一个报错,都是按照套路来的,怎么可能会报错呢。。查看一下相关的日志看看(kubectldescribepodstest-pod):看最后的事件就是不停的重启失败的容器,查看一下容器的日志:ark,size_16,text java flannel一直处于crashloopbackoff 在部署flannel网络插件时,发现flannel一直处于crashloopbackoff状态:bashroot@fv120100manifestkubectlgetpodsnkubesystemNAMEREADYSTATUSRESTARTSAGEkubeflannelds2xsqv0/1CrashLoopBackOff55m13skubeflanneldsp7j2d0/1CrashLoopBac flannel crashloopbackoff k8s部署redis时报CrashLoopBackOff 标题:解析Kubernetes部署Redis时出现的CrashLoopBackOff错误摘要:本文将为读者介绍如何使用Kubernetes(简称K8s)来部署Redis,并讨论在部署过程中可能出现的CrashLoopBackOff错误。我们将学习如何识别和解决这个问题,并提供代码示例以帮助读者更好地理解。引言:Kubernetes是一个开源的容器编排引擎,可以帮助我们管理和部署容器化应用 Pod Redis 应用程序 Kubernetes pod状态出现CrashLoopBackOff 的原因 做个实验:$ kubectl run crasher --image=rosskukulinski/crashing-app查看这个pod的状态:$ kubectl get pods NAME READY STATUS RESTARTS AGE crasher-2443551393-vuehs 0/1 CrashLoopBackOff 2 54sCrashLoopBackOff的含义是,Kuber Kubernetes docker 5e f5 kubernetes使用flannel网络插件服务状态显示CrashLoopBackOff 使用Kubeadm安装K8s集群,在安装flannel网络 edn 初始化 nginx K8s CrashLoopBackOff 如何排障? 整理排故相关笔记分享给小伙伴。博文内容涉及:什么是 CrashLoopBackOff?如何对 Cra kubernetes docker linux 重启 github kubernetes启动Pod遇到CrashLoopBackOff的解决思路 1.问题现状通过命令行工具kubectl 获取异常容器[root@master ~]# kubectl get pods -n k8s kubernetes linux 命令行工具 4s ingress-nginx部署状态为CrashLoopBackOff 问题排查 ingress-nginx部署状态为CrashLoopBackOff 问题排查,说起来这个问题挺坑的,kubernet nginx IP TCP 7 张图解 CrashLoopBackOff,如何发现问题并解决它? 是一种 Kubernetes 状态,表示 Pod 中发生的重启循环:Pod 中的容器已启动,但崩溃然后又重新启 kubernetes docker 容器 重新启动 重启 K8s问题【flannel一直重启问题,CrashLoopBackOff】 kubectl describe 命令查看Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 13m ... Kubernetes k8s kubernetes CrashLoopBackOff 如何定位 kubernetes pause 一、什么是PODPod是Kubernetes最重要的基本概念,我们看到每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。二、POD的生命周期三、pause容器 用"kubernetes/pause"镜像为每 Pod nginx 重启 kubernetes 部分 flannel pod CrashLoopBackoff kubernetes endpoint endpointendpoint是k8s集群中的一个资源对象,存储在etcd中,用来记录一个service对应的所有pod的访问地址。service配置selector,endpoint controller才会自动创建对应的endpoint对象;否则,不会生成endpoint对象.例如,k8s集群中创建一个名为hello的service,就会生成一个同名的endpoint对象,ENDPOINTS Pod Endpoint IP k8s中的Pod的状态CrashLoopBackOff 现象如下: [root@k8s1 ~]# kubectl get pod NAME READY STATUS RESTARTS AGE eureka-server-65695bbdc8-49b6v 0/1 CrashLoopBackOff 5 4m32s [root@k8s1 ~]# kubectl spring tomcat java jar apache k8s 查看 镜像 k8s镜像crashloopbackoff 文章目录问题现象问题分析问题解决拓展总结 问题现象在一次测试ConfigMap的过程中,我想起一个单容器的pod,简单的打印出容器内所有的环境变量,以验证ConfigMap的传递。结果pod起来以后一直出现CrashLoopBackOff的状态。这里为了抽离出问题的本质,去掉干扰项,将pod的生成yaml文件简化如下apiVersion: v1kind: Podmetadata: nam k8s 查看 镜像 重启 Pod ide k8s yaml 使用本地镜像 k8s镜像crashloopbackoff 前言这周一,新年后上班第一个完整周,年前一波需求已经评审过了,方案也已经制定好,所以年后就开始了如火如荼的写bug阶段,正在写go bug,突然企业微信,tapd弹出一条消息,提了一个缺陷单,处理人是我,顿时预感不妙,果然5秒后,测试同学那微笑的头像弹出来,嗯,完蛋,bug来了。测试同学告诉我,有一个node组件,使用chaos注入故障,频繁杀掉主线程,大概会在第七轮杀掉主进程,pod会长时间处于 k8s yaml 使用本地镜像 kubernetes crashloop backoff container