目前越來越多的開發者開始採納 Kubernetes 管理基礎設施環境，並通過 Kubernetes 完成日常的開發，測試以及生產釋出活動，為了能夠有效的幫助開發者提升在 Kubernetes 場景下的本地開發測試效率，阿里巴巴研發效能雲效團隊面向原生 Kubernetes 開源了一款輕量級的開發者工具 KT Connect。

1. KT Connect 是什麼

KT Connect（Kubernetes Developer Tool） 是輕量級的面向 Kubernetes 使用者的開發測試環境治理輔助工具。其核心是通過建立本地到叢集以及叢集到本地的雙向通道，從而提升在持續交付生命週期中開發環節的效率問題以及開發測試環境的複用問題：

KT Connect 包含一組用於快速實現本地與叢集聯調的 Cli 命令集： connect， exchange， mesh 以及一個集中式的視覺化 Dashboard。

• connect： 在 kubectl 的基礎上基於 SSH 協議構建本地到 Kubernetes 叢集的 VPN 網路，使得使用者本地能夠直接訪問 Kubernetes 叢集的內部網路如 PodIP, ClusterIP。同時基於內建的 DNS 服務，開發者本地可以直接訪問叢集內的 Service DNS 地址。
• exchange： 通過部署代理容器接管叢集內對特定應用的全部流量並轉發到開發者本地埠，從而幫助開發者將本地服務加入到叢集中從而實現聯調測試。
• mesh： 與 exchange 類似，區別在於 mesh 不會完全接管所有流量，而是在 Service 後部署一個帶有特定版本號的 Pod 例項，配合 Istio 的流量管理規則，從而可以將特定流量轉發到開發者本地。

通過 KT Connect 提供的上述能力，開發者可以從傳統的“開發-構建-部署”的場景中解脫，直接實現本地開發本地聯調，從而可以極大的提升開發效率。同時通過 Mesh 提供混合能力，通過複用測試環境減少在基礎設施層面的資源投入。

2. KT Connect 的優勢

KT Connect 源於阿里巴巴研發效能在測試規模化環境治理上的豐富經驗，同時受啟發於像 Azure Dev Spaces 和 Telepresence 這樣的開發者工具，而形成的一套面向原生 Kubernetes 使用者的測試環境治理以及本地聯調解決方案：

• 原生 Kubernetes 支援：相容任意 Kubernetes 叢集，同時支援以 kubectl 外掛的方式執行；
• 輕量級：基於 Go 實現，且只在 connect 的 VPN 網路能力方面主要依賴 SSHUttle 工具，無其它任何第三方依賴；使用者可以在任意能正常執行 kubectl 的環境中使用 KT Connect；
• 多種應用場景：通過與原生 Istio 的整合，支援使用者獨佔式或者共享開發測試環境；
• 視覺化：基於同一的 Dashboard 以及視覺化能力，讓使用者更直觀的瞭解測試環境的使用情況。
• 可擴充套件性： KT Connect 中提供了詳細的元資料資訊，使用者可以快速基於 Kubernetes API 擴充套件 Dashboard 以及功能；

3. KT Connect 的由來

經過這麼些年持續交付理念不斷的深入人心以及相關實踐的不斷完善，釋出已經成了一鍵可以完成的事情。整個持續交付過程越來越自動化，質量以及基礎設施定義等活動不斷左移，研發最大時間投入迴歸到程式碼本身。

時至今日在團隊協作的模式下，無論軟體研發模式或者架構這麼些年來發生了多大的變化，影響軟體開發效率最大的問題依然是整合的問題。

3.1 阿里巴巴解決之道

一般來說在DevOps中我們會通過持續交付流水線的方式不斷的對軟體進行整合，越到後面的階段越接近生產環境，整合的驗證結果也越讓研發人員有信心，程式碼能夠在生產環境上正常執行：

在理想情況下，我們希望通過自動化流水線來完成持續整合驗證，各階段環境部署。並且在這些環節上完成各角色的協作：

• “誰又把日常搞掛了！！！”
• “改一行程式碼部署十分鐘……”

這些都是研發團隊實踐持續交付流水線後的真實心聲。我們都知道本地開發本地聯調是效率最高的，但是持續交付流水線本身並不解決這些問題。而幸好集團有 Aone 以及強大的中介軟體能力。基於中介軟體的隔離能力以及集團大環境下辦公網路與日常環境網路是直接連通的。在真正提交整合之前，開發者可以在本地使用獨立的測試環境進行聯調測試：

除了獨立使用的專案環境以外，為了提升日常環境的問題性，阿里 Aone 中還引入了主幹環境的模式來提升整合環境的穩定性。在前面已經介紹過在集團內整合聯調測試能夠如此高效，是有一些前置條件的：

• 第一是集團能夠有多餘的基礎設施來給開發人員獨佔式的使用
• 第二是集團網路環境辦公網路與日常環境是直接打通的
• 第三是強大的中介軟體隔離能力，從而能夠讓流量能夠按照開發者的規劃流轉

3.2 KT Connect 的解決方案

