前言
我相信很多做k8s或者微服务的小伙伴是在使用以下方式调试本地代码：
1. 本地开发，调试接口之后再部署到k8s集群进行联调
2. 或者本地调试时，为了能够稳定接收到来自测试环境的消息事件等，需要先将测试集群上对应的服务停掉。
第一种方式效率低，第二种方式容易给集群其他用户造成影响。
之前我介绍过一款Visual Studio k8s调试插件: Bridge to Kubernetes-附加到k8s集群调试 ，它可以将集群流量重定向到你的Visual Studio，今天为大家介绍另一款k8s调试工具：Telepresence。
Telepresence架构
Telepresence是由Ambassador Labs公司提供的，大家可能会了解他家的云原生微服务网关Ambassador，其实它是一家致力于提供混合云架构解决方案的公司，Telepresence是其中一个产品。
Traffic Manager 与 Traffic Agent
Telepresence 需要在k8s集群中安装一个Traffic Manager服务，它的作用是接受来自开发者机器的指令，转发本地与集群之间请求和响应，集群中被拦截调试的对象被称为Intercepted container。
当开发者本地使用Telepresence附加调试之后，Traffic Manager会以sidecar模式向目标服务注入一个container：Traffic Agent，它是一个代理网关。Traffic Agent的作用是将你的本地流量转发到Kubernetes集群中的Pod上，同时将从Pod返回的流量重定向回本地。
Telepresence Daemons
Telepresence Daemons 是本地与集群网络连接的通讯站。
Telepresence Daemons其实分两个版本，User-Daemon是开源的免费版，Root-Daemon是需要Ambassador Cloud账户的付费版。付费版有以下两个优势：
Ambassador Cloud
Root-Daemon需要连接到Ambassador Cloud，而Ambassador Cloud会为你本地服务生成Preview URL，一个临时的公开可访问域名，当然只有你允许的团队成员可以访问它。
想象一下，你可以直接把本地的swagger页面，或者把正在调试的blazor页面发给同事review，并且你的代码像是已经部署在集群中一样，这是一种什么体验。
VIF
Root-Daemon 使用Virtual Network Device (VIF)。
请思考一个问题，你本地访问集群容易，可是集群怎么访问你呢？怎么才能够接收到来自集群发出的请求？在以前的版本中，Telepresence会采用一种简单粗暴的方式：启动socket代理，修改防火墙规则。
修改防火墙规则？这听着很不科学，事实上这种方式确实会带来很多问题，因此Telepresence 采用了VIF技术，它会像VPN一样建立一条集群与本地服务之间的通信隧道，具体原理可以参考：Implementing Telepresence Networking with a TUN Device
安装使用Telepresence
安装
Telepresence的安装和使用都非常简单，首先你必须拥有集群管理权限，你可以去看官网 Ambassador Telepresence Install，接下来我会介绍Windows安装过程。
- 下载并解压https://app.getambassador.io/download/tel2/windows/amd64/latest/telepresence.zip
- 可以运行install-telepresence.ps1脚本，也可以手动把解压后的路径添加到环境变量里。
- 打开powershell运行：telepresence helm install。正常情况下会返回Launching Telepresence User Daemon；Traffic Manager installed successfully两条提示。
准备两个测试项目
1. 确认集群中traffic-manager pod正常运行
2. 在k8s中部署两个web api项目作为测试，第一个项目提供接口api，第二个项目去调用。
项目一提供两个api：
项目二去调用项目一的api：
将两者部署到k8s当中：
本地调试
在本地修改项目一的api代码并调试，我这里正在使用的是5252端口。
创建一个 intercept
第一次创建telepresence-agent会比较耗时，如果命令执行超时，建议等待sidecar container注入完成之后再试一次，直到返回下图所示结果
telepresence intercept <target service name> --namespace <namespace> --port <local service port>
正式测试
项目二会去调用项目一的接口，项目一的代码修改之后正在本地调试。
因此，我们现在调用项目二的接口，看看集群是否会将流量转发到我们本地
1. port-forward 项目二，以供本地调用
2. 调用项目二的接口，可以看到命中了本地正在调试的项目一中的断点。
清理intercept
如果你不把刚刚创建的intercept清理掉的话，集群会一直将流量转发到你的本地，因此你需要使用以下命令清理intercept：
telepresence uninstall <INTERCEPT-NAME>
对比Bridge to Kubernetes和Telepresence
我记得很重要一点是Bridge to Kubernetes提供了路由隔离机制，而Telepresence是全部转发。以下内容来自ChatGPT：
Visual Studio的Bridge to Kubernetes和Telepresence都是用于在本地开发环境中开发、调试Kubernetes应用程序的工具，它们的实现方式和一些功能有所不同。
Bridge to Kubernetes是Microsoft在Visual Studio 2019中提供的一个插件，通过该插件，开发人员可以将本地的开发环境连接到Kubernetes集群中的应用程序。具体来说，Bridge to Kubernetes会在本地计算机上创建一个虚拟机，该虚拟机会运行Kubernetes代理和Istio代理。当开发人员在本地计算机上运行应用程序时，请求将被重定向到虚拟机中的代理，代理会将请求转发到Kubernetes集群中的应用程序，从而实现本地开发环境和Kubernetes集群之间的协作。Bridge to Kubernetes还支持一些高级功能，例如在本地开发环境中进行调试、追踪、分析和配置微服务应用程序，以及在本地构建和部署Docker容器映像。
Telepresence是一个开源工具，可以将本地开发环境连接到远程Kubernetes集群中的应用程序。具体来说，Telepresence会在本地计算机上创建一个代理，代理会截获应用程序的流量并将其重定向到Kubernetes集群中的应用程序。与Bridge to Kubernetes不同，Telepresence不需要在本地计算机上创建虚拟机，因此可以更快地启动和运行应用程序。此外，Telepresence还支持多种模式，例如本地模式、桥接模式和VPN模式，可以满足不同的开发需求。与Bridge to Kubernetes相比，Telepresence是一个更加通用的工具，可以用于连接任何Kubernetes集群，而不仅仅是Microsoft Azure Kubernetes Service (AKS)。
总之，Bridge to Kubernetes和Telepresence都是很好的工具，可以提高开发人员的生产力和开发效率。选择哪个工具取决于您的具体需求和个人喜好。