摘要：和中的二進(jìn)制文件仍然支持與中相同的供應(yīng)商程序。但是二進(jìn)制文件應(yīng)該是可用的并且完全獨(dú)立，因?yàn)檫@簡化了發(fā)布和運(yùn)行它。將在測試檔案中分發(fā)的二進(jìn)制文件將能夠測試已安裝的存儲驅(qū)動程序，而無需重建測試套件。

作者：Patrick Ohly（英特爾）

越來越多過去是Kubernetes組件的一部分，現(xiàn)在搬到在Kubernetes之外開發(fā)。例如，存儲驅(qū)動程序曾經(jīng)被編譯成Kubernetes二進(jìn)制文件，然后被轉(zhuǎn)移到主機(jī)上的獨(dú)立Flexvolume二進(jìn)制文件中，現(xiàn)在作為容器存儲接口（Container Storage Interface，CSI）驅(qū)動程序提供，這些驅(qū)動程序部署在Kubernetes集群內(nèi)部的pod中。

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

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

開放式基礎(chǔ)架構(gòu)經(jīng)理（Open Infrastructure Manager，OIM）

PMEM-CSI

測試這些驅(qū)動程序是大多數(shù)這些增強(qiáng)功能的主要動機(jī)。

E2E測試包括幾個階段：

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

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

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

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

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

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

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

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

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

“l(fā)ocal”：跟“skeleton”差不多，但是另外kubernetes/kubernetes/cluster中的腳本可以在運(yùn)行測試套件后通過ssh檢索日志

測試可能必須在運(yùn)行時讀取其他文件，例如.yaml清單。但是Kubernetes e2e.test二進(jìn)制文件應(yīng)該是可用的并且完全獨(dú)立，因?yàn)檫@簡化了發(fā)布和運(yùn)行它。Kubernetes構(gòu)建系統(tǒng)中的解決方案是使用go-bindata將test/e2e/testing-manifests下的所有文件鏈接到二進(jìn)制文件中。E2E框架過去對go-bindata的輸出有很強(qiáng)的依賴性，現(xiàn)在bindata支持是可選的。通過testfiles包訪問文件時，將從不同的源檢索文件：

相對于使用--repo-root參數(shù)指定的目錄

零個或多個bindata塊

e2e.test二進(jìn)制文件采用控制測試執(zhí)行的附加參數(shù)。2016年，開始嘗試用Viper配置文件替換所有E2E命令行參數(shù)。但是這種努力停滯不前，這使得開發(fā)者沒有明確指導(dǎo)他們應(yīng)該如何處理特定于測試的參數(shù)。

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

總而言之，這就是現(xiàn)在如何處理參數(shù)：

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

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

測試運(yùn)行并可以使用參數(shù)值。

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

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

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

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

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

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

但歷史有重復(fù)的習(xí)慣。與供應(yīng)商程序一樣，定義這些測試的程序包也提取了所有樹內(nèi)存儲后端的驅(qū)動程序定義，這反過來又拉取了比所需更多的附加程序包。這在Kubernetes 1.14進(jìn)行了修復(fù)。

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

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

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

構(gòu)建自定義E2E測試套件仍然是相當(dāng)多的工作。將在Kubernetes 1.14測試檔案中分發(fā)的e2e.test二進(jìn)制文件將能夠測試已安裝的存儲驅(qū)動程序，而無需重建測試套件。有關(guān)詳細(xì)說明，請參閱本自述文件。

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

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

與PMEM-CSI一樣，OIM會丟棄所有額外功能，但有點(diǎn)復(fù)雜，因?yàn)樗鼘⒆远x集群啟動直接集成到測試套件中，在這種情況下非常有用，因?yàn)橐恍╊~外的組件必須在主機(jī)端運(yùn)行。通過直接在E2E二進(jìn)制文件中運(yùn)行它們，使用dlv進(jìn)行交互式調(diào)試變得更加容易。

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

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

PMEM-CSI存儲測試導(dǎo)Kubernetes存儲測試套件，并為必須已安裝在測試集群中的PMEM-CSI驅(qū)動程序設(shè)置一個供應(yīng)測試實(shí)例。存儲測試套件更改存儲類以使用不同的文件系統(tǒng)類型運(yùn)行測試。由于此要求，存儲類是從.yaml文件創(chuàng)建的。

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

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

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

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

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

Kubernetes E2E框架由測試SIG的testing-commons子項(xiàng)目所有。請參閱該頁面以獲取聯(lián)系信息。

有各種任務(wù)，包括但不限于：

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

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

從Kubernetes E2E測試套件中刪除特定于供應(yīng)商程序的代碼（#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多元化獎學(xué)金現(xiàn)正接受申請
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國
KubeCon + CloudNativeCon + Open Source Summit購票窗口，立即購票！
CNCF邀請你加入最終用戶社區(qū)