雲平台架構測試（k8s+docker）

雲平台架構測試基礎檢查點

      雲平台基礎架構測試，在筆者看來，最重要的是保證叢集的穩定性，健壯性，面對各種 突發情況都可以自動處理，保證業務功能邏輯正常，資料正常。主要關注叢集節點、叢集基 礎元件、叢集服務等。目前各種雲平台都采用了各種主從結構的叢集方式，例如：一主多從， 多主等形式，采用了各種 HA 政策，有叢集本身的 HA，有基礎元件的 HA，也有微服務本身 的 HA，基礎元件和微服務的差別是是否儲存狀态服務，是否持久化資料存儲這些，有興趣 可以下來了解一下，每個元件都有自己的特點，例如 mysql 本身的主從同步政策和資料盤日 志盤大小等，rabbitmq 出現髒隊列的時候的異常處理等，需要再測試過程中，了解各個元件 的特性，熟悉各個元件的基本操作，然後進行相對的測試設計。 筆者水準有限，全靠腦補，還有很多沒寫的地方，例如：多執行個體測試，是否啟用分布式 鎖，以及微服務鍊路資料檢查，鍊路壓測，資源狀态監控等，有不對的地方，還望指正。

                                                                                                                                                                             -- 成都 - 阿木木

一、全局配置檔案檢查

       一般來說，雲平台在安裝部署過程中，都會進行平台配置，背景在進行叢集部署時，可 能是通過一鍵部署，自動擷取叢集虛機的環境資訊，也可能是手動進行配置檔案的修改配置， 也可能是通過浏覽器界面進行配置。 針對全局配置檔案是否正确初始化進行檢查，各個參數配置錯誤是否有正确的提示資訊， 例如：配置的節點數是否符合規範，大于或者小于是否有正确的提示資訊；配置的 ip 是否 是正确并且可用的 IP，是否是非法 IP 以及被使用過得 IP；防火牆 IP 段是否配置正确，防火 牆 IP 端口是否配置正确，叢集各個節點之間的互信等。

二、叢集各元件配置檢查

雲平台中的各個元件的配置方式同叢集安裝部署的配置是一樣的，要麼通過修改配置檔案，要麼通過浏覽器界面進行配置，主要關注異常情況，是否有正确的提示項。 各個元件的正确配置，以及錯誤參數配置項檢查，是否有正确的提示資訊。

三、叢集安裝和解除安裝檢查

叢集安裝是否正常，各個微服務基礎元件狀态是否正常，頁面資料通路是否正常；叢集解除安裝是否正常，各個微服務包含叢集本的架構解除安裝是否完全解除安裝，是否有殘留的垃圾資料檔案，導緻二次安裝失敗。

四、元件監控安裝解除安裝檢查

叢集通常會安裝一些針對各個元件的監控服務。叢集中針對各個元件的監控子產品的安裝解除安裝是否正常，是否有資料殘留。

五、日志中心檢查

叢集通常會提供一個通用的日志服務，例如 EFK 等。叢集的日志服務是否安裝解除安裝正常；資料老化時間是否正常；當微服務的日志過大時，是否有對應的清理政策。

六、增量包安裝檢查

現在的雲平台都是支援增量安裝功能的，例如 K8S ：通過修改 deployment ， service等配置檔案，完成服務增量安裝，該場景比較常見。針對叢集内部需要增量安裝或更新某些微服務時，是否可以安裝成功，微服務是否可以更新成功，檢查微服務的 image 位址是否更改；微服務本身的執行個體數的修改是否生效，業務功能是否正常。

七、對于依賴公用基礎元件的其他元件安裝檢查

基礎元件本身也是會有依賴的，是以基礎元件啟動先後順序也需要進行檢查，是否可以 正常連接配接，逾時重連，斷線重連，是否有元件本身的 HA 政策等。未安裝公用基礎元件時候，單獨安裝某一個依賴它的元件，

八、NTP 時鐘源配置檢查

