必须配置startupprobe解决java微服务慢启动被重启问题：实测启动超45秒即需配置，其成功前livenessprobe和readinessprobe不生效；推荐http get方式，设failurethreshold×periodseconds≥200秒，并确保initialdelayseconds避开端口未监听瞬态。
Java微服务启动要3分钟，但默认startupProbe没配，kubelet在30秒内反复重启Pod，根本等不到应用加载完——必须用StartupProbe给慢启动过程争取足够时间。
确认应用是否真需要StartupProbe
先验证启动耗时：进入容器执行 time curl -s http://localhost:8080/actuator/health | grep status，若首次返回 "status":"UP" 耗时超过45秒，就必须配StartupProbe。只配livenessProbe或readinessProbe无法解决启动阶段被杀问题，因为它们默认在容器创建后立即开始探测。
StartupProbe的唯一作用就是：在它成功前，【livenessProbe和readinessProbe完全不生效】。这是它区别于其他两个探针的根本机制。
用HTTP GET方式配置StartupProbe
方法一：直接写在Deployment的containers字段下
在容器spec里添加如下块：
startupProbe: httpGet: path: /health-startup port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 40 timeoutSeconds: 2
其中 【failureThreshold × periodSeconds = 总等待时长】，这里40×5=200秒，足够覆盖3分钟启动窗口；initialDelaySeconds设为10是为避开应用刚fork出进程但端口尚未监听的瞬态。
方法二：复用现有/health端点但加参数隔离
若不想新增路径，可在原有健康检查接口上加query参数区分语义：path: /actuator/health?probe=startup，后端Spring Boot需识别该参数并跳过数据库连接校验等耗时检查。
用Exec命令方式配置StartupProbe
第一步：确保容器内有curl或nc命令可用，否则exec探测会直接失败
第二步：编写探测命令，推荐用curl而非nc——nc只能判断端口通不通，curl能校验HTTP响应体是否含"UP"
startupProbe: exec: command: - sh - -c - "curl -f http://localhost:8080/health-startup | grep -q 'UP'" initialDelaySeconds: 15 periodSeconds: 8 failureThreshold: 25
注意：-f参数让curl在HTTP非2xx状态时返回非零退出码，这是exec探测判定失败的关键；没有-f，即使返回503也会被当成成功。
关键参数调优逻辑
① 计算最小failureThreshold：实测启动最长时间 ÷ periodSeconds，向上取整再加3～5次冗余（应对GC暂停、磁盘IO抖动）
② timeoutSeconds必须小于periodSeconds，否则两次探测会重叠；设为2秒可覆盖99%的健康接口响应
③ initialDelaySeconds不能设为0：Spring Boot应用在main线程启动前，HTTP服务器线程根本没起来，此时探测必然失败
④ successThreshold保持默认1即可，StartupProbe只需成功一次就永久退出监控，不需要“连续成功”
