Container附带业务jar包环境这种形式部署除了解决升级漏洞带来的好处还有哪些，是否带来了部署的复杂性？

1、日志落盘落在宿主机更简单明了，前提是做好应用启动时文件夹映射的命名区分
2、 initContainer更重了会不会造成启动困难？而且升级的init容器，对运行中容器的自愈重建后，会不会造城不可控的更新？
3、容器化改造的落地，开发无感是最好的，一般微服务架构是可以做到的。选 istio动作就太大了。

1、日志落盘
一般都是落到容器对接的存储上，即PVC上。
落本地技术上可行，但还要逐一维护，管理比较麻烦。

2、 initContainer是一种思路，但现在应用的用户很少，整体方案还不够完善。建议等段时间再看看

3、微服务架构选择，传统的SC架构已经比较普及了，相对从人员认知和技术成熟来说比较完善。Istio技术还是太新了，吸收和消耗需要一个过程，可找些非核心业务做也行技术试水和储备。

1、日志落盘看应用对日志的吞吐要求，有商业存储设备可以通过NAS落掉。
2、是的，这也是一种思路，确实带来了部署复杂性，所以需要额外开发一些能力屏蔽这个差异。
3、短期还是开发侧调整比较好，基础设施整体升级是一个蛮巨大的工程。