项目地址： https://github.com/alibaba/kt-connect

kt-connect 只会在指定连接的命名空间（namespace）里面新建一个自用的 pod，然后部署一个 kt-connect-shadow 的镜像。

它在模式进行了细分扩展，分为四大模式：

1. Connect 模式

ktctl.exe connect --kubeconfig .kubeconfig --namespace feature-N --debug
  • 1.

这个模式下，kt-connect 起到的是一个类似于 VPN 的作用，研发本地电脑可以访问到连接的命名空间(namespace)内的所有服务，但是并没有加到集群里面其他服务里面，其他服务的流量并不会转发到本地电脑。

注 1： 与 telepresence 类似，kt-connect 所有命令都要带上--kubeconfig，确保有足够权限和能正确连接 K8S 集群的 API Server，很多文章都很少提到这点，假如 K8S 集群限制权限，或者与研发不在同一个网络，必须确保使用运维同学提供的有足够权限的授权文件 kubeconfig 来进行连接。
注 2：

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](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.'，" linktype="text" imgurl="" imgdata="null" data-itemshowtype="0" tab="innerlink" data-linktype="2" hasload="1" style="margin: 0px; padding: 0px; outline: 0px; color: var(--weui-LINK); text-decoration: none; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-user-drag: none; cursor: default; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important;">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](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."，
  • 1.

如果出现以上报错的话，有可能是 kt-connect 路由 BUG，可能本地电脑的路由与新加的通往 API Server 的路由有冲突，增加参数--excludeIps 10.0.8.101/32 即可，如果网段冲突比较多，可以扩大网段范围，例如--excludeIps 10.0.8.0/24 参考 issue-302:

 https://github.com/alibaba/kt-connect/issues/302

ktctl.exe connect --kubeconfig .kubeconfig --namespace feature-N --excludeIps 10.0.8.101/32 --debug
  • 1.

2. Exchange 模式

ktctl.exe exchange serviceA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug
  • 1.

这个模式类似于 Telepresence 拦截模式，将指定服务的所有流量拦截下来转发到研发本地电脑的端口，使用这个模式能对环境里的访问请求直接进行调试。
具体原理就是将 service 里面的 pod 替换成一个 serviceA-kt-exchange 的 pod。

注 1： Exchange 模式的流量方向是单向的，并不会将本地电脑主动发起的请求代理过去，如果 K8S 集群跟研发本地电脑不在一个网段内，需要另外开一个命令行运行 Connect 模式，确保本地服务可以正常连接 K8S 集群的其他服务，参考 issue-216：

 https://github.com/alibaba/kt-connect/issues/216

注 2： Exchange 模式是通过拦截 service 进行流量转发，假如集群的请求没有经过 service，例如直接解析到 pod 之类，可能就会出现拦截失败的情况（同理 Mesh 模式也是如此），所以出现问题记得跟运维同学确认 K8S 集群内的路由情况。

3. Mesh 模式

kctl.exe mesh serviceA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug
  • 1.

执行命令后可以看到输出日志里面包含类似文字：

2:30PM INF Now you can access your service by header 'VERSION: xxxxx'
  • 1.

这个模式本地电脑的服务和 K8S 集群里面相同的服务同时对外响应请求，但是只有通过指定的 http 请求头 VERSION: xxxx 的请求才会转发到本地电脑，相比 Exchange 模式，保证了其他人服务正常使用，同时研发又能进行本地调试。每次生成的请求头 VERSION 的值都是动态生成的，如果要固定这个值，可以通过参数--versionMark 写死，例如固定值为 test-version，命令如下：

kctl.exe mesh serviceA --kubeconfig .kubeconfig --namespace feature-N --expose 12001 --debug --versionMark test-version
  • 1.

具体原理就是将 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
  • 1.

不同于 Exchange 和 Mesh 模式要求 K8S 集群有一个在运行的服务，Preview 模式可以将本地电脑运行的程序部署到 K8S 集群中作为一个全新的 Service 对外提供服务，非常便于新建服务的开发调试、预览等作用。