k8s本地联调工具kt-connect

news2024/9/17 16:50:40

1、Kt Connect简介

　　KT Connect （ Kubernetes Developer Tool ）是轻量级的面向 Kubernetes 用户的开发测试环境治理辅助工具。其核心是通过建立本地到集群以及集群到本地的双向通道，从而提升在持续交付生命周期中开发环节的效率问题以及开发测试环境的复用问题。其官网如下

KT: A simple kubernetes development toolkit

2、Kt Connect能帮我们实现什么

a、直接访问Kubernetes集群

　　开发者通过KT可以直接连接Kubernetes集群内部网络，在不修改代码的情况下完成本地开发与联调测试

b、转发集群流量到本地

　　开发者可以将集群中的流量转发到本地，从而使得集群中的其它服务可以联调本地

c、Service Mesh支持

　　对于使用Istio的开发者，KT支持创建一个指向本地的Version版本

d、基于SSH的轻量级VPN网络

　　KT使用shhuttle作为网络连接实现，实现轻量级的SSH VPN网络

e、作为kubectl插件，集成到Kubectl

　　开发者也可以直接将ktctl集成到kubectl中

3、实践步骤

a、安装kubectl命令行工具，并配置本地可以访问Kubernetes集群

　　以在window环境安装kubectl命令行工具为例（ps：本文的k8s是直接使用云厂商的k8s服务）

3.1下载kubectl

　　请到kubernetes版本发布页面下载与集群版本对应的或者更新的kubectl。其下载链接如下

kubernetes/README.md at master · kubernetes/kubernetes · GitHub

3.2、安装kubectl后，配置一下环境变量，并用管理员cmd命令验证一下安装是否成功

C:\WINDOWS\system32>kubectl version --client

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.9", GitCommit:"4fb7ed12476d57b8437ada90b4f93b17ffaeed99", GitTreeState:"clean", BuildDate:"2020-07-15T16:18:16Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"windows/amd64"}

3.3、配置config文件

　　在C:\Users\Administrator目录下新建.kube文件夹，并在该文件夹下新建config文件，并把kubeconfig内容拷贝到config文件中。

3.4、验证是否可以访问Kubernetes集群

C:\WINDOWS\system32>kubectl cluster-info

Kubernetes master is running at https://apiserver地址 CoreDNS is running at https:/apiserver地址/api/v1/namespaces/kube-system/services/coredns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

b、安装KT Connect

　　以在window安装为例，下载Windows可执行文件，并解压.exe文件到PATH路径下。其下载地址如下

　https://alibaba.github.io/kt-connect/#/zh-cn/

　　将下载的文件与上面的文件放在一起

c、验证KT Connect是否安装成功

C:\WINDOWS\system32>ktctl -v

使用

　　kt-connect只会在指定连接的命名空间（namespace）里面新建一个自用的pod，然后部署一个kt-connect-shadow的镜像。分为四大模式：

1. Connect模式

　　本地网络可以直接通过serviceid直接访问k8s集群网络中的服务，但是并没有加到集群里面其他服务里面，其他服务的流量并不会转发到本地电脑。

ktctl --debug --image=10.3.87.5:8080/kt-connect-shadow:latest --namespace=k8s-project connect

或

ktctl.exe connect --kubeconfig .\kubeconfig --namespace feature-N --debug（--kubeconfig，确保有足够权限和能正确连接K8S集群的API Server）

　　在idea程序的VM options中添加

-DsocksProxyHost=127.0.0.1 -DsocksProxyPort=2223

　　在Java程序中所有网络请求完全通过KT Connect进行转发。从而可以直接在代码中访问Kubernetes集群中的服务。

注：

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 。

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

2. Exchange模式

　　Connect和Exchange模式都是单向的，一个是从集群外部到集群内部，一个是从集群内部到集群外部。

　　将集群里访问指定服务的所有请求拦截并转发到本地的指定端口。

ktctl exchange join-bpm-camunda --expose 8080 --debug --image=10.3.87.5:8080/kt-connect-shadow:latest --namespace=k8s-project

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

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

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

　　由于Nacos里面的服务最后基于ip访问，因此集群内无法通过这种方式来访问本机注册的服务。

解决：

添加 spring.cloud.nacos.discovery.ip: ${spring.application.name}

　　在discovery下注册指定ip为服务名，这样pod在调ip时会走k8s的服务代理到对应的本机ip

3. Mesh模式

　　mesh与exchange的最大区别在于，exchange会完全替换原有的应用实例。mesh命令创建代理容器，但是会保留原应用容器，代理容器会动态生成version标签，以便用于可以通过Istio流量规则将特定的流量转发到本地，同时保证环境正常链路始终可用。

ktctl mesh join-bpm-camunda --expose 8080 --debug --image=10.3.87.5:8080/kt-connect-shadow:latest --routerImage=10.3.87.5:8080/kt-connect-router:v0.3.6 --namespace=k8s-project

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

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

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

ktctl mesh join-bpm-camunda --expose 8080 --debug --image=10.3.87.5:8080/kt-connect-shadow:latest --routerImage=10.3.87.5:8080/kt-connect-router:v0.3.6 --namespace=k8s-project --versionMark debug-version

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