歡迎光臨
每天分享高質量文章

KT:一款提升Kubernetes應用開發效率的免費工具

對於使用了Kubernetes作為應用運行環境的開發者而言,在同一個集群中我們可以使用命名空間(Namespace)快速創建多套隔離環境,在相同命名空間下,服務間使用Service的內部DNS域名進行相互訪問。 基於Kubernetes強大的隔離以及服務編排能力,可以實現一套定義編排(YAML)多處部署的能力。
不過,一般來說Kubernetes使用的容器網絡與開發者的所在的辦公網絡直接並不能直接連通。 因此,如何高效的利用Kubernetes進行服務間的聯調測試,成為在日常開發工作中一道繞不開的坎。本文我們就來聊一聊,如何加速基於Kubernetes的研發效率。
使用自動流水線

 

為了能夠讓開發者能夠更快的將修改的代碼部署到集群測試環境中,一般來說我們會引入持續交付流水線,將代碼的編譯,鏡像的打包上傳以及部署通過自動化的方式來解決。如下所示: 
從一定程度上來說,這種方式可以避免開發人員進行大量重覆性的工作。但是,雖然整個過程自動化了,但是開發人員也不得不每次進行代碼變更之後都需要等待流水線的運行。對於開發人員來說,每次代碼變更後等待流水線運行或許已經成為整個開發任務過程中體驗最糟糕的部分。
打破網絡限制,本地聯調

 

理想狀態下是開發者可以直接在本地啟動服務,並且這個服務就可以無縫的和遠程的Kubernetes集群中的各個其它服務實現互相呼叫。需要解決兩個問題:
  • 我依賴了其它的服務:運行在本地的代碼可以直接通過PodIP,ClusterIP甚至是Kubernetes集群內的DNS地址訪問到部署在集群中的其它應用,如下圖左;

  • 其它的服務依賴了我:運行在Kubernetes集群中的其它應用可以在不做任何改變的情況下訪問我到運行的本地的代碼,如下圖右。

要實現剛纔說的兩種本地聯調方式,主要需要解決以下3個問題:
  1. 本地網絡與Kubernetes集群網絡直接的連通問題;

  2. 在本地實現Kubernetes中內部服務的DNS解析;

  3. 如果將對集群中其它Pod訪問的流量轉移到本地。

雲效開發者工具KT

 

為了簡化在Kubernetes下進行聯調測試的複雜度,雲效在SSH隧道網絡的基礎上並結合Kubernetes特性構建了一款面向開發者的免費輔助工具KT(文末有下載鏈接),如下所示: 
當本地運行的服務C’希望能夠直接訪問集群中default命名空間下的Service A和Service B時,運行如下命令:
  1. $ ktctl -namespace=default
KT會自動在集群中部署SSH/DNS代理容器,並構建本地到Kubernetes集群的VPN網絡並通過DNS代理實現集群服務DNS域名解析,在運行KT之後,開發者的本地程式可以直接像運行在集群中的服務一樣通過Service名字呼叫集群中部署的其它應用:
而如果希望集群中的其它Pod(比如圖中的PodD和PodE)能夠通過ServiceC訪問到本地運行的程式C‘,通過如下命令,指定需要替換的標的Deployment以及指定本地服務端口:
  1. # -swap-deployment指定需要替換的標的Deployment
  2. # -expose 指定本地服務運行的端口
  3. ktctl -swap-deployment c-deployment -expose=8080
KT在構建VPN網絡的同時,還會自動通過代理容器接管集群原有的PodC實體,並直接轉發的本地的8080端口。實現集群應用聯調本地。
經過上述兩個命令,開發者就可以真正的使用雲原生的方式來開發除錯Kubernetes中的應用了。
工作原理

 

下麵解析KT的工作原理,如果你已經迫不及待的想嘗試KT的功能,可以直接跳到文章末尾下載KT工具。
KT主要由兩部分組成:
  1. 在本地運行的命令列工具ktctl

  2. 運行在集群中的SSH/DNS代理容器

