阿里开源,超强大的 Kubernetes 本地调试工具 Kt-Connect 使用指南

Posted by Mike on 2022-09-27

背景

注:背景有点啰嗦,讲讲一路走来研发本地调试的变化,嫌烦的可以直接跳过,不影响阅读。

2019年

我在的公司当时是个什么情况,只有两个Java应用,还都跑在一个Tomcat Servlet容器。

当时是如何本地调试?都是研发自己电脑装个 Mysql,装个 Tomcat,自己电脑运行调试,好处嘛就是后端研发互不干扰,想怎么改就怎么改,APP端研发就直连后端的笔记本调试。上线部署嘛就是一个研发手动编译个 Jar 包丢到云服务器上面,大体就是个草台班子,能干活,但是也就那样。

2020年

到了 2020 年,公司买了一台服务器,Centos 的系统,给装上了 Mysql、Tomcat,用上了 Redis 缓存,RabbitMQ 消息队列,有了独立的测试环境,用上了 Jenkins 自动打包并部署应用,也算鸟枪换炮,起码不用自己打包了。

这个时候是如何本地调试呢?起码不用自己电脑装 Mysql 了,后面框架由 SpringMVC 和 Struts2 都改成 Spring Boot,外置的 Tomcat 也可以去掉了。后端研发本地运行 Spring Boot 时直连服务器的 Mysql 进行调试,APP 端再也不用连后端研发的笔记本了,有了相对稳定的调试环境。代价就是各个后端的数据库更新结构要保持兼容性,避免影响他人。

2021年

随着业务增长,后端框架由 Spring Boot 进化为 Spring Cloud 全家桶,应用运行环境由 Linux 直接运行改为了 Docker 镜像部署,各类中间件同样也使用了 Docker 镜像。产品线增加,单一的开发分支已经不能满足需求,为此又开辟了另外一条后端代码分支,同样的开发测试环境也多了一份。

这个时候的本地调试,对于 APP 端来说变化不大,区别连接后端不同环境使用不同域名而已。对于后端的研发同学就不一样了,每次本地调试自己电脑要常驻一个 Eureka 和一个 Config Server,如果本地调试的微服务依赖比较多,没个大内存真是顶不住。

2022年

业务量继续增加,产品同事数量增加了,那个需求量真是堆积如山,两个分支已经不能满足要求了,又开了第三个分支,还是不够。每次增加新的分支运行环境,后端研发同学也很痛苦,一堆环境和第三方平台回调需要配置。为了能动态扩容缩容,Spring Cloud 全家桶继续演进,抛弃了 Zuul 网关和 Eureka,改为使用 Spring Cloud Kubernetes,运行环境全面向 K8S 靠拢。在此期间公司又采购了一台服务器用于开发测试,内存 CPU 磁盘满上!

进入 K8S 时代,后端研发本地的电脑没办法随意连接 Linux 服务器上面的各种中间件,每个新分支环境里面的每个 POD 都是一个新的 IP,也不可能像之前那样开放指定几个中间件的端口给后端连接,那么多环境每个都做设置的话,运维同学整天不用干别的事了。也由此引出了今天要说的 kt-connect 工具,通过这个工具,后端研发本地的电脑可以代理访问到各个分支环境,也就是 K8S 里面的命名空间的所有服务,并且只需要启动需要调试的服务,大大节省了电脑 CPU 内存占用。

选型

在选择代理访问 K8S 环境以便于本地调试的工具中,网上有几种。

1. 端口转发

使用 Ingress、NodePort、LoadBalancer 之类的将流量转发到指定端口,如上文所说,会让运维同学工作量比较大,也不便于分支环境的自动创建和回收,只适合需要暴露端口数量不多的场景。

2. VPN

通过在 K8S 每个命名空间里面设置一个运行有 VPN 服务的 POD,后端研发笔记本通过 VPN 客户端连接代理进入到指定命名空间,可以正常访问和解析集群内各类服务,基本能满足日常的要求,缺点是每个命名空间都常驻了一个 VPN 服务的运行资源。

3. Telepresence

在搜索的过程中发现了这个代理工具,几乎可以说 9 成的中英文技术文章都推荐使用这个工具,功能非常强大,不但提供了 VPN 所具有的代理功能,可以访问到命名空间内所有服务,还能指定各种规则拦截指定服务的流量到本地机器,相当于本地机器也能作为一个普通的 POD 提供对外服务。大体设计原理如下:

在研发本地电脑执行如下命令

telepresence helm install --kubeconfig .\kubeconfig
telepresence connect —kubeconfig .\kubeconfig

就会自动在 K8S 集群创建一个命名空间 ambassador,并且部署一个 traffic-manager 的 Pod,用于流量管理,而在研发笔记本本地则会启动 2 个 Daemon 服务,其中一个叫 Root Daemon,用于建立一条双向代理通道,并管理本地电脑与 K8S 集群之间的流量,另外一个 User Daemon 则是负责与 Traffic Manager 通信,设置拦截规则,如果登录后还负责与 Ambassador Cloud 进行通信。

通过配置拦截规则,拦截的 Pod 里面会安装一个 traffic-agent,官方文档说明是类似 K8S 集群的 sidecar 模式,对注入 POD 进行流量劫持,所有流量出入通过 traffic-manager 进行重新路由。

The Traffic Agent is a sidecar container that facilitates intercepts. When an intercept is first started, the Traffic Agent container is injected into the workload’s pod(s).

