关于支持K8s管理的服务的流量录制方案讨论

[node]

Is your feature request related to a problem? Please describe.
有越来越多的应用部署在K8s pod，在录制流量时需要考虑对 K8s管理的服务的支持情况。

Describe the solution you'd like
根据微信群讨论记录，目前有多种可能的方案待探索和讨论确认。

Describe alternatives you've considered
期望的方案是：侵入少，满足大部分通用场景的需求；同时有一定的扩展性，支持少数用户自行扩展满足个性化需求。

Additional context

• JayeShen 提出有3个关键待完善 ；
• 一天到晚游泳的鱼思考提出了3种方案：
  • 使用 K8s api实现；
  • 类似sidecar模式在同一个pod里启动独立进程和应用；
  • 开发SDK到应用中，自动注册上报控制台

[NickyWu123]

基于代码侵入的考虑, 建议基于sdk的方式编写

[coderDylan]

我简单描述一下这3中实现方案的思路：

1.在moonbox中使用K8S的API或者对应语言的sdk包，实现进入指定应用的pod并执行sh脚本，最终完成agent附加目标到进程动作。
这样的好处是应用开发无感知，企业原有CI/CD基础镜像等不需改造。前提是需要对K8S api有一定了解，且能够获取到K8S相应的权限、认证。

2.类似sidecat的模式，开发一个独立应用程序并启动独立进程，部署时和被录制/回访的业务应用在同一个pod中，由该进程负责和moonbox的控制台通信、心跳、指令下发、sh执行等，最终完成agent附加到目标进程的动作。
这样的好处是应用无侵入，不感知。缺点是需要侵入到现有运维的CI/CD，应用打包时需要带上该特殊的应用（可内置在基础镜像中），容器启动时也需要启动该进程，也可能存在一定的安全风险

3.基于应用层SDK实现。开发一个Java的组件，实现与moonbox控制台的心跳、应用信息上报、通信、指令下发等等。该SDK组件被应用程序直接依赖。当控制台指令下发时，该SDK组件能够正常接收并执行sh脚本，最终完成agent附加目标到进程动作。
这样的好处是开发人员自主可控，无需侵入运维。缺点是对应用有一定的侵入性（需要添加依赖），也可能存在一定的安全风险

[claywong]

这个有进展吗？输入ssh协议的用户名和密码在公司已经走不通了，全部是k8s部署

[JayeShen]

Is your feature request related to a problem? Please describe. 有越来越多的应用部署在K8s pod，在录制流量时需要考虑对 K8s管理的服务的支持情况。

Describe the solution you'd like 根据微信群讨论记录，目前有多种可能的方案待探索和讨论确认。

Describe alternatives you've considered 期望的方案是：侵入少，满足大部分通用场景的需求；同时有一定的扩展性，支持少数用户自行扩展满足个性化需求。

Additional context

• JayeShen 提出有3个关键待完善 ；

• 一天到晚游泳的鱼思考提出了3种方案：

  • 使用 K8s api实现；
  • 类似sidecar模式在同一个pod里启动独立进程和应用；
  • 开发SDK到应用中，自动注册上报控制台

抽空提交了后端代码，https://github.com/JayeShen/Moonbox-k8s