作者| 阿里云技术专家 郑云龙（砧木）
目前越来越多的开发者开始采纳 Kubernetes 管理基础设施环境，并通过 Kubernetes 完成日常的开发，测试以及生产发布活动，为了能够有效的帮助开发者提升在 Kubernetes 场景下的本地开发测试效率，阿里巴巴研发效能云效团队面向原生 Kubernetes 开源了一款轻量级的开发者工具 KT Connect。
KT Connect （ Kubernetes Developer Tool ） 是轻量级的面向 Kubernetes 用户的开发测试环境治理辅助工具。其核心是通过建立本地到集群以及集群到本地的双向通道，从而提升在持续交付生命周期中开发环节的效率问题以及开发测试环境的复用问题：
KT Connect 包含一组用于快速实现本地与集群联调的 Cli 命令集： **connect，exchange，mesh **以及一个集中式的可视化 Dashboard。
通过 KT Connect 提供的上述能力，开发者可以从传统的“开发-构建-部署”的场景中解脱，直接实现本地开发本地联调，从而可以极大的提升开发效率。同时通过 Mesh 提供混合能力，通过复用测试环境减少在基础设施层面的资源投入。
KT Connect 源于阿里巴巴研发效能在测试规模化环境治理上的丰富经验，同时受启发于像 Azure Dev Spaces 和 Telepresence 这样的开发者工具，而形成的一套面向原生 Kubernetes 用户的测试环境治理以及本地联调解决方案：
经过这么些年持续交付理念不断的深入人心以及相关实践的不断完善，发布已经成了一键可以完成的事情。整个持续交付过程越来越自动化，质量以及基础设施定义等活动不断左移，研发最大时间投入回归到代码本身。
时至今日在团队协作的模式下，无论软件研发模式或者架构这么些年来发生了多大的变化，影响软件开发效率最大的问题依然是集成的问题。
一般来说在 DevOps 中我们会通过持续交付流水线的方式不断的对软件进行集成，越到后面的阶段越接近生产环境，集成的验证结果也越让研发人员有信心，代码能够在生产环境上正常运行：
在理想情况下，我们希望通过自动化流水线来完成持续集成验证，各阶段环境部署。并且在这些环节上完成各角色的协作：
这些都是研发团队实践持续交付流水线后的真实心声。我们都知道本地开发本地联调是效率最高的，但是持续交付流水线本身并不解决这些问题。而幸好集团有 Aone 以及强大的中间件能力。基于中间件的隔离能力以及集团大环境下办公网络与日常环境网络是直接连通的。在真正提交集成之前，开发者可以在本地使用独立的测试环境进行联调测试：
除了独立使用的项目环境以外，为了提升日常环境的问题性，阿里 Aone 中还引入了主干环境的模式来提升集成环境的稳定性。在前面已经介绍过在集团内集成联调测试能够如此高效，是有一些前置条件的：
快速建立本地到集群的 VPN 网络，同时将 Kubernetes 集群的 DNS 解析能力整合到本地，让用户可以直接通过 PodIP，ClusterIP 以及 DNS 域名访问到集群内的服务：
通过建立本地到集群的通道，让开发者可以快速的与集群内的其它服务进行联调测试。同时由于兼容了 Kubernetes 的 DNS 能力，因此可以使得本地的代码仿佛是直接运行在集群中一样。
那集群内的流量如何打到开发者的本地进程？ Exchange 提供了这样的能力，Exhange 命令通过在集群内部署代理容器，替换集群内的原有应用，并将所有对代理容器的请求直接转发到本地端口：
通过 Connect 和 Exchange 两个命令分别负责：本地到集群，以及集群到本地的通路。通过组合使用配合 Kubernetes 的 Namespace 隔离，Kubernetes 原生开发者可以在独占的测试环境上完成本地到集群以及集群到本地的联调与集成需求。
那我们再思考一个问题：我们真的需要独占的"项目测试环境吗"？
项目环境在集团内之所以有存在的意义，归根结低还是因为环境不稳定。导致开发集成效率被直接拉低。那在 Kubernetes 下有没有办法解决呢？既然说到了这，那就证明肯定是有的。接下来就是要介绍了 KT Connect 的第三个能力：Mesh
Mesh 与 Exchange 的能力其实非常类似，在调用之后都会在集群内启动一个代理容器，并且继承原应用的标签。 但是最大的差异在于 Exhange 会将原应用的 Replicas 直接降到 0，完全结果集群内所有对原应用的流量。 而 Mesh 则是在保持原有应用 Pod 不变的前提下，创建一个新的代理容器并且继承原应用的所有标签，但是会新增加一个随机的 version 标签。
说到这里，读者可能在想就增加了一个 version 而已，好像并没有太大的变化。但是当配合 Service Mesh 之后就可以产生新的化学反应。由于原应用存在依然存在，Mesh 是以应用新版本的形式部署到 Kubernetes 集群内，配合 Istio 的流量规则，可以让所有正常流量依然保持对原应用的访问，而只对一些有特殊标记的的请求转发到本地。从而可以实现在一套公用测试环境的基础上各自独立的完成本地的集成联调。
Cli 工具从客户端的角度为研发人员提供了相对便捷的方式能够让研发能够在本地快速完成联调测试，而站在测试环境管理的维度上，我们需要了解测试环境的状态，例如，当前有多少服务是被 Exchange 到了开发人员本地，服务一共 Mesh 了多少个本地版本？ 这部分内容在 KT Connect 中通过一个集中式的 Dashboard 提供相关的能力支撑，我们可以清楚的了解当前服务下运行了容器实例，同时是否有本地环境接入，从而可以更好的支撑多人协作的场景。
在阿里内部，开发人员可以为每一个变更单独创建一个开发测试环境并且与本地程序进行联调，在 Kubernetes 环境中通过分配单独的命名空间，并配合 connect 和 exchange 命令的组合，可以让开发人员在独占的开发测试环境中进行联调测试。
除了独占式的开发测试环境以外，结合 Istio 并组合 connext 和 mesh 命令，一组开发人员可以同时在一个共享的开发测试环境中完成本地的联调测试。从而可以大大节省基础设施资源的投入。
在阿里内部，我们通常会有一个单独的主干环境，每一次变更发布到正式并合并到主干代码之后，都会走动触发主干环境的部署，那意味着主干环境是默认稳定的一个环境。那在基于 Kubernetes 的持续交付流水线中，我们也可以非常方便的模拟一个主干环境，并且默认通过主干环境来进行本地的联调测试，从而避免日常环境不稳定导致无法有效的开展本地联调测试的任务。
我们计划平均一个月一个 Release 版本，当前规划：
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.