如何调试Minikube中Cassandra Pod的CrashLoopBackOff错误？

你的Cassandra Pod Exit Code 137是个关键信号——这通常表示容器被Linux内核的**OOM Killer（内存不足终止器）**强制杀死了，在资源有限的Minikube环境里，Cassandra默认的内存配置很容易触发这个问题。下面是获取详细故障信息的具体步骤：

1. 查看Pod容器的启动日志（含历史崩溃实例） #

首先用kubectl logs命令查看Cassandra容器的标准输出/错误日志，加上--previous参数可以获取上一次崩溃的容器日志，这能看到Cassandra启动时的具体报错：

kubectl logs -n test cassandra-6b5f5c46cf-zpwlx cassandra --previous

你可能会看到JVM初始化时内存分配失败的提示，或者Cassandra的启动自检日志。

2. 进入Minikube节点查看Docker底层日志 #

Minikube是单节点集群，你可以直接登录节点查看Docker容器的原始日志：

# 登录Minikube节点
minikube ssh

# 用kubectl describe里的Container ID（比如b34777883916）查看日志
docker logs b34777883916

这里会包含更底层的启动细节，比如内核发送SIGKILL信号的记录。

3. 检查Minikube节点的资源使用情况 #

确认节点是否真的内存不足：

# 直接在本地执行，无需登录节点
minikube ssh -- free -h

如果输出里的available内存很低（比如只有几百MB），那就是内存不足导致的崩溃。

4. 查看内核OOM Killer的日志记录 #

内核会把OOM杀死进程的操作记录在dmesg里，你可以用以下命令过滤相关日志：

minikube ssh -- dmesg | grep -i oom

如果看到类似Out of memory: Kill process 1234 (java) score 500的内容，就100%确认是内存不足导致的问题了。

针对当前问题的修复建议 #

既然是内存不足，你可以从两个方向解决：

• 调整Cassandra的JVM参数：把Deployment里的MAX_HEAP_SIZE降低到512M，HEAP_NEWSIZE调整到256M（根据Minikube的内存大小灵活调整，比如Minikube默认是2G内存）：

  env:
    - name: MAX_HEAP_SIZE
      value: 512M
    - name: HEAP_NEWSIZE
      value: 256M
  

  修改后执行kubectl apply -f your-deployment.yaml -n test重新部署。
• 给Minikube分配更多内存：如果你的主机有足够资源，可以重启Minikube并分配更大内存：

  minikube stop
  minikube start --memory 4096
  

内容的提问来源于stack exchange，提问作者wvxvw