K8S環境下研發如何本地偵錯？kt-connect使用詳解

背景

注：背景有點囉嗦，講講一路走來研發本地偵錯的變化，嫌煩的可以直接跳過，不影響閱讀。

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模式

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。

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

2. Exchange模式

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模式

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

執行命令後可以看到輸出紀錄檔裡面包含類似文字：

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

這個模式本地電腦的服務和K8S叢集裡面相同的服務同時對外響應請求，但是隻有通過指定的http請求頭VERSION: xxxx的請求才會轉發到本地電腦，相比Exchange模式，保證了其他人服務正常使用，同時研發又能進行本地偵錯。每次生成的請求頭VERSION的值都是動態生成的，如果要固定這個值，可以通過引數--versionMark寫死，例如固定值為test-version，命令如下：

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模式

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

不同於Exchange和Mesh模式要求K8S叢集有一個在執行的服務，Preview模式可以將本地電腦執行的程式部署到K8S叢集中作為一個全新的Service對外提供服務，非常便於新建服務的開發偵錯、預覽等作用。