將端到端 Kubernetes 測試帶到 Azure（第 1 部分）

在AppFormix，持續整合測試是我們文化的一部分。我們認為定期執行端到端測試有很多好處，包括最大限度地減少迴歸並確保我們的軟體作為一個整體協同工作。為了確保為客戶提供高質量的體驗，我們不僅需要對我們的應用程式，還需要對整個編排堆疊進行端到端測試的能力。我們的客戶正在選擇Kubernetes作為他們的容器編排技術，他們要求在容器執行地點上擁有選擇權，從私有基礎設施到公共提供商，包括Azure。經過幾周的工作，我們很高興地宣佈，我們正在貢獻一個每晚執行的持續整合作業，該作業在Azure平臺上執行e2e測試。在僅僅幾周的每晚e2e測試執行後，我們已經在Kubernetes中發現並修復了兩個問題。我們希望我們貢獻的e2e作業將幫助社群在Kubernetes發展過程中繼續支援Azure平臺。

在這篇部落格文章中，我們描述了我們為Azure平臺實現部署指令碼所經歷的旅程。部署指令碼是我們正在貢獻的e2e測試作業的先決條件，因為這些指令碼使得我們的e2e測試作業能夠測試Kubernetes主分支的最新提交。在隨後的部落格文章中，我們將詳細描述有助於維護Azure平臺支援的e2e測試，以及如何將聯合e2e測試結果貢獻給Kubernetes專案。

背景

雖然Kubernetes被設計為在任何IaaS上執行，並且存在針對許多平臺（包括Google Compute Engine、AWS、Azure和Rackspace）的解決方案指南，但Kubernetes專案將這些稱為“版本化發行版”，因為它們只針對特定的Kubernetes二進位制版本進行測試。另一方面，“開發發行版”每天被用於針對最新Kubernetes原始碼的自動化e2e測試，並作為程式碼提交的門控檢查。

當我們首次調查Kubernetes在Azure上的現有支援時，我們發現了使用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虛擬機器設定Kubernetes叢集，我們遵循了之前廢棄提交奠定的基礎工作，並嘗試儘可能多地利用現有程式碼。該解決方案使用SaltStack進行部署，使用OpenVPN進行主節點和從節點之間的網路連線。SaltStack也用於其他幾個解決方案（如AWS、GCE、Vagrant和Vsphere）的配置管理。復活被廢棄的提交是一個起點，但我們很快意識到有幾個關鍵元素需要注意：

• 使用SaltStack在節點上安裝Docker和Kubernetes
• 配置服務認證
• 配置網路

叢集設定指令碼確保Docker已安裝，將Kubernetes Docker映象複製到主節點和從節點，並載入映象。在主節點上，SaltStack啟動kubelet，kubelet又會啟動以下在容器中執行的Kubernetes服務：kube-api-server、kube-scheduler和kube-controller-manager。在每個從節點上，SaltStack啟動kubelet，kubelet又會啟動kube-proxy。

Kubernetes服務在相互通訊時必須進行身份驗證。例如，從節點向主節點上的kube-api服務註冊。在主節點上，指令碼生成自簽名證書和金鑰，供kube-api用於TLS。從節點被配置為跳過對kube-api（自簽名）TLS證書的驗證。我們將服務配置為使用使用者名稱和密碼憑據。使用者名稱和密碼由叢集設定指令碼生成，並存儲在每個節點上的kubeconfig檔案中。

最後，我們實現了網路配置。為了使指令碼引數化並最大限度地減少對目標環境的假設，指令碼建立了一個新的Linux網橋裝置 (cbr0)，並確保所有容器都使用該介面訪問網路。為了配置網路，我們使用OpenVPN在主節點和從節點之間建立隧道。對於每個從節點，我們保留一個 /24 子網供其 Pod 使用。Azure為每個節點分配了自己的 IP 地址。我們還添加了必要的路由表條目，以便此網橋使用 OpenVPN 介面。這是為了確保不同主機中的 Pod 可以相互通訊。主節點和從節點上的路由如下：

主節點

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

從節點-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

從節點-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上提交了一個拉取請求，我們正在積極與Kubernetes社群合作，以合併每晚e2e測試作業所需的Azure叢集部署指令碼。部署指令碼為Azure上的Kubernetes提供了一個最小的工作環境。接下來還有幾個步驟需要繼續這項工作，我們希望社群能參與進來以實現這些目標。

• 只有一部分e2e場景透過，因為Azure尚未實現一些雲提供商介面，例如負載均衡器和例項資訊。為此，我們尋求社群的意見和幫助，以定義雲提供商介面 (pkg/cloudprovider/) 的 Azure 實現。這些介面將啟用 Kubernetes Pod 暴露到外部網路和叢集 DNS 等功能。
• Azure有與服務互動的新API。提交的指令碼目前使用已棄用的Azure服務管理API。部署指令碼應該使用Azure資源管理器API。AppFormix團隊很高興能為Kubernetes社群貢獻對Azure的支援。我們期待收到關於我們如何共同改進Azure上Kubernetes的反饋。

編者按：想要為 Kubernetes 貢獻力量，請點選這裡參與。如果您有自己的 Kubernetes 故事想分享，請告訴我們！

第二部分可在此處獲取。

• ←上一篇
• 下一篇→