在工作原理上KT實際上是結合Kubernetes自身能力實現的一個基於SSH的VPN網絡。這這部分,筆者將詳細介紹雲效Kubernetes開發者工具KT的工作原理:
打通SSH協議通道
在Kubernetes命令列工具kubectl中內置的port-forward命令可以幫助用戶建立本地端口到Kubernetes集群中特定Pod實體端口間的網絡轉發。
當我們在集群中部署一個包含sshd服務的容器後,通過port-forward可以將容器的SSH服務端口映射到本地:
  1. # 將對本地2222端口轉發到kt-porxy實體的22端口
  2. $ kubectl port-forward deployments/kt-proxy 2222:22
  3. Forwarding from 127.0.0.1:8080 -> 8080
  4. Forwarding from [::1]:8080 -> 8080
在運行端口轉發後,就可以直接通過本地的2222端口通過SSH協議進入到Kubernetes集群的kt-proxy實體中。從而打通本地與集群之間的SSH網絡鏈路。
本地動態端口轉發與VPN
在打通SSH網絡之後,我們就可以利用SSH通道實現本地到集群的網絡請求,其中最基本的方式就是使用SSH動態端口轉發的能力。
使用如下命令,通過本地2000運行的代理,可以將網絡請求通過集群中運行的kt-proxy容器進行轉發,從而實現本地到集群網絡請求的轉發:
  1. # ssh -D [本地網卡地址:]本地端口 [email protected] -p映射到kt-proxy的22端口的本地端口
  2. ssh -D 2000 [email protected].0.0.1 -p2222
在啟用SSH動態端口轉發後,通過設置http_proxy環境變數後,即可直接在命令列中訪問集群網絡:
  1. # export http_proxy=socks5://127.0.0.1:ssh動態端口轉發的代理端口
  2. export http_proxy=socks5://127.0.0.1:2000
不過原生SSH動態端口轉發也有一定的限制那就是無法直接使用UDP協議,這裡我們選擇了一個替代方案sshuttle,如下命令所示:
  1. # export http_proxy=socks5://127.0.0.1:ssh動態端口轉發的代理端口
  2. export http_proxy=socks5://127.0.0.1:2000
  3. sshuttle --dns --to-ns 172.16.1.36 -e 'ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null' -r [email protected].0.0.1:2222 172.16.1.0/16 172.19.1.0/16 -vv
sshuttle工具在SSH協議之上構建了一個簡易的VPN網絡,同時支持DNS協議轉發。
因此,接下來的問題就是實現一個自定義的DNS服務即可,而該服務在KT中是直接內置在KT代理鏡像中。
遠程端口轉發
在本地到集群的鏈路打通之後。 接下來需要解決的就是從集群到本地的訪問鏈路。這部分,我們會使用到SSH的遠程端口轉發能力,如下所示,指定所有對kt-proxy的8080端口的網絡請求都會通過SSH隧道直接轉發到本地的8080端口:
  1. # ssh -R 8080:localhost:8080 [email protected] -p2222
  2. ssh -R 8080:localhost:8080 [email protected].0.0.1 -p2222
因此,在KT的實現過程之中,結合Kubernetes基於標簽的松耦合能力,我們只需要克隆原有應用實體的YAML描述,並將容器替換為kt-proxy即可。從而將對集群中原有應用的請求通過SSH遠程端口轉發到本地。
綜上,通過利用Kubernetes原生能力以及適度的擴展,開發者可以快速在本地利用KT打破本地網絡與Kubernetes網絡之間的界限,大大提升使用Kubernetes進行聯調測試的效率。
小結

 

工具承載了對特定問題的解決方案,而工程技術實踐則是對其價值的放大。阿裡巴巴雲效平臺,致力於為開發者提供一站式的企業研發與協作服務,並將阿裡多年的軟體工程實踐以一種更加開發的形態反饋技術社區,歡迎更多的技術開發者入駐。
目前,Mac用戶可以下載並體驗KT工具:https://yq.aliyun.com/download/3393。

赞(1)

分享創造快樂