Kubernetes部署Tomcat应用时Web上下文监听器未触发问题排查

结合你遇到的Tomcat监听器未触发的场景，两种启动方式的关键差异主要集中在以下几个方面：

1. 工作目录（Working Directory） #

• K8s直接启动：严格遵循镜像中WORKDIR的配置（你的镜像中是/usr/local/tomcat/webapps），命令会在该目录下执行。如果直接运行catalina.sh run，实际是在webapps目录下寻找该脚本，虽然Tomcat可能通过环境变量定位到脚本，但启动工作目录异常会导致Web应用初始化上下文不符合预期，进而影响监听器触发。
• 手动进入容器执行：默认进入镜像定义的用户主目录（Tomcat官方镜像中为/usr/local/tomcat），此时执行bin/catalina.sh run是从Tomcat根目录启动，完全符合Tomcat的预期启动路径，应用初始化流程正常。

2. 环境变量加载逻辑 #

• K8s直接启动：仅加载镜像构建阶段定义的环境变量，以及K8s Deployment中env字段配置的变量。默认情况下，命令不会经过shell解析（除非显式指定用shell启动，如["bash", "-c", "catalina.sh run"]），因此不会加载.bashrc、.profile等shell配置文件中的环境变量，可能缺少Tomcat启动依赖的部分变量。
• 手动进入容器：会启动交互式shell，自动加载当前用户的shell配置文件，补充环境变量（如PATH扩展、CATALINA_BASE默认设置），这些变量确保Tomcat以标准流程启动，监听器能正常触发。

3. 进程身份与信号处理 #

• K8s直接启动：启动的命令是容器的PID 1进程。Linux系统中，PID 1进程的信号处理规则与普通进程不同（比如默认忽略部分终止信号），Tomcat的catalina.sh run作为PID 1运行时，内部Servlet容器的初始化逻辑可能受到影响，导致监听器未被正确调用。
• 手动执行命令：命令作为shell的子进程运行（PID不为1），信号处理逻辑与普通进程一致，Tomcat的初始化流程完全遵循标准行为，监听器能正常触发。

4. 权限执行环境 #

• K8s直接启动：如果Deployment中配置了securityContext（如指定运行用户、权限限制），命令会以指定的权限执行，可能与镜像默认的运行用户（Tomcat镜像通常为tomcat用户）权限不一致，导致Tomcat在读取配置文件、加载Web应用时出现权限问题，间接影响监听器初始化。
• 手动进入容器：默认使用镜像定义的运行用户，权限环境与镜像构建时完全一致，不会出现权限差异导致的初始化异常。

针对你的场景的修复建议 #

1. 在Deployment的容器配置中显式指定workingDir: /usr/local/tomcat，确保命令在Tomcat根目录执行；
2. 修改容器启动命令为["bin/catalina.sh", "run"]，明确指定脚本路径；
3. 若需要加载shell环境变量，可改用shell启动命令：["bash", "-c", "bin/catalina.sh run"]。

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