摘要：和中的二進制文件仍然支持與中相同的供應商程序。但是二進制文件應該是可用的并且完全獨立，因為這簡化了發布和運行它。將在測試檔案中分發的二進制文件將能夠測試已安裝的存儲驅動程序，而無需重建測試套件。

作者：Patrick Ohly（英特爾）

越來越多過去是Kubernetes組件的一部分，現在搬到在Kubernetes之外開發。例如，存儲驅動程序曾經被編譯成Kubernetes二進制文件，然后被轉移到主機上的獨立Flexvolume二進制文件中，現在作為容器存儲接口（Container Storage Interface，CSI）驅動程序提供，這些驅動程序部署在Kubernetes集群內部的pod中。

這對于處理此類組件的開發者來說是一個挑戰：如何在這樣的外部組件上對Kubernetes集群進行端到端（E2E）測試？用于測試Kubernetes本身的E2E框架具有所有必要的功能。但是，嘗試在Kubernetes之外使用它很困難，只有通過仔細選擇大量依賴項的正確版本才能實現。在Kubernetes 1.13中，E2E測試變得更加簡單。

這篇博客文章總結了Kubernetes 1.13的變化。對于CSI驅動程序開發者，它將涵蓋使存儲測試可用于測試第三方CSI驅動程序。如何使用它們將基于兩個Intel CSI驅動程序顯示：

開放式基礎架構經理（Open Infrastructure Manager，OIM）

PMEM-CSI

測試這些驅動程序是大多數這些增強功能的主要動機。

E2E測試包括幾個階段：

實現測試套件。這是本篇博文的主要焦點。Kubernetes E2E框架是用Go編寫的。它依賴于Ginkgo來管理測試，而斷言（assertion）則依賴于Gomega。這些工具支持“行為驅動開發”，它描述了“規范”中的預期行為。在這篇博客文章中，“test”用于引用個別Ginkgo.It規范。測試使用client-go與Kubernetes集群進行交互。

啟動測試集群。像kubetest這樣的工具可以幫忙。

針對該群集運行E2E測試套件。Ginkgo測試套件可以使用ginkgo工具運行，也可以使用go test進行正常的Go測試。沒有任何參數，Kubernetes E2E測試套件將基于環境變量（如KUBECONFIG）連接到默認集群，與kubectl完全相同。 Kubetest還知道如何運行Kubernetes E2E套件。

所有以下增強都遵循相同的基本模式：它們使E2E框架在Kubernetes之外更有用和更容易使用，而不會改變原始Kubernetes e2e.test二進制文件的行為。

使用Kubernetes <= 1.12的E2E框架很困難的主要原因是依賴于特定于提供者的SDK，這些SDK使用了大量的軟件包。只是編譯它已經不簡單。

許多這些軟件包僅在某些測試中需要。例如，測試預配置卷的安裝必須首先通過一些非Kubernetes API，直接與特定存儲后端通信，以管理員相同的方式配置這樣的卷。

現在有嘗試從核心Kubernetes中刪除特定于云供應商的測試。在PR#68483中采用的方法可以看作是朝著這個目標邁出的一步：不是立即剝離代碼并打破所有依賴它的測試，所有特定于云供應商的代碼都被移動到test/e2e/framework/providers下的可選包中。然后，E2E框架通過每個供應商包多帶帶實現的接口訪問它。

E2E測試套件的作者決定將哪些軟件包導入測試套件。然后通過--provider命令行標志激活供應商支持。1.13和1.14中的Kubernetes e2e.test二進制文件仍然支持與1.12中相同的供應商程序。也可以不包含任何包，這意味著只有通用供應上程序可用：

“skeleton”：通過Kubernetes API訪問集群，沒有別的

“local”：跟“skeleton”差不多，但是另外kubernetes/kubernetes/cluster中的腳本可以在運行測試套件后通過ssh檢索日志

測試可能必須在運行時讀取其他文件，例如.yaml清單。但是Kubernetes e2e.test二進制文件應該是可用的并且完全獨立，因為這簡化了發布和運行它。Kubernetes構建系統中的解決方案是使用go-bindata將test/e2e/testing-manifests下的所有文件鏈接到二進制文件中。E2E框架過去對go-bindata的輸出有很強的依賴性，現在bindata支持是可選的。通過testfiles包訪問文件時，將從不同的源檢索文件：

