本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
將端對端 Kubernetes 測試帶入 Azure (第 1 部分)
在 AppFormix，持續整合測試是我們文化的一部分。我們看到定期執行端對端測試的許多好處，包括最大限度地減少回歸，並確保我們的軟體整體協同工作。為了確保為我們的客戶提供高品質的體驗，我們需要能夠不僅針對我們的應用程式，而且針對整個協調堆疊執行端對端測試。我們的客戶正在採用 Kubernetes 作為他們選擇的容器協調技術，並且他們要求在容器執行地點方面有選擇，從私有基礎架構到公共供應商，包括 Azure。經過幾週的工作，我們很高興地宣布，我們正在貢獻一個每晚的持續整合工作，該工作在 Azure 平台上執行 e2e 測試。在每晚執行 e2e 測試僅幾週後，我們已經在 Kubernetes 中發現並修復了兩個問題。我們希望我們對 e2e 工作的貢獻將有助於社群在 Kubernetes 不斷發展的同時維持對 Azure 平台的支援。
在這篇部落格文章中，我們描述了我們為 Azure 平台實作部署腳本的歷程。部署腳本是我們正在貢獻的 e2e 測試工作的前提條件，因為這些腳本使我們的 e2e 測試工作能夠測試 Kubernetes master 分支的最新提交。在後續的部落格文章中，我們將描述 e2e 測試的詳細資訊，這些測試將有助於維持對 Azure 平台的支援，以及如何將聯邦 e2e 測試結果貢獻給 Kubernetes 專案。
背景
雖然 Kubernetes 旨在在任何 IaaS 上運行，並且 解決方案指南 適用於包括 Google Compute Engine、AWS、Azure 和 Rackspace 在內的許多平台，但 Kubernetes 專案將這些稱為「版本化發行版」，因為它們僅針對 Kubernetes 的特定二進制版本進行測試。另一方面，「開發發行版」每天由最新的 Kubernetes 原始碼的自動化 e2e 測試使用，並作為程式碼提交的閘道檢查。
當我們首次調查 Azure 上對 Kubernetes 的現有支援時，我們發現了有關使用 CoreOS 和 Weave 在 Azure 上運行 Kubernetes 的文件。該文件包括 部署腳本，但這些腳本不符合「開發發行版」所需的 cluster/kube-up.sh 自動叢集建立框架。此外，還沒有一個持續整合工作使用這些腳本來使用端對端測試場景（在 Kubernetes 儲存庫的 test/e2e 中找到的那些）驗證 Kubernetes。
透過對專案歷史進行一些額外調查（旁注：git log --all --grep='azure' --oneline 非常有幫助），我們發現之前存在一組與 cluster/kube-up.sh 框架整合的腳本。這些腳本在 2015 年 10 月 16 日被丟棄 (commit 8e8437d)，因為這些腳本自 Kubernetes 1.0 版本之前就無法運作。以這些提交作為起點，我們著手更新這些腳本，並建立受支援的持續整合工作，這將有助於持續維護。
叢集部署腳本
為了在 Azure 上使用 Ubuntu VM 設定 Kubernetes 叢集，我們遵循了先前放棄的提交奠定的基礎，並盡可能嘗試利用現有程式碼。該解決方案使用 SaltStack 進行部署，並使用 OpenVPN 進行 master 和 minion 之間的網路連線。SaltStack 也被其他幾個解決方案用於組態管理，例如 AWS、GCE、Vagrant 和 Vsphere。重新啟用已丟棄的提交是一個起點，但我們很快意識到需要注意的幾個關鍵要素
- 使用 SaltStack 在節點上安裝 Docker 和 Kubernetes
- 為服務配置身份驗證
- 配置網路
叢集設定腳本確保安裝 Docker，將 Kubernetes Docker 映像複製到 master 和 minion 節點，並載入映像。在 master 節點上，SaltStack 啟動 kubelet，kubelet 又啟動以下在容器中運行的 Kubernetes 服務：kube-api-server、kube-scheduler 和 kube-controller-manager。在每個 minion 節點上，SaltStack 啟動 kubelet，kubelet 啟動 kube-proxy。
Kubernetes 服務在相互通訊時必須進行身份驗證。例如，minion 向 master 上的 kube-api 服務註冊。在 master 節點上，腳本產生一個自簽憑證和金鑰，kube-api 將其用於 TLS。Minion 配置為跳過驗證 kube-api 的（自簽）TLS 憑證。我們配置服務以使用使用者名稱和密碼憑證。使用者名稱和密碼由叢集設定腳本產生，並儲存在每個節點上的 kubeconfig 檔案中。
最後，我們實作了網路配置。為了使腳本參數化並最大限度地減少對目標環境的假設，腳本建立了一個新的 Linux bridge 裝置 (cbr0)，並確保所有容器都使用該介面存取網路。為了配置網路，我們使用 OpenVPN 在 master 和 minion 節點之間建立隧道。對於每個 minion，我們保留一個 /24 子網路供其 Pod 使用。Azure 為每個節點分配了自己的 IP 位址。我們還為此 bridge 新增了必要的路由表項目，以使用 OpenVPN 介面。這是確保不同主機中的 Pod 可以相互通訊所必需的。master 和 minion 上的路由如下
master
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.244.2.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 cbr0
minion-1
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 0.0.0.0 255.255.255.0 U 0 0 0 cbr0
10.244.2.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
minion-2
10.8.0.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.244.1.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
10.244.2.0 0.0.0.0 255.255.255.0 U 0 0 0 cbr0
| | 圖 1 - OpenVPN 網路配置 |
未來工作 隨著部署腳本的實作，一部分 e2e 測試案例正在 Azure 平台上通過。每晚的結果發佈到 Kubernetes 測試歷史儀表板。Weixu Zhuang 在 Kubernetes GitHub 上發出了一個 pull request，我們正在積極與 Kubernetes 社群合作，以合併每晚 e2e 測試工作所需的 Azure 叢集部署腳本。部署腳本為 Azure 上的 Kubernetes 提供了最小的工作環境。接下來還有幾個步驟要繼續進行，我們希望社群能夠參與其中以實現它們。
- 只有一部分 e2e 場景正在通過，因為某些雲端供應商介面尚未為 Azure 實作，例如負載平衡器和實例資訊。為此，我們尋求社群的意見和協助，以定義 cloudprovider 介面 (pkg/cloudprovider/) 的 Azure 實作。這些介面將啟用諸如 Kubernetes Pod 公開到外部網路和叢集 DNS 等功能。
- Azure 具有用於與服務互動的新 API。提交的腳本目前使用 Azure 服務管理 API，這些 API 已被棄用。部署腳本中應使用 Azure Resource Manager API。AppFormix 團隊很高興為 Kubernetes 社群貢獻對 Azure 的支援。我們期待收到有關如何共同努力改進 Azure 上 Kubernetes 的回饋。
編者註：想要貢獻 Kubernetes，參與 這裡。有您自己的 Kubernetes 故事想要分享，請告訴我們！
第 II 部分在此處提供 here。