你們對Kubernetes基礎架構進行自動化測試了嗎？
軟件測試
軟件開發中的自動化測試是保障軟件質量不可或缺一部分。隨著容器化技術的不斷發展，Kubernetes已經是事實上的標準。那么，通過自動化的方式驗證像Kubernetes這樣的基礎架構的有效性，也越來越重要。這篇文章就介紹如何利用和擴展現有工具來測試Kubernetes的集群。
為什么要測試?
為什么要利用自動化集群測試的原因有很多。Kubernetes是一個非常復雜的系統，由多個獨立的組件組成。他們在一種配置中能夠正常運行并不意味著他們將在每種配置中都能完美的運行。
通過使用諸如kubeadm或kops之類的安裝程序，或設置集群的其他方法，有多種啟動Kubernetes集群的方法。對于每種方式，都有許多配置選項，使兩個配置看起來不一樣。在用戶使用集群之前對其進行測試，以確保我們的設置能夠按預期執行，從而為用戶提供了一個可用的、有價值的平臺。但是，集群設置只是第一步，這是因為Kubernetes的更新頻繁的發布。這個時候，測試就有其作用了，可用驗證更新之后基本的集群功能仍然可用。
不過，Kubernetes不僅僅是一個平臺，它還是一個通過插件和附加組件進行擴展的框架。因此，沒有一個Kubernetes集群是以一種同樣的方式運行。Kubernetes自己的測試不包括插件，因此測試范圍僅取決于插件開發人員的測試。為了確保我們的插件不會相互干擾或影響到Kubernetes，我們還應該在設置中對其進行測試。對于您自己編寫的插件來說尤其如此。
一致性測試
Kubernetes一致性測試是測試Kubernetes核心功能的端到端測試用例的子集。用開發人員小組的話就是，“目前的測試僅是測試可用，API的必須的功能”，通過這些測試的集群就是合格的，并且可以通過CNCF k8s合格工作組的認證。
目前，能夠測試的功能包括創建API對象，在節點上啟動容器和掛載基本卷以及對kubectl進行測試。不包括可選功能，例如基于角色的訪問控制，NetworkPolicy和PodSecurityPolicy。插件和附加組件也大多不受一致性測試的限制，例如，對DNS進行測試，但某些測試僅隱含地要求使用Weave或Calico等插件進行聯網。將來，也可能會通過一致性測試配置文件對插件進行測試，但目前需要分別對其進行測試。
但是，他們對基本集群功能的驗證使一致性測試成為測試集群的理想起點。要執行這些測試，我們可以使用諸如kubetest或sonobuoy之類的工具。
kubetest
kubetest是Kubernetes管道中使用的CLI工具，用于運行端到端的測試。由于一致性測試是端到端測試的子集，因此可以使用kubetest通過過濾要運行的測試來在集群上運行它們。
- # 安裝最新版本的kubetest
- go get -u k8s.io/test-infra/kubetest
- #測試需要匹配集群版本
- K8S_VERSION=$(kubectl version -o json | jq -r '.serverVersion.gitVersion')
- # 設置該變量為y
- export KUBERNETES_CONFORMANCE_TEST=y
- # 顯示設置配置
- export KUBECONFIG=”$HOME/.kube/config”
- # 運行該測試，skeleton是目前的集群
- kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\[Conformance\]” --extract ${K8S_VERSION}
當下載并提取了我們集群版本所需的Kubernetes二進制文件之后，將會執行所有標記為[Conformance]的測試。還可以使用并行測試來縮短測試運行的時間。
- kubetest --provider=skeleton --test --ginkgo.parallel
- --test_args=”--ginkgo.focus=\[Conformance\] --ginkgo.skip=\
- [Serial\]” --extract ${K8S_VERSION}
- kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\
- [Serial\].*\[Conformance\]” --extract ${K8S_VERSION}
您還可以只運行一次kubetest extract，然后從Kubernetes目錄中執行測試以加快后續執行速度。為了進行調試，您還可以告訴kubetest不要刪除測試失敗的名稱空間：
- kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\
- [Conformance\] --delete-namespace-on-failure=false” --extract
- ${K8S_VERSION}
盡管kubetest具有高度可定制性，但它不一定是面向最終用戶的，其標志很少被記錄且經常引起混淆。為了簡單地運行一致性測試，Heptio發布了Sonobuoy，從而簡化了此過程。
Sonobuoy
Sonobuoy是一種診斷工具，可以運行Kubernetes一致性測試。它由一個CLI組成，該CLI啟動一個pod來管理集群中的測試運行，并讓您隨后檢索結果。它是一個簡單的即用型解決方案，是用于運行一致性測試的標準工具。
我們還可以選擇使用kubetest和Sonobuoy來運行端到端測試套件的其他測試，以測試我們的某些插件。例如，如果我們要在集群中使用網絡策略，則可能應該測試它們是否被強制執行。可以使用Sonobuoy進行如下基本測試：
- # 執行sonobuoy, 覆蓋掉默認的skip和focus參數
- sonobuoy run --e2e-focus="\[Feature:NetworkPolicy\]" --e2e-skip=""
這些測試創建了受其限制的基本網絡策略和Pod，并驗證了它們是否在集群中得到了強制執行(請注意，它們并未驗證集群中存在的策略是否按預期工作，因此可以使用netassert或illuminatio之類的工具使用)。對于其他功能也存在類似的測試。
編寫自己的端到端測試
你也可以寫自己的端到端測試用于集群的設置。這在運行本地開發的附件時特別有用，因為單元測試幾乎無法模仿正在運行的Kubernetes集群的行為。要在Golang中開發測試，可以使用Kubernetes本身的E2E框架。
如果您使用其他編程語言，則仍然可以使用kubernetes客戶端庫，但是您必須自己編寫一些樣板代碼，例如，用于設置和拆除測試名稱空間。像pytest之類的單元測試框架對于將測試用例以及運行測試和收集結果分開仍然很有用。
無論您是剛剛開始Kubernetes之旅，還是已經在生產環境中運行集群好多年，都認為您應該立即開始測試這些集群。運行Sonobuoy在管道中進行一致性測試，開始對您使用的功能進行一些E2E測試，并為導致集群故障太多次的組件開發自己的測試。這將使操作更加輕松，并讓您高枕無憂。
