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

作者：Patrick Ohly（英特爾）

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

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

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

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

PMEM-CSI

測(cè)試這些驅(qū)動(dòng)程序是大多數(shù)這些增強(qiáng)功能的主要?jiǎng)訖C(jī)。

E2E測(cè)試包括幾個(gè)階段：

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

啟動(dòng)測(cè)試集群。像kubetest這樣的工具可以幫忙。

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

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

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

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

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

E2E測(cè)試套件的作者決定將哪些軟件包導(dǎo)入測(cè)試套件。然后通過--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)行測(cè)試套件后通過ssh檢索日志

測(cè)試可能必須在運(yùn)行時(shí)讀取其他文件，例如.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框架過去對(duì)go-bindata的輸出有很強(qiáng)的依賴性，現(xiàn)在bindata支持是可選的。通過testfiles包訪問文件時(shí)，將從不同的源檢索文件：

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

零個(gè)或多個(gè)bindata塊

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

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

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

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

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

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

但是，最近有人指出，比較可取且有可能不將測(cè)試設(shè)置公開為命令行標(biāo)志，只能通過配置文件設(shè)置它們。關(guān)于這個(gè)有一個(gè)開放的bug和一個(gè)待定的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í)，也可以設(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è)置幾個(gè)參數(shù)。請(qǐng)注意Viper的一個(gè)限制仍然存在：它通過匹配已知標(biāo)志的配置文件條目，而不會(huì)發(fā)出有關(guān)未知配置文件條目的警告，從而不會(huì)檢測(cè)到錯(cuò)別字。Kubernetes的更好的配置文件解析器仍在開發(fā)中。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

即使消除了許多不必要的依賴關(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文件是一個(gè)很好的起點(diǎn)。它啟用了修剪（默認(rèn)情況下未在dep中啟用）并將某些項(xiàng)目鎖定到與所使用的Kubernetes版本兼容的版本上。當(dāng)dep沒有選擇兼容的版本時(shí)，檢查Kubernetes的Godeps.json有助于確定哪個(gè)版本可能是正確的版本。

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

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

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

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

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

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

從Kubernetes E2E測(cè)試套件中刪除特定于供應(yīng)商程序的代碼（#70194）。

特別感謝本文的審閱者：

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

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

KubeCon + CloudNativeCon + Open Source Summit大會(huì)日期：

會(huì)議日程通告日期：2019 年 4 月 10 日

會(huì)議活動(dòng)舉辦日期：2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon + Open Source Summit贊助方案
KubeCon + CloudNativeCon + Open Source Summit多元化獎(jiǎng)學(xué)金現(xiàn)正接受申請(qǐng)
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國
KubeCon + CloudNativeCon + Open Source Summit購票窗口，立即購票！
CNCF邀請(qǐng)你加入最終用戶社區(qū)