基於Kubernetes的分佈式壓力測試方案

原文連接php

 

 

壓力測試是用來檢測系統承載能力的有效手段。在系統規模較小的時候,在一臺空閒的服務器上使用abwrksiege等工具發起必定量的併發請求便可獲得一個初步的測試結果。但在系統複雜度逐步提升,特別是引入了負載均衡,微服務架構後,單機的壓力測試方案再也不可用,企業須要搭建分佈式測試集羣或者付費使用外部供應商提供的壓力測試服務。html

不論是採起自主搭建或是採用外購的手段,都會面臨系統使用率不高以及成本的問題。基於Kubernetes的動態資源調度功能,以及Kubernetes集羣的動態伸縮特性,咱們能夠充分利用集羣內的閒置計算資源,在須要進行壓力測試時啓動測試節點,在測試結束後釋放資源給其餘業務,甚至經過集羣擴容和縮容臨時爲壓力測試提供更多的計算資源。python

支持分佈式部署的壓力測試工具備多款,今天咱們將介紹在Kubernetes集羣中使用Tsung進行壓力測試的方法。mysql

Tsung

Tsung是一款使用Erlang開發的分佈式壓力測試系統,它支持HTTP,Jabber,MySQL等多種協議,能夠用於不一樣場景的壓力測試。與傳統的針對單一測試目標重複請求的壓測系統不一樣,Tsung更側重於模擬真實使用場景。測試人員指定新用戶到訪頻率,並設定一系列的模擬操做請求。全部的Slave節點將在Master節點的統一調度下,按照到訪頻率建立虛擬用戶,併發送操做請求。
全部請求的耗時以及錯誤信息將傳回Master節點用於統計和報表。git

選擇Tsung主要有三方面的考慮:github

  • 性能優越。Erlang語言天生就是爲高併發網絡系統設計的。合理配置的Tsung集羣能夠實現100W以上的併發流量。
  • 描述式的配置方法。不論簡單仍是複雜,Tsung均統一使用XML文件描述整個測試步驟以及各類參數。這樣能夠在集羣架構保持不變時完成各類測試。
  • 模擬真實用戶的測試理念。在真實場景中,用戶會訪問系統的各項功能。只有支持模擬真實用戶的壓力測試系統才能比較準確的反應系統各個部分在壓力下的狀態,找到瓶頸環節。

因爲Tsung採起的工做模式是在配置中註明Slave地址,而後由Master連上Slave完成測試,傳統的部署方法是啓動多臺物理機或者虛擬機,分別配置它們。在這種工做模式下,會產生大量的運維工做,同時這些計算資源在不進行測試時處於閒置狀態,下降了硬件使用率。sql

在Kubernetes中使用容器運行Tsung

利用Kubernetes強大的調度能力,咱們能夠將Tsung運行在容器當中,動態的啓動和刪除。當須要提升測試規模時,咱們僅須要使用Archon等已有的工具對集羣進行擴容,就能夠很方便的一鍵擴容Slave的數量,幾乎沒有帶來任何的運維負擔。docker

如下是具體的操做流程:apache

建立Namespace

$ kubectl create namespace tsung 

使用StatefulSet部署Tsung Slave

這裏不能使用Deployment,只有使用StatefulSet才能在爲每個Pod分配獨立的內部域名,供Master鏈接。api

將如下文件保存爲tsung-slave-svc.yaml

apiVersion: v1 kind: Service metadata: labels: run: tsung-slave name: tsung-slave spec: clusterIP: None selector: run: tsung-slave ports: - port: 22 type: ClusterIP 

將如下文件保存爲tsung-slave.yaml

apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: tsung-slave spec: serviceName: "tsung-slave" replicas: 1 template: metadata: labels: run: tsung-slave spec: containers: - name: tsung image: ddragosd/tsung-docker:1.6.0 env: - name: SLAVE value: "true" 

在Kubernetes中建立相應的資源

$ kubectl create -f tsung-slave-svc.yaml --namespace tsung $ kubectl create -f tsung-slave.yaml --namespace tsung 

這裏咱們設置了StatefulSetserviceName字段,這樣啓動的Pod在集羣內部就能夠經過tsung-slave-0.tsung-slave.tsung.svc.cluster.local
這個域名訪問到。

使用StatefulSet部署Tsung Master

