kubernetes redis pod CrashLoopBackOff修复心得

前言

实验环境的kubernetes服务器物理机突然断电,重启后helm 部署的harbor出现了启动故障,首先查看harbor 相关容器运行状态:

解决方法

前面两个CrashLoopBackOff的容器,可以的使用命令删除容器,就可以解决,关键的是redis 容器,删除是解决不了的。

使用命令查看容器的日志。

[[email protected] ~]# 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的创建信息:

[[email protected] ~]# kubectl get pv | grep redis
pv006      100Gi      RWO            Recycle          Bound     default/redis-data-hub-redis-master-0
[[email protected] ~]# 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

进入到容器:

[[email protected] ~]# kubectl exec -it hub-redis-master-0 bash
I have no [email protected]:/$ 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自动重新建立就可以了。

原文地址:http://blog.51cto.com/m51cto/2344375

时间: 2024-08-30 16:40:34

kubernetes redis pod CrashLoopBackOff修复心得的相关文章

Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet

目录 Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet ReplicaSet Deployment控制器 创建Deployment Deployment更新 Deployment扩容 金丝雀发布 Deployment回滚 DaemonSet 定义 DaemonSet演示 redis-filebeat DaemonSet的滚动更新 Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet Kubernete

Kubernetes之Pod的生命周期

目录 Kubernetes之Pod的生命周期 理解Pod Pod内如何管理多个容器 Pod的使用 其他替代选择 Pod的持久性 Pod的终止 Init容器 Pause容器 Pod的生命周期 Pod的phase Pod的状态 容器探针 存活性探测 livenessProbe 就绪性探测 readnessProbe livenessProbe和readinessProbe使用场景 lifecycle Kubernetes之Pod的生命周期 理解Pod Pod是kubernetes中你可以创建和部署的

kubernetes之pod超详细解读--第二篇(三)

8.资源对象对pod的调度 ??在kubernetes集群中,pod基本上都是容器的载体,通常需要通过相应的资源对象来完成一组pod的调度和自动控制功能,比如:deployment.daemonSet.RC.Job等等.接下来小编将一一介绍这些资源对象如何调度pod. (1)Deployment/RC 自动化调度 ??Deployment/RC的主要功能之一就是自动部署一个容器应用的多个副本,以及持续监控副本数量,在集群内始终维持用户指定的副本数量.举例:(这里以deployment为例) ap

Kubernetes中Pod间共享内存方案

摘要:一些公共服务组件在追求性能过程中,与业务耦合太紧,造成在制作基础镜像时,都会把这些基础组件都打包进去,因此当业务镜像启动后,容器里面一大堆进程,这让Kubernetes对Pod的管理存在很大隐患.为了让业务容器瘦身,更是为了基础组件自身的管理更独立和方便,将基础组件从业务镜像中剥离并DaemonSet容器化部署.然而一些基础组件Agent与业务Pod之间通过共享内存的方式进行通信,同一Node中跨Pod的共享内存方案是首先要解决的问题. 为什么要将公共基础组件Agent进行DaemonSe

Kubernetes之Pod控制器应用进阶

目录 Kubernetes之Pod控制器应用进阶 Pod控制器下spec常用字段 标签(Labels)和标签选择器(LabelSelector) 标签 标签选择器 Kubernetes之Pod控制器应用进阶 Pod控制器下spec常用字段 #containers [[email protected] ~]# kubectl explain pods.spec.containers. name <string> -required- #容器名,必选字段 image <string>

kubernetes之pod健康检查

目录 kubernetes之pod健康检查 1.概述和分类 2.LivenessProbe探针(存活性探测) 3.ReadinessProbe探针(就绪型探测) 4.探针的实现方式 4.1.ExecAction 4.2.HTTPGetAction 4.3.TCPSocketAction 5.探测行为属性 6.扩展的探测机制 kubernetes之pod健康检查 1.概述和分类 pod通过两类探针来检查容器的健康状态.分别是LivenessProbe(存活性探测)和ReadinessProbe(就

Kubernetes基石-pod容器

引用三个问题来叙述Kubernetes的pod容器 1.为什么不直接在一个Docker容器中运行所有的应用进程. 2.为什么pod这种容器中要同时运行多个Docker容器(可以只有一个) 3.为什么k8s使用pod这种容器而不直接使用Docker容器 一个由多个进程进行组成的应用程序,无论是通过ipc(进程间通信)还是本地存储文件进行通信,都要求它们运行于同一台机器上.Docker容器非常像一台独立的机器,此时你可能认为在单个容器中运行多个进程是合乎逻辑的,然而在实践中这种做法并不合理. 容器被

Kubernetes之POD

什么是Pod Pod是可以创建和管理Kubernetes计算的最小可部署单元.一个Pod代表着集群中运行的一个进程. Pod就像是豌豆荚一样,它由一个或者多个容器组成(例如Docker容器),它们共享容器存储.网络和容器运行配置项.Pod中的容器总是被同时调度,有共同的运行环境.你可以把单个Pod想象成是运行独立应用的"逻辑主机"--其中运行着一个或者多个紧密耦合的应用容器--在有容器之前,这些应用都是运行在几个相同的物理机或者虚拟机上. 尽管kubernetes支持多种容器运行时,但

kubernetes之pod超详细解读--第一篇(三)

   小编在这里向各位博友道个歉,上篇文章确实写的有些应付,但怎么说,部署确实因人而异,而且很少有刚刚进公司就让你搭建一个集群,一般公司都有自己的集群,所以小编觉得,侧重点不应该在安装,应该在维护!虽然有些牵强,但小编保证,这一篇绝对有质量!希望看了小编的博客,大家对pod有更深入的认识.   这篇文章,小编打算介绍关于pod的11个重要的知识点,大家要有耐心的看下去哦!虽然内容比较多,有兴趣的朋友可以细细阅读,小编会尽可能的用比较容易理解的话和图,去介绍比较重要并且难以理解的地方. 1. po