先看exit code和events再查日志：kubectl describe pod可查oomkilled（137）、探针失败等warning事件及last state退出码；--previous日志必加，因go崩溃快、当前日志常为空；内存配额与gomemlimit需协同，避免rss超限触发内核kill。
先看 exit code 和 Events，别急着翻日志
Pod 频繁重启时，Exit Code 和 Events 是最直接的线索，比日志更早暴露根因。很多 Go 服务崩溃后日志为空，但 kubectl describe pod 里已写明 OOMKilled 或 Probe failed。
执行以下命令快速抓取关键信息：
kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>
重点关注两处：
-
Events区域中带Warning标签的条目，尤其是OOMKilled、Liveness probe failed、Back-off restarting failed container -
Containers下的Last State字段，看Exit Code：137= OOM，1= 应用主动退出，2或143= 收到SIGTERM后未处理完就退出
kubectl logs --previous 是 Go 服务崩溃排查的刚需
Go 程序启动失败（比如配置解析 panic、DB 连接超时）往往在几秒内就退出，kubectl logs <pod-name></pod-name> 查不到任何内容——因为容器已重建，日志被清空。必须加 --previous 才能拿到上一轮崩溃前的 stderr/stdout。
实操要点：
- 单容器 Pod：
kubectl logs <pod-name> --previous -n <namespace></namespace></pod-name> - 多容器 Pod（如含 initContainer）：
kubectl logs <pod-name> -c <container-name> --previous -n <namespace></namespace></container-name></pod-name> - 加
--timestamps可对齐崩溃时间点：kubectl logs <pod-name> --previous --timestamps</pod-name>
常见 Go 崩溃日志特征：
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
-
panic: runtime error: invalid memory address→ 空指针或未初始化结构体字段 -
exit status 1: flag provided but not defined→ 启动参数拼错或 flag.Parse() 调用位置不对 -
context deadline exceeded或dial tcp: i/o timeout→ 初始化阶段依赖服务不可达，未设重试或超时过短
Go 服务内存行为特殊，limits 设置不当极易触发 OOMKilled
Go 的 GC 不会立即归还内存给操作系统，container_memory_usage_bytes 指标可能长期贴近 resources.limits.memory，但实际 RSS 已超限，内核直接发 SIGKILL（exit code 137）。这不是 Go 内存泄漏，而是资源配额和 runtime 行为不匹配。
验证与调整建议：
- 查实时内存使用：
kubectl top pod <pod-name> --containers -n <namespace></namespace></pod-name>，对比describe中的limits.memory - Go 服务建议设置
GOMEMLIMIT环境变量（Go 1.19+），例如512Mi，让 runtime 主动触发 GC，避免内核 OOMKill - 若用
runtime/debug.ReadMemStats打印堆统计，注意Alloc和Sys的差值——HeapSys - HeapAlloc大说明内存未及时归还 - 不要把
requests.memory设得过低（如64Mi），否则节点调度器可能把多个高内存 Go 服务挤在同一节点，加剧 OOM 风险
livenessProbe 误杀 Go 服务：initialDelaySeconds 不是拍脑袋定的
Go HTTP 服务冷启动慢（尤其加载模板、初始化 DB 连接池、预热缓存），livenessProbe 在应用还没 ready 就开始探测，连续失败后 kubelet 强制重启，形成 CrashLoopBackOff。
典型误配：
-
initialDelaySeconds: 5→ Spring Boot 都不够，Go 更不够 -
timeoutSeconds: 1→ GC STW 或磁盘 I/O 毛刺就超时 -
failureThreshold: 1→ 一次偶发延迟就杀，毫无容错
合理做法：
- 本地用
time curl -o /dev/null http://localhost:8080/health测真实冷启动耗时，initialDelaySeconds至少设为该值 + 5 秒缓冲 -
timeoutSeconds≥ 3，failureThreshold≥ 3，允许 GC 暂停或网络抖动 - 生产环境可加轻量级 readinessProbe（检查端口通）+ 严格 livenessProbe（检查 DB 连接），避免健康检查耦合过重
临时验证是否探针导致：用 kubectl patch 禁用 livenessProbe，观察是否还重启。如果停止，问题就在这里。
