如何在Kuma等服务网格中将SpringBoot应用作为SideCar代理注入另一SpringBoot应用

完全可以实现将自定义Spring Boot应用作为Sidecar注入其他Spring Boot（或任意语言）应用，和Istio、Kuma注入Envoy代理的底层逻辑一致，仅替换了Sidecar的运行镜像为你封装好的Spring Boot应用即可。

方案1：复用现有服务网格的注入能力 #

你已经熟悉Istio/Kuma的Sidecar注入规则，可以直接修改框架的默认注入模板：

• 替换模板中默认的istio-proxy/Kuma数据面镜像为你的Spring Boot应用镜像
• 保留原有模板的端口映射、流量拦截规则、生命周期管理配置
• 在你的Spring Boot应用中实现透明代理逻辑，匹配服务网格的iptables流量拦截规则，完成策略校验后再转发流量到主应用或上游服务

方案2：无服务网格依赖的K8s原生注入 #

如果不想依赖服务网格组件，用K8s原生能力即可实现：

• K8s 1.28及以上版本已正式支持Sidecar容器特性，将你的Spring Boot应用打包为标准容器镜像，配置为Sidecar容器，设置restartPolicy: Always保证和主应用同生命周期
• 开发简单的MutatingAdmissionWebhook实现自动注入：给需要注入的Namespace或Pod打自定义标签，Webhook会在Pod创建时自动将Spring Boot Sidecar注入Pod Spec，无需修改主应用的任何部署配置

• 流量转发规则：入站请求先到Spring Boot Sidecar，完成认证、安全策略校验后，通过localhost转发到主应用的服务端口；出站请求通过iptables规则拦截，先到Sidecar处理后再向外发送，主应用完全无感知
• 复用性保证：所有通用策略逻辑全部收敛在Sidecar中，主应用不需要做任何代码改造，仅需和Sidecar约定固定的本地转发端口，可直接复用到任意语言、任意框架的应用中
• 性能优化：Spring Boot的默认资源占用高于Envoy这类通用代理，建议通过JVM参数调优、GraalVM原生编译等方式降低Sidecar的内存占用和启动速度，避免影响主应用的调度和运行

• 生命周期同步：必须保证Sidecar先于主应用启动、晚于主应用停止，避免主应用启动初期的流量未经过策略校验直接流出。K8s原生Sidecar特性已默认支持该生命周期顺序控制，无需额外开发
• 本地通信无额外开销：Sidecar和主应用同属一个Pod网络命名空间，走localhost通信不会产生跨节点网络开销，性能损耗可忽略

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