阿里开源 KT Connnect，轻量级云原生测试环境治理平台来啦！

目前越来越多的开发者开始采纳 Kubernetes 管理基础设施环境，并通过 Kubernetes 完成日常的开发，测试以及生产发布活动，为了能够有效的帮助开发者提升在 Kubernetes 场景下的本地开发测试效率，阿里巴巴研发效能云效团队面向原生 Kubernetes 开源了一款轻量级的开发者工具 KT Connect。1. KT Connect 是什么KT Connect（Kubernete

qingdao666666

720人浏览 · 2021-08-27 22:16:24

qingdao666666 · 2021-08-27 22:16:24 发布

1. KT Connect 是什么

KT Connect（Kubernetes Developer Tool）是轻量级的面向 Kubernetes 用户的开发测试环境治理辅助工具。其核心是通过建立本地到集群以及集群到本地的双向通道，从而提升在持续交付生命周期中开发环节的效率问题以及开发测试环境的复用问题：

KT Connect 包含一组用于快速实现本地与集群联调的 Cli 命令集： connect， exchange， mesh 以及一个集中式的可视化 Dashboard。

connect： 在 kubectl 的基础上基于 SSH 协议构建本地到 Kubernetes 集群的 VPN 网络，使得用户本地能够直接访问 Kubernetes 集群的内部网络如 PodIP, ClusterIP。同时基于内置的 DNS 服务，开发者本地可以直接访问集群内的 Service DNS 地址。
exchange： 通过部署代理容器接管集群内对特定应用的全部流量并转发到开发者本地端口，从而帮助开发者将本地服务加入到集群中从而实现联调测试。
mesh： 与 exchange 类似，区别在于 mesh 不会完全接管所有流量，而是在 Service 后部署一个带有特定版本号的 Pod 实例，配合 Istio 的流量管理规则，从而可以将特定流量转发到开发者本地。

通过 KT Connect 提供的上述能力，开发者可以从传统的“开发-构建-部署”的场景中解脱，直接实现本地开发本地联调，从而可以极大的提升开发效率。同时通过 Mesh 提供混合能力，通过复用测试环境减少在基础设施层面的资源投入。

2. KT Connect 的优势

KT Connect 源于阿里巴巴研发效能在测试规模化环境治理上的丰富经验，同时受启发于像 Azure Dev Spaces 和 Telepresence 这样的开发者工具，而形成的一套面向原生 Kubernetes 用户的测试环境治理以及本地联调解决方案：

原生 Kubernetes 支持：兼容任意 Kubernetes 集群，同时支持以 kubectl 插件的方式运行；
轻量级：基于 Go 实现，且只在 connect 的 VPN 网络能力方面主要依赖 SSHUttle 工具，无其它任何第三方依赖；用户可以在任意能正常运行 kubectl 的环境中使用 KT Connect；
多种应用场景：通过与原生 Istio 的集成，支持用户独占式或者共享开发测试环境；
可视化：基于同一的 Dashboard 以及可视化能力，让用户更直观的了解测试环境的使用情况。
可扩展性： KT Connect 中提供了详细的元数据信息，用户可以快速基于 Kubernetes API 扩展 Dashboard 以及功能；

3. KT Connect 的由来

经过这么些年持续交付理念不断的深入人心以及相关实践的不断完善，发布已经成了一键可以完成的事情。整个持续交付过程越来越自动化，质量以及基础设施定义等活动不断左移，研发最大时间投入回归到代码本身。

时至今日在团队协作的模式下，无论软件研发模式或者架构这么些年来发生了多大的变化，影响软件开发效率最大的问题依然是集成的问题。

3.1 阿里巴巴解决之道

一般来说在DevOps中我们会通过持续交付流水线的方式不断的对软件进行集成，越到后面的阶段越接近生产环境，集成的验证结果也越让研发人员有信心，代码能够在生产环境上正常运行：

在理想情况下，我们希望通过自动化流水线来完成持续集成验证，各阶段环境部署。并且在这些环节上完成各角色的协作：

“谁又把日常搞挂了！！！”
“改一行代码部署十分钟……”

这些都是研发团队实践持续交付流水线后的真实心声。我们都知道本地开发本地联调是效率最高的，但是持续交付流水线本身并不解决这些问题。而幸好集团有 Aone 以及强大的中间件能力。基于中间件的隔离能力以及集团大环境下办公网络与日常环境网络是直接连通的。在真正提交集成之前，开发者可以在本地使用独立的测试环境进行联调测试：