相對于使用--repo-root參數指定的目錄

零個或多個bindata塊

e2e.test二進制文件采用控制測試執行的附加參數。2016年，開始嘗試用Viper配置文件替換所有E2E命令行參數。但是這種努力停滯不前，這使得開發者沒有明確指導他們應該如何處理特定于測試的參數。

v1.12中的方法是將所有標志添加到中央test/e2e/framework/test_context.go，這對于獨立于框架開發的測試不行。自PR#69105以來，建議使用普通標志包在其自己的源代碼中定義其參數。標記名稱必須是分層的，點分隔不同的級別，例如my.test.parameter，并且必須是唯一的。標志包強制執行唯一性，第二次注冊標志時會發生混亂。新的配置包簡化了多個選項的定義，這些選項存儲在單個結構中。

總而言之，這就是現在如何處理參數：

測試包中的init代碼定義了測試和參數。實際參數值尚不可用，因此測試定義不能使用它們。

測試套件的init代碼解析參數和配置文件（可選）。

測試運行并可以使用參數值。

但是，最近有人指出，比較可取且有可能不將測試設置公開為命令行標志，只能通過配置文件設置它們。關于這個有一個開放的bug和一個待定的PR。

Viper支持得到了增強。與供應商支持一樣，它是完全可選的。它通過導入viperconfig包被拉入e2e.test二進制文件，并在解析正常的命令行標志后調用它。這已經實現，以便當標志出現在Viper配置文件中時，也可以設置所有可以通過命令行標志設置的變量。例如，Kubernetes v1.13 e2e.test二進制文件接受--viper-config=/tmp/my-config.yaml，該文件將my.test.parameter設置為具有此內容的值：my: test: parameter: value

在較舊的Kubernetes版本中，該選項只能從當前目錄加載文件，后綴必須省略，實際上只能通過這種方式設置幾個參數。請注意Viper的一個限制仍然存在：它通過匹配已知標志的配置文件條目，而不會發出有關未知配置文件條目的警告，從而不會檢測到錯別字。Kubernetes的更好的配置文件解析器仍在開發中。

在Kubernetes 1.12中，有一些支持從.yaml文件加載單個項目，但是然后創建該項目必須通過手寫代碼完成?，F在，框架提供新方法加載具有多個項目的.yaml文件、修補這些項目（例如，設置為當前測試創建的命名空間）以及創建它們。這目前用于為每個測試重新部署CSI驅動程序，這些驅動程序來自完全相同的.yaml文件，這些文件也用于通過kubectl進行部署。如果CSI驅動程序支持以不同的名稱運行，則測試完全獨立并且可以并行運行。

但是，重新部署驅動程序會降低測試執行速度，并且不會涵蓋針對驅動程序的并發操作。更現實的測試場景是在啟動測試集群時部署驅動程序一次，然后針對該部署運行所有測試。最終，Kubernetes E2E測試將轉移到該模型，一旦更清楚如何擴展測試集群的啟動，包括安裝CSI驅動程序等其他實體。

能夠使用Kubernetes之外的框架可以構建自定義測試套件。但是沒有測試的測試套件仍然沒用。一些現有的測試，特別是用于存儲的測試，可以應用于樹外組件。感謝Masaki Kimura所做的工作，Kubernetes 1.13中的存儲測試被定義為可以針對不同的驅動程序多次實例化它們。

但歷史有重復的習慣。與供應商程序一樣，定義這些測試的程序包也提取了所有樹內存儲后端的驅動程序定義，這反過來又拉取了比所需更多的附加程序包。這在Kubernetes 1.14進行了修復。

某些存儲測試依賴于群集的功能（如在支持XFS的主機上運行）或驅動程序（如支持塊卷）。在測試運行時檢查這些條件，導致在不滿意時跳過測試。好的是這記錄解釋了為什么測試沒有運行。

開始測試很慢，特別是當它必須首先部署CSI驅動程序時，在其他情況下也差不多。在快速集群上測量為測試創建命名空間的時間為5秒，并且會產生大量噪聲測試輸出。本來可以解決這個問題，通過跳過不支持的測試的定義，然后報告為什么測試甚至不是測試套件的一部分變得棘手。這種方法已不被考慮，而是采用重新組織存儲測試套件的方式，以便在進行更昂貴的測試設置步驟之前首先檢查條件。

