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年
业务量继续增加，产品同事数量增加了，那个需求量真是堆积如山，两个分支已经不能满足要求了，又开了第三个分支，还是不够。每次增加新的分支运行环境，后端研发同学也很痛苦，一堆环境和第三方平台回调需要配置。为了能动态扩容缩容，Spring Cloud全家桶继续演进，抛弃了Zuul网关和Eureka，改为使用Spring Cloud Kubernetes，运行环境全面向K8S靠拢。在此期间公司又采购了一台服务器用于开发测试，内存CPU磁盘满上!
进入K8S时代，后端研发本地的电脑没办法随意连接Linux服务器上面的各种中间件，每个新分支环境里面的每个POD都是一个新的ip，也不可能像之前那样开放指定几个中间件的端口给后端连接，那么多环境每个都做设置的话，运维同学整天不用干别的事了。也由此引出了今天要说的kt-connect工具，通过这个工具，后端研发本地的电脑可以代理访问到各个分支环境，也就是K8S里面的命名空间的所有服务，并且只需要启动需要调试的服务，大大节省了电脑CPU内存占用。
选型
在选择代理访问K8S环境以便于本地调试的工具中，网上有几种。
1. 端口转发
使用Ingress、NodePort、LoadBalancer之类的将流量转发到指定端口，如上文所说，会让运维同学工作量比较大，也不便于分支环境的自动创建和回收，只适合需要暴露端口数量不多的场景。
2. VPN
通过在K8S每个命名空间里面设置一个运行有VPN服务的POD，后端研发笔记本通过VPN客户端连接代理进入到指定命名空间，可以正常访问和解析集群内各类服务，基本能满足日常的要求，缺点是每个命名空间都常驻了一个VPN服务的运行资源。
3. Telepresence
在搜索的过程中发现了这个代理工具，几乎可以说9成的中英文技术文章都推荐使用这个工具，功能非常强大，不但提供了VPN所具有的代理功能，可以访问到命名空间内所有服务，还能指定各种规则拦截指定服务的流量到本地机器，相当于本地机器也能作为一个普通的POD提供对外服务。大体设计原理如下：
在研发本地电脑执行如下命令
telepresence helm install --kubeconfig .\kubeconfig telepresence connect ---kubeconfig .\kubeconfig就会自动在K8S集群创建一个命名空间ambassador，并且部署一个traffic-manager的pod，用于流量管理，而在研发笔记本本地则会启动2个daemon服务，其中一个叫Root Daemon，用于建立一条双向代理通道，并管理本地电脑与K8S集群之间的流量，另外一个User Daemon则是负责与Traffic Manager通信，设置拦截规则，如果登录后还负责与Ambassador Cloud进行通信。
通过配置拦截规则，拦截的POD里面会安装一个traffic-agent，官方文档说明是类似K8S集群的sidecar模式，对注入POD进行流量劫持，所有流量出入通过traffic-manager进行重新路由。
The Traffic Agent is a sidecar container that facilitates intercepts. When an intercept is first started, the Traffic Agent container is injected into the workload's pod(s).虽然他的功能很强大，但是在目前2.5版本的使用过程中，为了使用他的拦截和Preview Url功能必须在他家的商业云平台Ambassador Cloud进行注册登陆(注：不知道为什么网上技术文章都没提到这点，测试的时候非得要登录他家云平台)，并且拦截规则的配置是通过云平台的网页进行操作的，联网的要求，包括可能存在的安全，泄露之类的隐患，我觉得是不可接受，也因此不得不放弃使用这个工具。
还有一个不得不说的缺点就是，老版本使用后可以清理掉自动创建的命名空间（namespace）和pod、拦截agent的功能（telepresence uninstall）也没了，在2.5版本的命令参数里面完全消失了，这就导致每次使用后，如果想保持环境干净，还得麻烦运维同学去清理掉，非常麻烦，简直逼死洁癖患者。
4. kt-connect
所幸开源社区又找到了另外一款类似Telepresence的工具，名为 kt-connect ，使用版本为v0.3.6（顺便说下我们使用的K8S版本是1.24），并且它无需联网登陆什么账号，结束命令执行默认还会自动清理。阿里出品，不确定是不是又一个KPI开源项目，但是至少这一刻我对这个工具是非常满意的。
原理
同Telepresence类似，但不同的是，kt-connect只会在指定连接的命名空间（namespace）里面新建一个自用的pod，然后部署一个kt-connect-shadow的镜像。相比Telepresence，它在模式进行了细分扩展，分为四大模式：
1. Connect模式
ktctl.exe connect --kubeconfig .\kubeconfig --namespace feature-N --debug这个模式下，kt-connect起到的是一个类似于VPN的作用，研发本地电脑可以访问到连接的命名空间(namespace)内的所有服务，但是并没有加到集群里面其他服务里面，其他服务的流量并不会转发到本地电脑。
注1：与telepresence类似，kt-connect所有命令都要带上--kubeconfig，确保有足够权限和能正确连接K8S集群的API Server，很多文章都很少提到这点，假如K8S集群限制权限，或者与研发不在同一个网络，必须确保使用运维同学提供的有足够权限的授权文件kubeconfig来进行连接。
注2：
Failed to setup port forward local:28344 -> pod kt-connect-shadow-gseak:53 error="error upgrading connection: error sending request: Post " https://10.0.8.101:8443/api/v1/namespaces/feature-N/pods/kt-connect-shadow-gseak/portforward ": dial tcp 10.0.8.101:8443: connectex: A socket operation was attempted to an unreachable host."，
如果出现以上报错的话，有可能是kt-connect路由BUG，可能本地电脑的路由与新加的通往API Server的路由有冲突，增加参数--excludeIps 10.0.8.101/32即可，如果网段冲突比较多，可以扩大网段范围，例如--excludeIps 10.0.8.0/24 参考 issue-302 。
ktctl.exe connect --kubeconfig .\kubeconfig --namespace feature-N --excludeIps 10.0.8.101/32 --debug2. Exchange模式
ktctl.exe exchange serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug这个模式类似于Telepresence拦截模式，将指定服务的所有流量拦截下来转发到研发本地电脑的端口，使用这个模式能对环境里的访问请求直接进行调试。
具体原理就是将service里面的pod替换成一个serviceA-kt-exchange的pod。
注1：Exchange模式的流量方向是单向的，并不会将本地电脑主动发起的请求代理过去，如果K8S集群跟研发本地电脑不在一个网段内，需要另外开一个命令行运行Connect模式，确保本地服务可以正常连接K8S集群的其他服务，参考 issue-216 。
注2：Exchange模式是通过拦截service进行流量转发，假如集群的请求没有经过service，例如直接解析到pod之类，可能就会出现拦截失败的情况（同理Mesh模式也是如此），所以出现问题记得跟运维同学确认K8S集群内的路由情况。
3. Mesh模式
kctl.exe mesh serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug执行命令后可以看到输出日志里面包含类似文字：
2:30PM INF Now you can access your service by header 'VERSION: xxxxx'这个模式本地电脑的服务和K8S集群里面相同的服务同时对外响应请求，但是只有通过指定的http请求头VERSION: xxxx的请求才会转发到本地电脑，相比Exchange模式，保证了其他人服务正常使用，同时研发又能进行本地调试。每次生成的请求头VERSION的值都是动态生成的，如果要固定这个值，可以通过参数--versionMark写死，例如固定值为test-version，命令如下：
kctl.exe mesh serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug --versionMark test-version具体原理就是将serviceA里面的Pod替换成一个serviceA-kt-router的路由镜像，负责根据请求头进行流量代理转发，另外生成一个serviceA-kt-stuntman服务，这个就是线上正常运行的serviceA，还有一个serviceA-kt-mesh-xxxxx服务，这个就负责将代理流量到本地电脑。
4. Preview模式
kctl.exe preview serviceB --kubeconfig .\kubeconfig --namespace feature-N --expose 12001不同于Exchange和Mesh模式要求K8S集群有一个在运行的服务，Preview模式可以将本地电脑运行的程序部署到K8S集群中作为一个全新的Service对外提供服务，非常便于新建服务的开发调试、预览等作用。