K8s集群部署Spring Boot内嵌Redis触发CrashLoopBackOff如何解决

启用Redis配置后出现CRASH LOOP BACKOFF报错的核心原因如下：

• Spring Boot应用引入Redis依赖后会在启动时自动尝试连接Redis服务，当前配置未给业务容器注入正确的Redis连接参数，且同Pod多容器无启动顺序保证，业务容器可能在Redis、MySQL就绪前启动，连接失败直接退出触发重启循环。
• 同Pod部署的MySQL、Redis未配置数据存储挂载，MySQL 5.7默认写入系统目录会触发权限问题，直接导致容器启动失败。
• Redis配置的资源配额过低，100m CPU、100Mi内存无法满足Redis 6.0的最低运行要求，运行时极易触发OOM被Kubernetes杀死。
• 仅为业务应用创建了Service，Redis、MySQL没有稳定的服务发现地址，后续扩容、多副本部署时完全无法适配。

根据使用场景选择对应部署方式：

方案1：同Pod Sidecar部署（仅适用于本地测试、单实例演示场景） #

将Redis、MySQL作为Sidecar容器和业务应用放在同一个Pod内，修正配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-registration
spec:
  selector:
    matchLabels:
      app: user-registration
  replicas: 1
  template:
    metadata:
      labels:
        app: user-registration
    spec:
      containers:
        - name: user-registration
          image: user-registration:1.0
          ports:
          - containerPort: 8080
          env:
            - name: DB_HOST
              value: "127.0.0.1"
            - name: DB_NAME
              value: user_registration
            - name: DB_USERNAME
              value: root
            - name: DB_PASSWORD
              value: root
            # 按Spring Boot配置规则注入Redis连接参数
            - name: SPRING_REDIS_HOST
              value: "127.0.0.1"
            - name: SPRING_REDIS_PORT
              value: "6379"
        - image: mysql:5.7
          args:
            - "--ignore-db-dir=lost+found"
          name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: root
            - name: MYSQL_DATABASE
              value: user_registration
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
        - name: redis
          image: "docker.io/redis:6.0.5"
          resources:
              requests:
                cpu: 200m
                memory: 256Mi
              limits:
                cpu: 500m
                memory: 512Mi
          ports:
            - containerPort: 6379
              name: redis
      volumes:
        - name: mysql-data
          emptyDir: {}

注意：该方案使用emptyDir作为存储卷，Pod重启、调度时MySQL和Redis的数据会全部丢失，禁止用于生产环境。如果应用无内置连接重试逻辑，建议在业务容器启动命令中增加端口检测等待逻辑，避免中间件启动慢导致应用启动失败。

方案2：独立部署中间件（生产环境推荐） #

Redis、MySQL属于有状态服务，不要和无状态业务应用放在同一个Pod内，需单独部署并配置持久化存储：

1. 先单独部署Redis，创建对应的Deployment、Service和持久化卷声明：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:6.0.5
        ports:
        - containerPort: 6379
          name: redis
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 1
            memory: 1Gi
        volumeMounts:
        - name: redis-data
          mountPath: /data
      volumes:
      - name: redis-data
        persistentVolumeClaim:
          claimName: redis-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  selector:
    app: redis
  ports:
  - port: 6379
    targetPort: 6379

2. 按相同逻辑单独部署MySQL，创建名称为mysql的ClusterIP Service，配置持久化存储。
3. 修改业务应用Deployment，移除同Pod内的Redis、MySQL容器，将环境变量中DB_HOST值改为mysql、SPRING_REDIS_HOST值改为redis，直接通过Kubernetes内置DNS访问中间件服务。原有业务Service配置无需修改。

部署完成后可通过以下命令定位问题：

• 查看Pod事件，确认具体失败的容器和原因：kubectl describe pod <业务Pod名称>
• 查看容器上一次崩溃前的日志：kubectl logs <业务Pod名称> -c <容器名，可选值为user-registration/mysql/redis> --previous
• 验证服务连通性：进入业务容器执行curl redis:6379、curl mysql:3306确认端口可通。

内容的提问来源于stack exchange，提问作者Surya-Arvin