如何進行本地調(diào)試

背景

注：背景有點啰嗦，講講一路走來研發(fā)本地調(diào)試的變化，嫌煩的可以直接跳過，不影響閱讀。

2019 年

我在的公司當(dāng)時是個什么情況，只有兩個 Java 應(yīng)用，還都跑在一個 Tomcat Servlet 容器。

當(dāng)時是如何本地調(diào)試？都是研發(fā)自己電腦裝個 Mysql，裝個 Tomcat，自己電腦運行調(diào)試，好處嘛就是后端研發(fā)互不干擾，想怎么改就怎么改，APP 端研發(fā)就直連后端的筆記本調(diào)試。上線部署嘛就是一個研發(fā)手動編譯個 Jar 包丟到云服務(wù)器上面，大體就是個草臺班子，能干活，但是也就那樣。

2020 年

到了 2020 年，公司買了一臺服務(wù)器，Centos 的系統(tǒng)，給裝上了 Mysql、Tomcat，用上了 Redis 緩存，RabbitMQ 消息隊列，有了獨立的測試環(huán)境，用上了 Jenkins 自動打包并部署應(yīng)用，也算鳥槍換炮，起碼不用自己打包了。

這個時候是如何本地調(diào)試呢？起碼不用自己電腦裝 Mysql 了，后面框架由 SpringMVC 和 Struts2 都改成 Spring Boot，外置的 Tomcat 也可以去掉了。后端研發(fā)本地運行 Spring Boot 時直連服務(wù)器的 Mysql 進行調(diào)試，APP 端再也不用連后端研發(fā)的筆記本了，有了相對穩(wěn)定的調(diào)試環(huán)境。代價就是各個后端的數(shù)據(jù)庫更新結(jié)構(gòu)要保持兼容性，避免影響他人。

2021 年

隨著業(yè)務(wù)增長，后端框架由 Spring Boot 進化為 Spring Cloud 全家桶，應(yīng)用運行環(huán)境由 Linux 直接運行改為了 Docker 鏡像部署，各類中間件同樣也使用了 Docker 鏡像。產(chǎn)品線增加，單一的開發(fā)分支已經(jīng)不能滿足需求，為此又開辟了另外一條后端代碼分支，同樣的開發(fā)測試環(huán)境也多了一份。

這個時候的本地調(diào)試，對于 APP 端來說變化不大，區(qū)別連接后端不同環(huán)境使用不同域名而已。對于后端的研發(fā)同學(xué)就不一樣了，每次本地調(diào)試自己電腦要常駐一個 Eureka 和一個 Config Server，如果本地調(diào)試的微服務(wù)依賴比較多，沒個大內(nèi)存真是頂不住。

2022 年

業(yè)務(wù)量繼續(xù)增加，產(chǎn)品同事數(shù)量增加了，那個需求量真是堆積如山，兩個分支已經(jīng)不能滿足要求了，又開了第三個分支，還是不夠。每次增加新的分支運行環(huán)境，后端研發(fā)同學(xué)也很痛苦，一堆環(huán)境和第三方平臺回調(diào)需要配置。為了能動態(tài)擴容縮容，Spring Cloud 全家桶繼續(xù)演進，拋棄了 Zuul 網(wǎng)關(guān)和 Eureka，改為使用 Spring Cloud Kubernetes，運行環(huán)境全面向 K8S 靠攏。在此期間公司又采購了一臺服務(wù)器用于開發(fā)測試，內(nèi)存 CPU 磁盤滿上!

進入 K8S 時代，后端研發(fā)本地的電腦沒辦法隨意連接 Linux 服務(wù)器上面的各種中間件，每個新分支環(huán)境里面的每個 POD 都是一個新的 ip，也不可能像之前那樣開放指定幾個中間件的端口給后端連接，那么多環(huán)境每個都做設(shè)置的話，運維同學(xué)整天不用干別的事了。也由此引出了今天要說的 kt-connect 工具，通過這個工具，后端研發(fā)本地的電腦可以代理訪問到各個分支環(huán)境，也就是 K8S 里面的命名空間的所有服務(wù)，并且只需要啟動需要調(diào)試的服務(wù)，大大節(jié)省了電腦 CPU 內(nèi)存占用。

選型

在選擇代理訪問 K8S 環(huán)境以便于本地調(diào)試的工具中，網(wǎng)上有幾種。

1. 端口轉(zhuǎn)發(fā)

