K8S环境下研发如何本地调试？kt-connect使用详解

背景

注：背景有点啰嗦，讲讲一路走来研发本地调试的变化，嫌烦的可以直接跳过，不影响阅读。

2019年

我在的公司当时是个什么情况，只有两个Java应用，还都跑在一个Tomcat Servlet容器。

当时是如何本地调试？都是研发自己电脑装个Mysql，装个Tomcat，自己电脑运行调试，好处嘛就是后端研发互不干扰，想怎么改就怎么改，APP端研发就直连后端的笔记本调试。上线部署嘛就是一个研发手动编译个Jar包丢到云服务器上面，大体就是个草台班子，能干活，但是也就那样。

2020年

到了2020年，公司买了一台服务器，Centos的系统，给装上了Mysql、Tomcat，用上了Redis缓存，RabbitMQ消息队列，有了独立的测试环境，用上了Jenkins自动打包并部署应用，也算鸟枪换炮，起码不用自己打包了。

这个时候是如何本地调试呢？起码不用自己电脑装Mysql了，后面框架由SpringMVC和Struts2都改成Spring Boot，外置的Tomcat也可以去掉了。后端研发本地运行Spring Boot时直连服务器的Mysql进行调试，APP端再也不用连后端研发的笔记本了，有了相对稳定的调试环境。代价就是各个后端的数据库更新结构要保持兼容性，避免影响他人。

2021年

随着业务增长，后端框架由Spring Boot进化为Spring Cloud全家桶，应用运行环境由Linux直接运行改为了Docker镜像部署，各类中间件同样也使用了Docker镜像。产品线增加，单一的开发分支已经不能满足需求，为此又开辟了另外一条后端代码分支，同样的开发测试环境也多了一份。

这个时候的本地调试，对于APP端来说变化不大，区别连接后端不同环境使用不同域名而已。对于后端的研发同学就不一样了，每次本地调试自己电脑要常驻一个Eureka和一个Config Server，如果本地调试的微服务依赖比较多，没个大内存真是顶不住。

2022年

业务量继续增加，产品同事数量增加了，那个需求量真是堆积如山，两个分支已经不能满足要求了，又开了第三个分支