使用Telepresence调试AKS上Scala微服务遇端口绑定失败、断点不命中问题

• 已知Telepresence可用于Java微服务本地远程调试，Scala运行于JVM之上理论上兼容该方案，但实际操作始终无法调试成功
• 参照教程完成Telepresence拦截配置后，最初出现Kafka、MariaDB(MySQL)连接报错，在IntelliJ中参照AKS服务配置修改本地参数，例如将Kafka连接地址设置为kafka.default:9092（对应Kafka部署在default命名空间、服务名为kafka、AKS暴露端口9092）后，Kafka与数据库连接恢复正常，无相关报错
• 本地服务入口为Boot.scala，启动时会读取配置完成项目构建：
  • 若将本地application.conf中服务端口修改为和AKS一致的80端口，会抛出如下绑定错误
  • 若配置为其他端口，服务仅保持监听状态，无法正常处理请求

I|2022-07-13 15:41:00,893|c.a.libats.http.tracing.Tracing$|Request tracing disabled in config
E|2022-07-13 15:41:01,901|akka.io.TcpListener|Bind failed for TCP channel on endpoint [/0.0.0.0:80]

• Telepresence处于拦截状态时，前端侧发起的fetch请求始终无法完成，在全链路代码位置添加断点后，以调试模式启动本地服务从未命中任何断点
• 退出Telepresence拦截状态仅本地运行服务，现象完全一致：日志输出相同，80端口绑定问题仍然存在
• 补充背景：该项目为接手的存量Scala项目，无Scala开发经验，可能遗漏基础配置要点，除Telepresence方案外也需要其他可行的AKS远程调试方案

• 80端口绑定失败是核心阻塞点
  *nix系统默认限制普通用户进程绑定1024以下的特权端口，以普通用户身份启动IntelliJ运行服务时，没有权限监听80端口，直接导致Akka TCP层启动失败，HTTP服务未完成初始化，自然无法接收请求、触发断点。该问题和Telepresence无关，退出拦截后本地运行仍复现相同报错即可佐证。
• 非80端口下服务仅监听不生效
  Telepresence拦截默认将集群发往目标服务原端口（80）的流量转发到本地相同端口，若本地服务启动在其他端口但未手动配置拦截转发规则，流量不会打到本地服务，自然无法触发断点。
• 断点不命中的次要诱因
  若本地代码和集群运行的服务镜像代码版本不一致，或Scala编译开启优化导致行号映射偏移，也会出现断点失效问题，但当前场景下服务未正常接收流量是主因，该问题可在流量连通后再排查。

Telepresence调试修复步骤 #

• 解决端口绑定问题：放弃直接用80端口启动本地服务，选择1024以上的高位端口（如8080、9000）作为本地服务监听端口，修改application.conf中对应端口配置，启动服务确认日志无Bind failed报错，服务完成全量初始化。
• 配置端口转发规则：创建Telepresence拦截规则时，手动指定端口映射，将集群目标服务的80端口转发到上一步配置的本地高位端口，确认拦截状态中映射关系正确。
• 连通性校验：拦截生效后，先本地访问http://localhost:<本地监听端口>/服务健康检查路径确认服务本地可正常响应，再从前端或集群内发起请求验证流量转发正常，此时断点可正常命中。
• 断点异常兜底：若仍存在断点不命中问题，确认本地代码分支和集群部署镜像的代码版本完全一致，IntelliJ安装的Scala插件版本和项目使用的Scala版本匹配，关闭编译器代码优化选项后重新编译启动调试。

其他AKS远程调试方案 #

• JDWP端口转发直连调试
  1. 修改目标服务的Deployment配置，在JVM启动参数中添加JDWP调试参数：-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005
  2. 通过kubectl port-forward <目标Pod名称> 5005:5005 -n <服务所在命名空间>命令，将本地5005端口直接映射到目标Pod的5005调试端口
  3. 在IntelliJ中创建Remote JVM Debug配置项，连接本地5005端口即可直接调试集群上运行的服务，无需依赖Telepresence流量拦截。注意禁止在生产环境使用该方式，suspend参数不要设置为y，否则会阻塞服务正常启动。
• 临时容器注入调试
  若不想修改原有服务启动参数、重启Pod，可在AKS集群开启临时容器特性，通过kubectl debug命令给运行中的目标Pod注入带JDK调试工具的临时容器，转发JDWP端口即可完成调试，对原有业务无侵入。

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