NTP 時鐘源是叢集内部需要關注的一個重點，很多時候容易忽視，其實很多時候，我們關注的不是時鐘源是否和公網環境時鐘源同步，更多的是關注叢集各個節點的時間是否同步，當然，如果對于應用界面的資料操作有時間方面的時效性的嚴格要求，那麼保證伺服器時鐘源和 PC 時鐘源同步是非常重要的了。舉個例子，我們在對于叢集各個節點所在虛拟機進行快照的時候，會導緻叢集停頓一段時間，造成資料的寫入不同步，叢集的時間不同步等情況，如果沒有對應的處理機制，會導緻叢集崩潰，各個服務直接 terminal 掉。 未配置時鐘源情況，公網環境是否會自動擷取時鐘源，内網環境各個節點的時鐘源是否會同步；構造主節點和從節點時間跳變情況，檢視叢集時間以及狀态是否正常，時鐘源是否會自動校準。配置了時鐘源情況，不通公網，當本地 PC 和叢集所在伺服器時鐘源不比對情況，叢集時間狀态如何處理。安裝部署叢集後，叢集斷電、斷網情況；修改時鐘源向前或者向後調整情況；叢集恢複後檢視叢集時間以及狀态。當叢集中某一個節點接入了公網，其他節點不接入公網，叢集時間以及狀态是否正常。

九、本地化倉庫檢查

現在的私有雲，公有雲，混合雲，都會有一個鏡像倉庫的概念在裡面，鏡像倉庫通常都是本地倉庫，針對鏡像倉庫所在節點進行測試也是非常有必要的，防止出現鏡像拉取失敗，鏡像的 tar 包加載到本地鏡像倉庫失敗等情況。當本地化倉庫所在 master 節點，或者 node 節點出現問題，例如網絡原因等，從本地化倉庫中拉取鏡像資源是否有正确的提示資訊。

十、磁盤檢查

磁盤大小檢測，防止資料盤不夠元件使用，安裝前或擴容前報錯；資料盤夠元件使用，檢查是否可以正确安裝。磁盤速率檢測，檢查安裝速率等情況，如果不滿足要求，安裝失敗退出。

十一、叢集各節點運作微服務數量狀态檢查

通常一個叢集在安裝完成後，各個節點的微服務是排程中心使用排程算法，根據目前節點的 CPU 、記憶體、磁盤等資訊，計算各個節點運作的微服務數量，各個節點運作的微服務數量應該相差不大。版本安裝後，各個 node 節點的微服務數量應該是均勻配置設定，數量差距不大。

十二、叢集節點突然當機微服務檢查

當某一個叢集節點突然當機後，當機節點的微服務是否可以正确的遷移到正常的 node節點上，并且，微服務恢複正常，頁面資料通路正常。

十三、微服務重新開機檢查

微服務本身也是有調用順序的，通過更改各個微服務的啟用順序，進行檢查。重新開機各個微服務，檢視微服務運作狀态，如果微服務之間有依賴，可以改變重新開機順序，進行檢查，重新開機過後的微服務狀态是否正常。

十四、微服務與元件啟動先後順序檢查

叢集的普通服務除了依賴其他普通服務之外，也會依賴基礎元件，例如：在 K8S 中，有狀态服務通過 statefulset 副本控制器控制，普通服務（無狀态服務）通過 deployment 副本控制器控制，當普通服務依賴于公共基礎元件的時候。如果普通服務先于基礎元件服務啟動，如果普通服務本身沒有 HA ，或者逾時重連、斷線重連機制，那麼，除了手動重新開機普通服務本身可以恢複業務之外，會導緻叢集本身的健壯性有問題，給使用者造成不好的體驗。反過來，如果普通微服務後于基礎元件服務啟動，是否可以正常連接配接元件，保證業務功能正常，資料正常，微服務狀态正常。

十五、微服務運作過程中關閉元件服務再開啟元件微服務的重連機制檢查

