域名解析在线_阿里工程师开发了一款免费工具，提升Kubernetes应用开发效率

对于将其作为应用运行环境的开发者，我们可以使用 () 在同一个集群内快速创建多个隔离环境，同一个 下，服务之间使用内部 DNS 域名相互访问。强大的隔离和服务编排能力允许将一组定义的业务流程（YAML）部署到多个位置。

但一般来说，所使用的容器网络无法直接与开发者办公网络对接，因此如何高效地利用其进行服务间的联调测试，成为了日常开发工作中无法回避的一道坎。本文，我们来聊聊关于如何加速研发效率。

01

使用自动管道

为了使开发者能够更加快捷的将修改后的代码部署到集群测试环境，我们一般会引入持续交付流水线，实现代码编译、镜像打包、上传、部署等自动化操作。展示：

这种方式在一定程度上可以节省开发者大量的重复劳动。然而，虽然整个过程是自动化的，但开发者每次进行代码修改时仍然需要等待流水线运行。对于开发者来说，等待每次代码更改后运行的管道可能成为整个开发任务体验中最糟糕的部分。

02

突破网络限制，本地联调

理想情况下，开发者可以直接在本地启动一个服务，并且这个服务可以无缝调用远程集群中的其他服务。需要解决两个问题：

要实现刚才提到的两种本地联调方法，需要解决以下三个问题：

本地网络和集群网络之间的直接连接问题

本地实现中内部服务的DNS解析；

如果要将集群中其他Pod的流量转移到本地服务器；

03

云效开发者工具KT

为了简化联调测试的复杂度，云效基于SSH隧道网络，结合其特点，为开发者打造了一款免费的辅助工具KT（点击文章末尾阅读原文可直接下载） ， 如下所示：

当本地运行的服务C'想要直接访问集群中命名空间中的A和B时，运行以下命令：

$ ktctl -namespace=default

KT会自动在集群中部署SSH/DNS代理容器，构建从本地到集群的VPN网络，通过DNS代理实现集群服务DNS域名解析。运行KT后，开发者本地程序可直接在集群。服务通过名称调用集群中部署的其他应用程序：

如果想要让集群中的其他Pod（例如图中的PodD和PodE）访问本地运行的程序C'，则使用以下命令指定需要替换的和本地服务端口：

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

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

运行上述两个命令之后，开发者就可以真正使用云原生的方式来开发和调试应用程序了。

04

工作准则

下面就来分析一下KT的具体使用方法，如果你迫不及待想要试用一下KT的功能，可以直接跳到文章末尾下载KT工具。

KT主要由两部分组成：

本地运行的命令行工具 ktctl

在集群中运行的 SSH/DNS 代理容器。

从工作原理上来说，KT其实就是结合自身能力实现的基于SSH的VPN网络，这部分笔者就来详细介绍一下云效开发者工具KT的工作原理：

打开SSH协议通道

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

当我们在集群中部署一个包含sshd服务的容器时，可以通过port-将容器的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

运行端口转发后，就可以直接使用SSH协议通过本地的2222端口访问集群的kt-proxy实例，从而打通本地与集群之间的SSH网络链接。

本地动态端口转发和 VPN

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

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

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

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

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

但是原生的SSH动态端口转发也有一定的局限性，就是不能直接使用UDP协议，这里我们选择一种替代的方案，如下命令所示：

# 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

该工具基于SSH协议构建简单的VPN网络，并支持DNS协议转发。

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

远程端口转发

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

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

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

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

综上所述，通过原生能力和适当的扩展，开发者可以在本地快速使用KT，打破本地网络与互联网的界限，大大提高联调测试的效率。

05

概括

工具承载着具体问题的解决方案，工程实践放大了工具的价值。阿里云效能平台致力于为开发者提供一站式企业研发与协作服务，并将阿里巴巴的软件工程实践以更成熟的形式反哺给技术社区，也欢迎更多的技术开发者加入我们。