使用 Ingress、NodePort、LoadBalancer 之類的將流量轉(zhuǎn)發(fā)到指定端口，如上文所說，會讓運維同學(xué)工作量比較大，也不便于分支環(huán)境的自動創(chuàng)建和回收，只適合需要暴露端口數(shù)量不多的場景。

2. VPN

通過在 K8S 每個命名空間里面設(shè)置一個運行有 VPN 服務(wù)的 POD，后端研發(fā)筆記本通過 VPN 客戶端連接代理進入到指定命名空間，可以正常訪問和解析集群內(nèi)各類服務(wù)，基本能滿足日常的要求，缺點是每個命名空間都常駐了一個 VPN 服務(wù)的運行資源。

3. Telepresence

在搜索的過程中發(fā)現(xiàn)了這個代理工具，幾乎可以說 9 成的中英文技術(shù)文章都推薦使用這個工具，功能非常強大，不但提供了 VPN 所具有的代理功能，可以訪問到命名空間內(nèi)所有服務(wù)，還能指定各種規(guī)則攔截指定服務(wù)的流量到本地機器，相當(dāng)于本地機器也能作為一個普通的 POD 提供對外服務(wù)。大體設(shè)計原理如下：

在研發(fā)本地電腦執(zhí)行如下命令

telepresencehelminstall--kubeconfig.kubeconfig
telepresenceconnect---kubeconfig.kubeconfig

就會自動在 K8S 集群創(chuàng)建一個命名空間 ambassador，并且部署一個 traffic-manager 的 pod，用于流量管理，而在研發(fā)筆記本本地則會啟動 2 個 daemon 服務(wù)，其中一個叫 Root Daemon，用于建立一條雙向代理通道，并管理本地電腦與 K8S 集群之間的流量，另外一個 User Daemon 則是負責(zé)與 Traffic Manager 通信，設(shè)置攔截規(guī)則，如果登錄后還負責(zé)與 Ambassador Cloud 進行通信。

通過配置攔截規(guī)則，攔截的 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 功能必須在他家的商業(yè)云平臺 Ambassador Cloud 進行注冊登陸(注：不知道為什么網(wǎng)上技術(shù)文章都沒提到這點，測試的時候非得要登錄他家云平臺)，并且攔截規(guī)則的配置是通過云平臺的網(wǎng)頁進行操作的，聯(lián)網(wǎng)的要求，包括可能存在的安全，泄露之類的隱患，我覺得是不可接受，也因此不得不放棄使用這個工具。

還有一個不得不說的缺點就是，老版本使用后可以清理掉自動創(chuàng)建的命名空間（namespace）和 pod、攔截 agent 的功能（telepresence uninstall）也沒了，在 2.5 版本的命令參數(shù)里面完全消失了，這就導(dǎo)致每次使用后，如果想保持環(huán)境干凈，還得麻煩運維同學(xué)去清理掉，非常麻煩，簡直逼死潔癖患者。

4. kt-connect

所幸開源社區(qū)又找到了另外一款類似 Telepresence 的工具，名為 kt-connect：

https://github.com/alibaba/kt-connect

使用版本為 v0.3.6（順便說下我們使用的 K8S 版本是 1.24），并且它無需聯(lián)網(wǎng)登陸什么賬號，結(jié)束命令執(zhí)行默認還會自動清理。阿里出品，不確定是不是又一個 KPI 開源項目，但是至少這一刻我對這個工具是非常滿意的。

原理

同 Telepresence 類似，但不同的是，kt-connect 只會在指定連接的命名空間（namespace）里面新建一個自用的 pod，然后部署一個 kt-connect-shadow 的鏡像。相比 Telepresence，它在模式進行了細分擴展，分為四大模式：

1. Connect 模式

ktctl.execonnect--kubeconfig.kubeconfig--namespacefeature-N--debug

這個模式下，kt-connect 起到的是一個類似于 VPN 的作用，研發(fā)本地電腦可以訪問到連接的命名空間(namespace)內(nèi)的所有服務(wù)，但是并沒有加到集群里面其他服務(wù)里面，其他服務(wù)的流量并不會轉(zhuǎn)發(fā)到本地電腦。

注 1： 與 telepresence 類似，kt-connect 所有命令都要帶上--kubeconfig，確保有足夠權(quán)限和能正確連接 K8S 集群的 API Server，很多文章都很少提到這點，假如 K8S 集群限制權(quán)限，或者與研發(fā)不在同一個網(wǎng)絡(luò)，必須確保使用運維同學(xué)提供的有足夠權(quán)限的授權(quán)文件 kubeconfig 來進行連接。
注 2：