叢集中如果出現元件重新開機（元件本身的狀态檢查政策，異常情況重新開機），那麼對于普通微服務來說，是否會重建立立連接配接就是至關重要的了。主要檢查微服務與基礎元件有依賴，基礎元件本身是一個有狀态服務，重新開機有狀态服務時，普通的無狀态微服務可能會斷開連接配接，如果沒有重連（連接配接逾時機制等政策），會導緻微服務不可用。例如 mysql 、 Redis 、 hdfs 、 mongodb 、 fastdfs 、 kafka 、 kong 、 rabbitmq 等元件。普通服務已經連接配接元件的情況，先關閉元件，然後再重新開機，主要是檢查普通服務對于基礎元件的依賴情況，普通服務是否會自動重連，如果說元件本身是一個叢集，關閉某一個元件執行個體，是否會對普通服務提供的業務本身造成影響等等，檢查是雙向的。

十六、微服務首次連接配接元件失敗後的重連檢查

普通服務未連接配接元件的情況，首先關閉基礎元件，然後啟動依賴基礎元件的相關的服務，然後啟動基礎元件，檢視微服務運作狀态是否正常，業務功能是否正常。

十七、節點故障檢查

1、叢集單節點故障，檢查是否啟用 HA 檢查（高可用政策）

叢集單節點故障有很多種原因，通常是該節點已經當機，或者該節點的網絡通信異常，IP 被更改等多種情況，主要周遊主節點和從節點分别出現節點故障的情況，叢集還是否可用，也就是現在常說的高可用政策是否生效檢查。各業務場景運作流量正常上送，當機主節點，不重新開機主節點，叢集的 HA 是否生效，如果是 K8S 叢集， VIP 是否會跟随權重漂移，元件的 HA 政策是否生效，各場景的環境恢複後，微服務自動重新開機或者手動重新開機，各微服務資源占用正常，元件正常，業務功能資料正常。各業務場景運作流量正常上送，當機主節點，并重新開機所有服務，檢查叢集群組件的 HA 是否生效。各業務場景運作流量正常上送，當機從節點，微服務進行節點遷移，各微服務資源占用正常，元件正常，業務功能資料正常。各業務場景運作流量正常上送，當機從節點，微服務進行節點遷移，并且重新開機服務，微服務遷移到該節點，各微服務資源占用正常，元件正常，業務功能資料正常。

2、單節點重新開機組合檢查

各業務場景運作流量正常上送，當機主節點， VIP 是否自動漂移，重新開機主節點， VIP 是否自動漂移回原來的節點，所有元件的 HA 政策是否生效，微服務是否遷移到從節點，各微服務資源占用正常，元件正常，業務功能資料正常。各業務場景運作流量正常上送，當機從節點，微服務是否遷移到其他節點，重新開機從節點，微服務是否自動排程遷移到該節點，各微服務資源占用正常，元件正常，業務功能資料正常。

3、多節點故障組合檢查

各業務場景運作流量正常上送，當機主節點，然後當機從節點， VIP 是否遷移到正常的從節點，各元件的 HA 政策是否生效，各微服務資源占用正常，元件正常，業務功能資料正常。

4、多節點重新開機組合檢查

各業務場景運作流量正常上送，當機主節點，當機從節點，重新開機從節點，再重新開機主節點，檢視 VIP 漂移的過程是否正常，是否會回到原來的主節點，檢視微服務的遷移是否正常，檢視元件的 HA 政策是否生效，各微服務資源占用正常，元件正常，業務功能資料正常。

十八、整個叢集異常斷電重新開機檢查

叢集異常斷電重新開機過程中，可能會導緻叢集本身的一些資料檔案損壞，有些是不可避免的，通常采用雙路電源，或者使用 UPS 等，當某些資料檔案損壞時，我們叢集需要對這些檔案進行處理，使叢集功能恢複運轉。關閉整個叢集後重新開機，所有微服務狀态應該恢複正常，頁面資料，功能正常；拔插伺服器電源，整個叢集斷電恢複後，所有微服務狀态應該恢複正常，頁面資料，功能正常；節點與節點之間重新開機的時間間隔，是否會出現時鐘源不同步的情況，導緻整個叢集崩潰。 **歡迎加入測試交流群：夜行者自動化測試（816489363）進行交流學習QAQ**