如何为Kubernetes中的Java应用配置startupProbe检测stdout启动日志

先理清楚两个容易走死胡同的事实：

• Kubernetes的exec探针是在容器内部的隔离命名空间下执行命令的，权限范围仅限容器自己的文件系统和进程空间，从根上就完全访问不到当前Node宿主机上/var/log/containers路径下的日志——这个目录是节点宿主机的本地路径，和容器的文件系统完全隔离，想从Pod内部直接读这个位置的日志，原理上就走不通。
• 容器的stdout实际是被容器运行时捕获后转发到节点日志目录的持续流，源头是容器内主进程（Java应用一般就是PID 1）的标准输出文件描述符（对应容器内路径/proc/1/fd/1），但这是个持续追加的流式接口，没法直接用来静态判断“是不是已经输出过目标文本”。

按推荐优先级从高到低排列：

1. 调整应用日志配置，让启动日志在容器内部落盘（最稳妥无额外依赖） #

完全不需要碰节点上的日志存储链路，只要在应用启动配置里，把原本只输出到stdout的启动日志，同时写入容器内文件系统的可写路径就行。以Tomcat为例：

• 编辑conf/logging.properties配置，开启日志的文件输出，让打印"tomcat started"的这段日志同时写到容器内固定路径的日志文件，比如/usr/local/tomcat/logs/catalina.log
• 配置startupProbe直接grep这个容器内的日志文件即可，示例YAML：

startupProbe:
  exec:
    command:
    - grep
    - -q
    - "tomcat started"
    - /usr/local/tomcat/logs/catalina.log
  failureThreshold: 30
  periodSeconds: 10

注意事项：

• 别把日志存储路径放在内存盘上，避免无谓的内存开销
• 配置日志定期轮转清理，防止日志写满磁盘

2. 用应用自带的健康端点替代日志匹配（工程上最优解） #

真没必要死磕匹配日志文本：日志里打"tomcat started"只是启动完成的外在表象，而Tomcat（尤其是Spring Boot集成的内嵌Tomcat）从9.0版本开始就提供了原生的健康检查端点，只有当所有组件初始化完成、可以对外接流量的时候，这个端点才会返回200状态码，判断逻辑的确定性比匹配日志高得多。
直接配置httpGet类型的startupProbe检测端点就行，示例：

startupProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

优势：不会因为日志格式调整、日志输出丢字、日志被截断导致探针误判，检测逻辑更贴合“应用真正就绪”的实际语义。

3. 共享卷日志转发（仅适合完全改不动应用配置的场景） #

如果既改不了日志配置、也不想开健康端点，可以在同一个Pod内配一个共享emptyDir卷，让主容器把原本输出到stdout的内容同步写到共享卷的日志文件里，探针直接检测这个文件就行。
这种方式本质是把原本节点层面的日志捕获逻辑挪到Pod内部，会带来额外的资源开销，没有特殊必要不推荐用。

• 别把节点上的/var/log/containers目录通过hostPath挂到Pod里：这种操作会把节点上所有业务的日志都暴露给Pod，安全风险极高，而且日志路径和节点名、Pod名、容器名强绑定，Pod重建后路径很容易失效，维护成本高到离谱。
• 别尝试grep容器内/proc/1/fd/1的内容：这是持续的流式文件，每次执行grep时只能读到当前时间点的流内容，很容易错过之前已经输出过的'tomcat started'文本，导致探针一直超时直到判定启动失败。

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