对于使用了 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 [email protected] -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 [email protected]: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 [email protected] -p2222 ssh -R 8080:localhost:8080 [email protected] -p2222
因此，在 KT 的实现过程之中，结合 Kubernetes 基于标签的松耦合能力，我们只需要克隆原有应用实例的 YAML 描述，并将容器替换为 kt-proxy 即可。从而将对集群中原有应用的请求通过 SSH 远程端口转发到本地。
综上，通过利用 Kubernetes 原生能力以及适度的扩展，开发者可以快速在本地利用 KT 打破本地网络与 Kubernetes 网络之间的界限，大大提升使用 Kubernetes 进行联调测试的效率。
小结
工具承载了对特定问题的解决方案，而工程技术实践则是对其价值的放大。阿里巴巴云效平台，致力于为开发者提供一站式的企业研发与协作服务，并将阿里多年的软件工程实践以一种更加开发的形态反馈技术社区，欢迎更多的技术开发者入驻。
目前，Mac 用户可以下载并体验 KT 工具。