3.2.1 Connect 連線：

快速建立本地到叢集的 VPN 網路，同時將 Kubernetes 叢集的 DNS 解析能力整合到本地，讓使用者可以直接通過 PodIP， ClusterIP 以及 DNS 域名訪問到叢集內的服務：

通過建立本地到叢集的通道，讓開發者可以快速的與叢集內的其它服務進行聯調測試。同時由於相容了 Kubernetes 的 DNS 能力，因此可以使得本地的程式碼彷彿是直接執行在叢集中一樣。

3.2.2 Exchange 交換：

那叢集內的流量如何打到開發者的本地程序？ Exchange 提供了這樣的能力，Exhange 命令通過在叢集內部署代理容器，替換叢集內的原有應用，並將所有對代理容器的請求直接轉發到本地埠：


通過 Connect 和 Exchange 兩個命令分別負責：本地到叢集，以及叢集到本地的通路。通過組合使用配合 Kubernetes 的 Namespace 隔離， Kubernetes 原生開發者可以在獨佔的測試環境上完成本地到叢集以及叢集到本地的聯調與整合需求。

3.2.3 Mesh 混合：

那我們再思考一個問題：我們真的需要獨佔的"專案測試環境嗎"？

專案環境在集團內之所以有存在的意義，歸根結低還是因為環境不穩定。導致開發整合效率被直接拉低。那在 Kubernetes 下有沒有辦法解決呢？既然說到了這，那就證明肯定是有的。接下來就是要介紹了 KT Connect 的第三個能力： Mesh

Mesh 與 Exchange 的能力其實非常類似，在呼叫之後都會在叢集內啟動一個代理容器，並且繼承原應用的標籤。 但是最大的差異在於 Exhange 會將原應用的 Replicas 直接降到 0，完全結果叢集內所有對原應用的流量。 而 Mesh 則是在保持原有應用 Pod 不變的前提下，建立一個新的代理容器並且繼承原應用的所有標籤，但是會新增加一個隨機的 version 標籤。

說到這裡，讀者可能在想就增加了一個 version 而已，好像並沒有太大的變化。但是當配合 Service Mesh 之後就可以產生新的化學反應。由於原應用存在依然存在，Mesh 是以應用新版本的形式部署到 Kubernetes 叢集內，配合 Istio 的流量規則，可以讓所有正常流量依然保持對原應用的訪問，而只對一些有特殊標記的的請求轉發到本地。從而可以實現在一套公用測試環境的基礎上各自獨立的完成本地的整合聯調。

3.2.4 Dashboard 視覺化：

Cli 工具從客戶端的角度為研發人員提供了相對便捷的方式能夠讓研發能夠在本地快速完成聯調測試，而站在測試環境管理的維度上，我們需要了解測試環境的狀態，例如，當前有多少服務是被 Exchange 到了開發人員本地，服務一共 Mesh 了多少個本地版本？ 這部分內容在 KT Connect 中通過一個集中式的 Dashboard 提供相關的能力支撐，我們可以清楚的瞭解當前服務下運行了容器例項，同時是否有本地環境接入，從而可以更好的支撐多人協作的場景。

4. KT Connect 的應用場景

4.1 本地聯調測試

在阿里內部，開發人員可以為每一個變更單獨建立一個開發測試環境並且與本地程式進行聯調，在 Kubernetes 環境中通過分配單獨的名稱空間，並配合 connect 和 exchange 命令的組合，可以讓開發人員在獨佔的開發測試環境中進行聯調測試。

4.2 共享開發測試環境

除了獨佔式的開發測試環境以外，結合 Istio 並組合 connext 和 mesh 命令，一組開發人員可以同時在一個共享的開發測試環境中完成本地的聯調測試。從而可以大大節省基礎設施資源的投入。

4.3 持續交付流水線

在阿里內部，我們通常會有一個單獨的主幹環境，每一次變更釋出到正式併合併到主幹程式碼之後，都會走動觸發主幹環境的部署，那意味著主幹環境是預設穩定的一個環境。那在基於 Kubernetes 的持續交付流水線中，我們也可以非常方便的模擬一個主幹環境，並且預設通過主幹環境來進行本地的聯調測試，從而避免日常環境不穩定導致無法有效的開展本地聯調測試的任務。

5. RoadMap

我們計劃平均一個月一個 Release 版本，當前規劃：

視覺化與測試環境管理

• 提供測試環境模板和基線管理幫助使用者一鍵拉起測試環境；
• Namespace 保護機制，叢集中即包含測試環境又包含生產環境的叢集提供 Namespace 保護機制，避免客戶端接管生產環境流量；
• 視覺化能力增強叢集整體視覺化拓撲；
• Istio 視覺化管理，通過 Dashboard 視覺化或者自動化生成流量規則；

效能和穩定性優化

• 優化代理容器大小以及啟動速度，提升啟動效率；
• Cli 優化程序管理能力；
• Cli 中 Istio 能力增強，在 Cli 中定義流量轉發規則

原文連結
本文為雲棲社群原創內容，未經