目前各大软件厂商都在积极拥抱云原生，K8S、DevOps等技术在各大软件厂商之间快速流行开来。诚然，K8S和DevOps等计算大大降低了运维的工作量，提高了服务发布的效率。但是“甘蔗没有两头甜”，当应用部署在K8S内时，软件工程师的开发、调试难度却增加了，原因在于K8S内部的网络和开发环境的网络并不互通（当然可以通过配置SVC为NodePort模式来实现，但是这并不适合所有的服务），而现在的服务拆解的粒度很细，在开发一个服务时，往往会依赖多个其它的服务，而这些被依赖的服务之间往往也会依赖更多的服务，形成一张很大的服务网，这大大增加了程序员在本地开发、调试的难度（因为你不可能把所有的服务都在本地启动起来）。借助阿里巴巴开源的工具KtConnect，我们可以方便的将本地环境和测试集群环境双向互联（在正式环境你肯定不会这样干），实现本地直接访问集群中的服务，以及将集群中的服务转发到本地的功能。
文章导航
原理
知其然也要知其所以然，我们先介绍一下KtConnec的原理，再来讲一讲工具的使用方法，这更有利于读者的理解。
connect
connect模式是我们最常用的模式，在启动connect模式后，我们边可以在本地直接访问集群内的网络。例如某个服务的SVC名称为tomcat，那么在本地环境内，如果需要请求其8888端口上的某个接口，直接访问tomcat:8888/path即可。
connect模式启动后，KtConnect会在集群内创建一个Shadow Pod，并且会使用PortForward将此Pod的SSH端口映射到本地。随后，KtConnect会在本地创建一个虚拟网络设备，发送到此设备的数据将被转发给Shadow Pod，由Shadow Pod去访问集群内的服务。之后KtConnect会配置本地路由表、DNS，将访问集群IP的请求路由到上面创建的虚拟网络设备中。此后，便可以通过这一转发链路，实现在本地请求集群中的服务。
exchange
exchange模式用于使用本地服务替换集群中的SVC实例。和connect类似，exchange模式也会在集群内创建Shadow Pod,并且同样会映射此Pod的SSH端口到本地。启动exchange模式后，KtConnect会修改原来SVC的selector，使得原来的流量转发到Shadow Pod来，然后再通过本地映射的端口转发到本地启动的服务。
使用方法
安装
MacOS
brew install kt-connect其它
$ curl -OL https://github.com/alibaba/kt-connect/releases/download/v0.3.7/ktctl_0.3.7_Linux_x86_64.tar.gz
$ tar zxf ktctl_0.3.7_Linux_x86_64.tar.gz
$ mv ktctl /usr/local/bin/ktctl
$ ktctl --version使用
前提
需要获得拥有编辑K8S对象的kubeconfig
连接到集群的网络
sudo ktctl --kubeconfig ~/.kube/config/config --namespace dev connect因为ktctl会修改本地路由表和DNS，所以执行ktctl需要使用管理员权限。通过 【–kubeconfig】和【–namespace】可以指定K8S的配置文件和命名空间。
替换集群服务
sudo ktctl --kubeconfig ~/.kube/config/config --namespace dev exchange <目标服务名> --expose <本地端口>:<目标服务端口>指定K8S的配置文件和命名空间，确定需要替换的目标服务名和目标服务端口，已经本地服务的端口，即可完成替换。
延展阅读：
如何通过微调Embedding模型提升RAG（检索增强生成）在问答中的召回效果
咨询方案
获取更多方案详情