虽然他的功能很强大,但是在目前 2.5 版本的使用过程中,为了使用他的拦截和 Preview Url 功能必须在他家的商业云平台 Ambassador Cloud 进行注册登陆(注:不知道为什么网上技术文章都没提到这点,测试的时候非得要登录他家云平台),并且拦截规则的配置是通过云平台的网页进行操作的,联网的要求,包括可能存在的安全,泄露之类的隐患,我觉得是不可接受,也因此不得不放弃使用这个工具。

还有一个不得不说的缺点就是,老版本使用后可以清理掉自动创建的命名空间(namespace)和 Pod、拦截 Agent 的功能(telepresence uninstall)也没了,在 2.5 版本的命令参数里面完全消失了,这就导致每次使用后,如果想保持环境干净,还得麻烦运维同学去清理掉,非常麻烦,简直逼死洁癖患者。

4. kt-connect

所幸开源社区又找到了另外一款类似 Telepresence 的工具,名为kt-connect,使用版本为 v0.3.6(顺便说下我们使用的 K8S 版本是 1.24),并且它无需联网登陆什么账号,结束命令执行默认还会自动清理。阿里出品,不确定是不是又一个 KPI 开源项目,但是至少这一刻我对这个工具是非常满意的。

原理

同 Telepresence 类似,但不同的是,kt-connect 只会在指定连接的命名空间(namespace)里面新建一个自用的 Pod,然后部署一个 kt-connect-shadow 的镜像。相比 Telepresence,它在模式进行了细分扩展,分为四大模式:

1. Connect模式

1
ktctl.exe connect --kubeconfig .\kubeconfig --namespace feature-N --debug

这个模式下,kt-connect 起到的是一个类似于VPN的作用,研发本地电脑可以访问到连接的命名空间(namespace)内的所有服务,但是并没有加到集群里面其他服务里面,其他服务的流量并不会转发到本地电脑。

注1:与 telepresence 类似,kt-connect 所有命令都要带上 --kubeconfig ,确保有足够权限和能正确连接 K8S 集群的 API Server,很多文章都很少提到这点,假如K8S集群限制权限,或者与研发不在同一个网络,必须确保使用运维同学提供的有足够权限的授权文件 kubeconfig 来进行连接。

注2:

Failed to setup port forward local:28344 -> pod kt-connect-shadow-gseak:53 error=“error upgrading connection: error sending request: Post “https://10.0.8.101:8443/api/v1/namespaces/feature-N/pods/kt-connect-shadow-gseak/portforward”: dial tcp 10.0.8.101:8443: connectex: A socket operation was attempted to an unreachable host.”,

如果出现以上报错的话,有可能是 kt-connect 路由 BUG,可能本地电脑的路由与新加的通往 API Server 的路由有冲突,增加参数 --excludeIps 10.0.8.101/32 即可,如果网段冲突比较多,可以扩大网段范围,例如--excludeIps 10.0.8.0/24 参考 issue-302

1
ktctl.exe connect --kubeconfig .\kubeconfig --namespace feature-N --excludeIps 10.0.8.101/32 --debug

2. Exchange模式

1
ktctl.exe exchange serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug

这个模式类似于 Telepresence 拦截模式,将指定服务的所有流量拦截下来转发到研发本地电脑的端口,使用这个模式能对环境里的访问请求直接进行调试。

具体原理就是将 service 里面的 Pod 替换成一个 serviceA-kt-exchange 的 Pod。

注1:Exchange 模式的流量方向是单向的,并不会将本地电脑主动发起的请求代理过去,如果K8S集群跟研发本地电脑不在一个网段内,需要另外开一个命令行运行 Connect 模式,确保本地服务可以正常连接 K8S 集群的其他服务,参考issue-216

注2:Exchange 模式是通过拦截 service 进行流量转发,假如集群的请求没有经过 service,例如直接解析到 Pod 类,可能就会出现拦截失败的情况(同理 Mesh 模式也是如此),所以出现问题记得跟运维同学确认K8S集群内的路由情况。

3. Mesh模式

1
kctl.exe mesh serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug

执行命令后可以看到输出日志里面包含类似文字:

1
2:30PM INF Now you can access your service by header 'VERSION: xxxxx'

这个模式本地电脑的服务和 K8S 集群里面相同的服务同时对外响应请求,但是只有通过指定的 http 请求头 VERSION: xxxx 的请求才会转发到本地电脑,相比 Exchange 模式,保证了其他人服务正常使用,同时研发又能进行本地调试。每次生成的请求头 VERSION 的值都是动态生成的,如果要固定这个值,可以通过参数 --versionMark 写死,例如固定值为 test-version,命令如下:

1
kctl.exe mesh serviceA --kubeconfig .\kubeconfig --namespace feature-N --expose 12001 --debug --versionMark test-version

具体原理就是将 serviceA 里面的 Pod 替换成一个 serviceA-kt-router 的路由镜像,负责根据请求头进行流量代理转发,另外生成一个 serviceA-kt-stuntman 服务,这个就是线上正常运行的 serviceA,还有一个serviceA-kt-mesh-xxxxx 服务,这个就负责将代理流量到本地电脑。

4. Preview模式

1
kctl.exe preview serviceB --kubeconfig .\kubeconfig --namespace feature-N --expose 12001

不同于 Exchange 和 Mesh 模式要求 K8S 集群有一个在运行的服务,Preview 模式可以将本地电脑运行的程序部署到 K8S 集群中作为一个全新的 Service 对外提供服务,非常便于新建服务的开发调试、预览等作用。

本文转载自:「 博客园 」,原文:https://url.hi-linux.com/9JmW5,版权归原作者所有。欢迎投稿,投稿邮箱: editor@hi-linux.com