除了独立使用的项目环境以外，为了提升日常环境的问题性，阿里 Aone 中还引入了主干环境的模式来提升集成环境的稳定性。在前面已经介绍过在集团内集成联调测试能够如此高效，是有一些前置条件的：

第一是集团能够有多余的基础设施来给开发人员独占式的使用
第二是集团网络环境办公网络与日常环境是直接打通的
第三是强大的中间件隔离能力，从而能够让流量能够按照开发者的规划流转

3.2 KT Connect 的解决方案

3.2.1 Connect 连接：

快速建立本地到集群的 VPN 网络，同时将 Kubernetes 集群的 DNS 解析能力整合到本地，让用户可以直接通过 PodIP， ClusterIP 以及 DNS 域名访问到集群内的服务：

通过建立本地到集群的通道，让开发者可以快速的与集群内的其它服务进行联调测试。同时由于兼容了 Kubernetes 的 DNS 能力，因此可以使得本地的代码仿佛是直接运行在集群中一样。

3.2.2 Exchange 交换：

那集群内的流量如何打到开发者的本地进程？ Exchange 提供了这样的能力，Exhange 命令通过在集群内部署代理容器，替换集群内的原有应用，并将所有对代理容器的请求直接转发到本地端口：

通过 Connect 和 Exchange 两个命令分别负责：本地到集群，以及集群到本地的通路。通过组合使用配合 Kubernetes 的 Namespace 隔离， Kubernetes 原生开发者可以在独占的测试环境上完成本地到集群以及集群到本地的联调与集成需求。

3.2.3 Mesh 混合：

那我们再思考一个问题：我们真的需要独占的"项目测试环境吗"？

项目环境在集团内之所以有存在的意义，归根结低还是因为环境不稳定。导致开发集成效率被直接拉低。那在 Kubernetes 下有没有办法解决呢？既然说到了这，那就证明肯定是有的。接下来就是要介绍了 KT Connect 的第三个能力： Mesh

Mesh 与 Exchange 的能力其实非常类似，在调用之后都会在集群内启动一个代理容器，并且继承原应用的标签。但是最大的差异在于 Exhange 会将原应用的 Replicas 直接降到 0，完全结果集群内所有对原应用的流量。而 Mesh 则是在保持原有应用 Pod 不变的前提下，创建一个新的代理容器并且继承原应用的所有标签，但是会新增加一个随机的 version 标签。

说到这里，读者可能在想就增加了一个 version 而已，好像并没有太大的变化。但是当配合 Service Mesh 之后就可以产生新的化学反应。由于原应用存在依然存在，Mesh 是以应用新版本的形式部署到 Kubernetes 集群内，配合 Istio 的流量规则，可以让所有正常流量依然保持对原应用的访问，而只对一些有特殊标记的的请求转发到本地。从而可以实现在一套公用测试环境的基础上各自独立的完成本地的集成联调。

3.2.4 Dashboard 可视化：

Cli 工具从客户端的角度为研发人员提供了相对便捷的方式能够让研发能够在本地快速完成联调测试，而站在测试环境管理的维度上，我们需要了解测试环境的状态，例如，当前有多少服务是被 Exchange 到了开发人员本地，服务一共 Mesh 了多少个本地版本？这部分内容在 KT Connect 中通过一个集中式的 Dashboard 提供相关的能力支撑，我们可以清楚的了解当前服务下运行了容器实例，同时是否有本地环境接入，从而可以更好的支撑多人协作的场景。

4. KT Connect 的应用场景

4.1 本地联调测试

在阿里内部，开发人员可以为每一个变更单独创建一个开发测试环境并且与本地程序进行联调，在 Kubernetes 环境中通过分配单独的命名空间，并配合 connect 和 exchange 命令的组合，可以让开发人员在独占的开发测试环境中进行联调测试。

4.2 共享开发测试环境

除了独占式的开发测试环境以外，结合 Istio 并组合 connext 和 mesh 命令，一组开发人员可以同时在一个共享的开发测试环境中完成本地的联调测试。从而可以大大节省基础设施资源的投入。

4.3 持续交付流水线

在阿里内部，我们通常会有一个单独的主干环境，每一次变更发布到正式并合并到主干代码之后，都会走动触发主干环境的部署，那意味着主干环境是默认稳定的一个环境。那在基于 Kubernetes 的持续交付流水线中，我们也可以非常方便的模拟一个主干环境，并且默认通过主干环境来进行本地的联调测试，从而避免日常环境不稳定导致无法有效的开展本地联调测试的任务。