1、Kt Connect簡介
KT Connect （ Kubernetes Developer Tool ） 是輕量級的面向 Kubernetes 使用者的開發測試環境治理輔助工具。其核心是透過建立本地到叢集以及叢集到本地的雙向通道，從而提升在持續交付生命週期中開發環節的效率問題以及開發測試環境的複用問題。其官網如下
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。其下載連結如下
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路徑下。其下載地址如下
將下載的檔案與上面的檔案放在一起
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服務，這個就負責將代理流量到本地電腦。
4. Preview模式
ktctl preview join-bpm-camunda-debug --expose 8080 --image=10.3.87.5:8080/kt-connect-shadow:latest --namespace=k8s-project
不同於Exchange和Mesh模式，要求K8S叢集有一個在執行的服務，Preview模式可以將本地電腦執行的程式部署到K8S叢集中作為一個全新的Service對外提供服務，非常便於新建服務的開發除錯、預覽等作用。