对于使用了Kubernetes作为应用运行环境的开发者而言，在同一个集群中我们可以使用命名空间（Namespace）快速创建多套隔离环境，在相同命名空间下，服务间使用Service的内部DNS域名进行相互访问。 基于Kubernetes强大的隔离以及服务编排能力，可以实现一套定义编排（YAML）多处部署的能力。

不过，一般来说Kubernetes使用的容器网络与开发者的所在的办公网络直接并不能直接连通。 因此，如何高效的利用Kubernetes进行服务间的联调测试，成为在日常开发工作中一道绕不开的坎。本文我们就来聊一聊，如何加速基于Kubernetes的研发效率。

使用自动流水线

为了能够让开发者能够更快的将修改的代码部署到集群测试环境中，一般来说我们会引入持续交付流水线，将代码的编译，镜像的打包上传以及部署通过自动化的方式来解决。如下所示：

从一定程度上来说，这种方式可以避免开发人员进行大量重复性的工作。但是，虽然整个过程自动化了，但是开发人员也不得不每次进行代码变更之后都需要等待流水线的运行。对于开发人员来说，每次代码变更后等待流水线运行或许已经成为整个开发任务过程中体验最糟糕的部分。

打破网络限制，本地联调

理想状态下是开发者可以直接在本地启动服务，并且这个服务就可以无缝的和远程的kubernetes集群中的各个其它服务实现互相调用。需要解决两个问题：

• 我依赖了其它的服务：运行在本地的代码可以直接通过podIP，clusterIP甚至是Kubernetes集群内的DNS地址访问到部署在集群中的其它应用，如下图左；
• 其它的服务依赖了我：运行在Kubernetes集群中的其它应用可以在不做任何改变的情况下访问我到运行的本地的代码，如下图右。

要实现刚才说的两种本地联调方式，主要需要解决以下3个问题：

• 本地网络与Kubernetes集群网络直接的连通问题
• 在本地实现Kubernetes中内部服务的DNS解析；
• 如果将对集群中其它Pod访问的流量转移到本地；

云效开发者工具KT

为了简化在Kubernetes下进行联调测试的复杂度，云效在SSH隧道网络的基础上并结合Kubernetes特性构建了一款面向开发者的免费辅助工具KT（点击前往下载），如下所示：

当本地运行的服务C’希望能够直接访问集群中default命名空间下的Service A和Service B时，运行如下命令：

$ ktctl -namespace=default

KT会自动在集群中部署SSH/DNS代理容器，并构建本地到Kubernetes集群的VPN网络并通过DNS代理实现集群服务DNS域名解析，在运行KT之后，开发者的本地程序可以直接像运行在集群中的服务一样通过service名字调用集群中部署的其它应用：

而如果希望集群中的其它Pod（比如图中的PodD和PodE）能够通过ServiceC访问到本地运行的程序C‘，通过如下命令，指定需要替换的目标Deployment以及指定本地服务端口：

#-swap-deployment指定需要替换的目标Deployment 
# -expose 指定本地服务运行的端口 
ktctl -swap-deployment c-deployment -expose=8080

KT在构建VPN网络的同时，还会自动通过代理容器接管集群原有的PodC实例，并直接转发的本地的8080端口。实现集群应用联调本地。

经过上述两个命令，开发者就可以真正的使用云原生的方式来开发调试Kubernetes中的应用了。

工作原理

下面解析KT的工作原理，如果你已经迫不及待的想尝试KT的功能，可以直接前往下载KT工具。

KT主要由两部分组成：

• 在本地运行的命令行工具ktctl
• 运行在集群中的SSH/DNS代理容器。

在工作原理上KT实际上是结合Kubernetes自身能力实现的一个基于SSH的VPN网络。这这部分，笔者将详细介绍云效Kubernetes开发者工具KT的工作原理：

打通SSH协议通道

在Kubernetes命令行工具kubectl中内置的port-forward命令可以帮助用户建立本地端口到Kubernetes集群中特定Pod实例端口间的网络转发。

当我们在集群中部署一个包含sshd服务的容器后，通过port-forward可以将容器的SSH服务端口映射到本地：

# 将对本地2222端口转发到kt-porxy实例的22端口 
$ kubectl port-forward deployments/kt-proxy 2222:22 
Forwarding from 127.0.0.1:8080 -> 8080 
Forwarding from [::1]:8080 -> 8080

在运行端口转发后，就可以直接通过本地的2222端口通过SSH协议进入到Kubernetes集群的kt-proxy实例中。从而打通本地与集群之间的SSH网络链路。

本地动态端口转发与VPN

在打通SSH网络之后，我们就可以利用SSH通道实现本地到集群的网络请求，其中最基本的方式就是使用SSH动态端口转发的能力。

使用如下命令，通过本地2000运行的代理，可以将网络请求通过集群中运行的kt-proxy容器进行转发，从而实现本地到集群网络请求的转发：

# ssh -D [本地网卡地址:]本地端口 name@ip -p映射到kt-proxy的22端口的本地端口 
ssh -D 2000 root@127.0.0.1 -p2222

在启用SSH动态端口转发后，通过设置http_proxy环境变量后，即可直接在命令行中访问集群网络：

# export http_proxy=socks5://127.0.0.1:ssh动态端口转发的代理端口 
export http_proxy=socks5://127.0.0.1:2000

不过原生SSH动态端口转发也有一定的限制那就是无法直接使用UDP协议，这里我们选择了一个替代方案sshuttle. 如下命令所示：

# export http_proxy=socks5://127.0.0.1:ssh动态端口转发的代理端口 
export http_proxy=socks5://127.0.0.1:2000 
sshuttle --dns --to-ns 172.16.1.36 -e 'ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null' -r root@127.0.0.1:2222 172.16.1.0/16 172.19.1.0/16 -vv

sshuttle工具在SSH协议之上构建了一个简易的VPN网络，同时支持DNS协议转发。

因此，接下来的问题就是实现一个自定义的DNS服务即可，而该服务在KT中是直接内置在KT代理镜像中。

远程端口转发

在本地到集群的链路打通之后。 接下来需要解决的就是从集群到本地的访问链路。这部分，我们会使用到SSH的远程端口转发能力，如下所示，指定所有对kt-proxy的8080端口的网络请求都会通过SSH隧道直接转发到本地的8080端口：

# ssh -R 8080:localhost:8080 root@127.0.0.1 -p2222 
ssh -R 8080:localhost:8080 root@127.0.0.1 -p2222

因此，在KT的实现过程之中，结合Kubernetes基于标签的松耦合能力，我们只需要克隆原有应用实例的YAML描述，并将容器替换为kt-proxy即可。从而将对集群中原有应用的请求通过SSH远程端口转发到本地。

综上，通过利用Kubernetes原生能力以及适度的扩展，开发者可以快速在本地利用KT打破本地网络与Kubernetes网络之间的界限，大大提升使用Kubernetes进行联调测试的效率。

小结

工具承载了对特定问题的解决方案，而工程技术实践则是对其价值的放大。阿里巴巴云效平台，致力于为开发者提供一站式的企业研发与协作服务，并将阿里多年的软件工程实践以一种更加开发的形态反馈技术社区，欢迎更多的技术开发者入驻。

原文链接
本文为云栖社区原创内容，未经允许不得转载。