與Slave相似,Master節點也要求能夠在集羣內部經過域名訪問。因此咱們依然須要使用StatefulSet來運行。

將如下文件保存爲tsung-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: tsung-config
data:
  config.xml: |
    <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd" []> <tsung loglevel="warning"> <clients> <client host="tsung-slave-0.tsung-slave.tsung.svc.cluster.local" /> </clients> <servers> <server host="target" port="8000" type="tcp"/> </servers> <load> <arrivalphase phase="1" duration="1" unit="minute"> <users arrivalrate="100" unit="second"/> </arrivalphase> </load> <sessions> <session name="es_load" weight="1" type="ts_http"> <for from="1" to="10" incr="1" var="counter"> <request> <http url="/" method="GET" version="1.1"></http> </request> </for> </session> </sessions> </tsung> 

將如下文件保存爲tsung-master-svc.yaml

apiVersion: v1 kind: Service metadata: labels: run: tsung-master name: tsung-master spec: clusterIP: None selector: run: tsung-master ports: - port: 8091 sessionAffinity: None type: ClusterIP 

將如下文件保存爲tsung-master.yaml

apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: tsung-master spec: serviceName: "tsung-master" replicas: 1 template: metadata: labels: run: tsung-master spec: containers: - name: tsung image: ddragosd/tsung-docker:1.6.0 env: - name: ERL_SSH_PORT value: "22" args: - -k - -f - /tsung/config.xml - -F - start volumeMounts: - mountPath: /tsung name: config-volume volumes: - configMap: name: tsung-config name: config-volume 

在Kubernetes中建立相應的資源

$ kubectl create -f tsung-config.yaml --namespace tsung $ kubectl create -f tsung-master-svc.yaml --namespace tsung $ kubectl create -f tsung-master.yaml --namespace tsung 

當Tsung Master的容器被啓動後,它會自動開始運行壓力測試。在上面的列子中,Tsung將向http://target:8000發起爲期1分鐘的壓力測試,在測試期間,每秒鐘產生100個模擬用戶,每一個用戶訪問10次目標地址。

咱們將Tsung的配置文件用ConfigMap注入到了Master容器當中,這樣用戶僅須要修改tsung-config.yaml的內容,就能夠方便的定義符合本身要求的測試。在實際使用過程當中,用戶能夠自主調整測試持續時間,虛擬用戶產生速度,目標地址等參數。用戶還能夠經過修改tsung-slave.yamlreplicas的數值,並將更多的Slave地址加入到tsung-config.yaml當中,來得到更多的測試資源,進一步增長負載量。

在Master的運行參數中,咱們使用的-k參數將使得Master在測試完成後仍處於運行狀態,這樣用戶能夠經過8091端口訪問到測試結果。

$ kubectl port-forward tsung-master-0 -n tsung 8091:8091 

以後在本地經過瀏覽器訪問http://localhost:8091便可打開Tsung內置的報表界面。以下圖所示:

tsung_report

另外-F參數讓Master使用FQDN地址訪問Slave節點,這項參數很是關鍵,缺乏它將致使Master沒法正常鏈接上Slave。

資源回收

測試結束後,用戶可使用報表界面查看和保存結果。當全部結果被保存下來以後,能夠直接刪除Namespace完成資源回收。

$ kubectl delete namespace tsung 

這樣全部的Tsung相關配置和容器均會被刪除。當下次須要測試時,能夠從一個全新的狀態開始新一次測試。

總結

本文主要介紹了在Kubernetes中部署Tsung這款分佈式壓力測試系統的方法。其中使用StatefulSet配合-F參數的方法,使得Master和Slave能夠順利的使用域名找到對方,成功的解決了在容器中運行Tsung會遇到的訪問問題。

本來須要專業的運維工程師投入很多時間才能搭建起來的Tsung測試集羣,在Kubernetes中幾乎能夠絕不費力的啓動起來,完成測試。這種使用調度器充分利用集羣空閒資源,使用後及時釋放供其餘系統使用的方法,也充分體現了Kubernetes的優越性。

在下一篇分享中,咱們將使用本文所描述的測試系統,對主流的Python WSGI服務器進行壓力測試,用以對比各個服務器的性能指標。但願經過這種實戰演示的方式,幫助你們深刻了解Tsung以及Kubernetes。敬請期待。

 

原文連接

 

相關文章
相關標籤/搜索