Failedtosetupportforwardlocal:28344->podkt-connect-shadow-gseak:53error="errorupgradingconnection:errorsendingrequest:Post"[https://10.0.8.101:8443/api/v1/namespaces/feature-N/pods/kt-connect-shadow-gseak/portforward](https://10.0.8.101:8443/api/v1/namespaces/feature-N/pods/kt-connect-shadow-gseak/portforward)":dialtcp10.0.8.101connectex:Asocketoperationwasattemptedtoanunreachablehost."，

如果出現(xiàn)以上報錯的話，有可能是 kt-connect 路由 BUG，可能本地電腦的路由與新加的通往 API Server 的路由有沖突，增加參數(shù)--excludeIps 10.0.8.101/32 即可，如果網(wǎng)段沖突比較多，可以擴大網(wǎng)段范圍，例如--excludeIps 10.0.8.0/24 參考 issue-302:

https://github.com/alibaba/kt-connect/issues/302

ktctl.execonnect--kubeconfig.kubeconfig--namespacefeature-N--excludeIps10.0.8.101/32--debug

2. Exchange 模式

ktctl.exeexchangeserviceA--kubeconfig.kubeconfig--namespacefeature-N--expose12001--debug

這個模式類似于 Telepresence 攔截模式，將指定服務(wù)的所有流量攔截下來轉(zhuǎn)發(fā)到研發(fā)本地電腦的端口，使用這個模式能對環(huán)境里的訪問請求直接進行調(diào)試。
具體原理就是將 service 里面的 pod 替換成一個 serviceA-kt-exchange 的 pod。

注 1： Exchange 模式的流量方向是單向的，并不會將本地電腦主動發(fā)起的請求代理過去，如果 K8S 集群跟研發(fā)本地電腦不在一個網(wǎng)段內(nèi)，需要另外開一個命令行運行 Connect 模式，確保本地服務(wù)可以正常連接 K8S 集群的其他服務(wù)，參考 issue-216：

https://github.com/alibaba/kt-connect/issues/216

注 2： Exchange 模式是通過攔截 service 進行流量轉(zhuǎn)發(fā)，假如集群的請求沒有經(jīng)過 service，例如直接解析到 pod 之類，可能就會出現(xiàn)攔截失敗的情況（同理 Mesh 模式也是如此），所以出現(xiàn)問題記得跟運維同學(xué)確認 K8S 集群內(nèi)的路由情況。

3. Mesh 模式

kctl.exemeshserviceA--kubeconfig.kubeconfig--namespacefeature-N--expose12001--debug

執(zhí)行命令后可以看到輸出日志里面包含類似文字：

2:30PMINFNowyoucanaccessyourservicebyheader'VERSION:xxxxx'

這個模式本地電腦的服務(wù)和 K8S 集群里面相同的服務(wù)同時對外響應(yīng)請求，但是只有通過指定的 http 請求頭 VERSION: xxxx 的請求才會轉(zhuǎn)發(fā)到本地電腦，相比 Exchange 模式，保證了其他人服務(wù)正常使用，同時研發(fā)又能進行本地調(diào)試。每次生成的請求頭 VERSION 的值都是動態(tài)生成的，如果要固定這個值，可以通過參數(shù)--versionMark 寫死，例如固定值為 test-version，命令如下：

kctl.exemeshserviceA--kubeconfig.kubeconfig--namespacefeature-N--expose12001--debug--versionMarktest-version

具體原理就是將 serviceA 里面的 Pod 替換成一個 serviceA-kt-router 的路由鏡像，負責(zé)根據(jù)請求頭進行流量代理轉(zhuǎn)發(fā)，另外生成一個 serviceA-kt-stuntman 服務(wù)，這個就是線上正常運行的 serviceA，還有一個 serviceA-kt-mesh-xxxxx 服務(wù)，這個就負責(zé)將代理流量到本地電腦。

4. Preview 模式

kctl.exepreviewserviceB--kubeconfig.kubeconfig--namespacefeature-N--expose12001

不同于 Exchange 和 Mesh 模式要求 K8S 集群有一個在運行的服務(wù)，Preview 模式可以將本地電腦運行的程序部署到 K8S 集群中作為一個全新的 Service 對外提供服務(wù)，非常便于新建服務(wù)的開發(fā)調(diào)試、預(yù)覽等作用。