同樣的PR還將測試重寫，接近傳統的Ginkgo測試，測試用例及其局部變量在一個函數中。

構建自定義E2E測試套件仍然是相當多的工作。將在Kubernetes 1.14測試檔案中分發的e2e.test二進制文件將能夠測試已安裝的存儲驅動程序，而無需重建測試套件。有關詳細說明，請參閱本自述文件。

第一步是設置定義測試套件的必要樣板代碼。在Kubernetes E2E中，這是在e2e.go和e2e_test.go文件中完成的。它也可以在e2e_test.go文件中完成。Kubernetes在e2e_test.go中導入所有各種供應商程序、樹內測試、Viper配置支持和bindata文件。e2e.go控制實際執行，包括一些集群準備和指標收集。

一個更簡單的起點是來自PMEM-CSI的e2e_[test].go文件。它不使用任何供應商程序，沒有Viper，沒有bindata，只導入存儲測試。

與PMEM-CSI一樣，OIM會丟棄所有額外功能，但有點復雜，因為它將自定義集群啟動直接集成到測試套件中，在這種情況下非常有用，因為一些額外的組件必須在主機端運行。通過直接在E2E二進制文件中運行它們，使用dlv進行交互式調試變得更加容易。

這兩個CSI驅動程序都遵循Kubernetes示例，并使用test/e2e目錄作為其測試套件，但也可以使用任何其他目錄和其他文件名。

測試由導入測試套件的包定義。E2E測試唯一特有的是，它們使用framework.NewDefaultFramework實例化一個framework.Framework指針（通常稱為f）。此變量在每個測試的BeforeEach中重新初始化，并在AfterEach中釋放。它在運行時有一個f.ClientSet和f.Namespace（并且只在運行時?。梢杂蓽y試使用。

PMEM-CSI存儲測試導Kubernetes存儲測試套件，并為必須已安裝在測試集群中的PMEM-CSI驅動程序設置一個供應測試實例。存儲測試套件更改存儲類以使用不同的文件系統類型運行測試。由于此要求，存儲類是從.yaml文件創建的。

解釋框架中可用的所有各種實用方法超出了本博文的范圍。閱讀現有測試和框架的源代碼是一個很好的入門方法。

即使消除了許多不必要的依賴關系，提供Kubernetes代碼仍然不是一件容易的事。k8s.io/kubernetes并不意味著包含在其他項目中，也沒有以dep等工具理解的方式定義其依賴關系。其他k8s.io包應包含在內，但不遵循語義版本控制或不標記任何版本（k8s.io/kube-openapi，k8s.io/utils）。

PMEM-CSI使用dep。它的Gopkg.toml文件是一個很好的起點。它啟用了修剪（默認情況下未在dep中啟用）并將某些項目鎖定到與所使用的Kubernetes版本兼容的版本上。當dep沒有選擇兼容的版本時，檢查Kubernetes的Godeps.json有助于確定哪個版本可能是正確的版本。

go test ./test/e2e -args -help是測試測試套件編譯的最快方法。

一旦編譯完成并且已經設置了集群，go test -timeout=0 -v ./test/e2e -ginkgo.v命令將運行所有測試。要并行運行測試，請使用ginkgo -p ./test/e2e命令。

Kubernetes E2E框架由測試SIG的testing-commons子項目所有。請參閱該頁面以獲取聯系信息。

有各種任務，包括但不限于：

將test/e2e/framework移動到staging倉庫并重組它以使其更加模塊化（#74352）。

通過將更多代碼移入test/e2e/framework（#74353）來簡化e2e.go。

從Kubernetes E2E測試套件中刪除特定于供應商程序的代碼（#70194）。

特別感謝本文的審閱者：

Olev Kartau（https://github.com/okartau）

Mary Camp（https://github.com/MCamp859）

KubeCon + CloudNativeCon + Open Source Summit大會日期：

會議日程通告日期：2019 年 4 月 10 日

會議活動舉辦日期：2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon + Open Source Summit贊助方案
KubeCon + CloudNativeCon + Open Source Summit多元化獎學金現正接受申請
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國
KubeCon + CloudNativeCon + Open Source Summit購票窗口，立即購票！
CNCF邀請你加入最終用戶社區