當您的應用在進行擴容、部署新版本或預期流量突增時,可以使用ASM慢啟動預熱功能,在自定義的時間窗口內逐步增加請求流量,從而平穩過渡,降低因瞬間壓力過高導致的服務中斷、請求超時及潛在的數據丟失風險,確保應用在伸縮和更新過程中的性能穩定性和高可用性。
前提條件
已創建ASM企業版或者旗艦版實例,且版本為1.14.3及以上。具體操作,請參見創建ASM實例。
已添加集群到ASM實例。具體操作,請參見添加集群到ASM實例。
通過kubectl連接ACK集群。具體操作,請參見獲取集群KubeConfig并通過kubectl工具連接集群。
已創建ASM網關。具體操作,請參見創建入口網關服務。
已部署示例應用Bookinfo。本文以Reviews服務為例,具體操作,請參見在ASM實例關聯的集群中部署應用。
背景信息
在未啟用慢啟動預熱功能時,每當新目標Pod加入時,請求方都會向該Pod發送一定比例的流量,不支持新Pod的漸進式流量增加。這對于需要一些預熱時間來提供全部負載的服務可能是不可取的,并且可能會導致請求超時、數據丟失和用戶體驗惡化。例如在基于JVM的Web應用程序中,這些應用程序使用水平Pod自動縮放。當服務剛啟動時,它會被大量請求淹沒,這會導致應用程序預熱時持續超時。因此,每次擴展服務時,都會丟失數據或者會導致這部分請求的響應時間增加。預熱的基本思想就是讓剛啟動的機器逐步接入流量。
慢啟動預熱功能介紹
慢啟動模式又稱漸進式流量增加,用戶可以為服務配置一個時間段,每當一個服務實例啟動時,請求方會向該實例發送一部分請求負載,并在配置的時間段內逐步增加請求量。當慢啟動窗口持續時間到達,就會退出慢啟動模式。
在慢啟動模式下,添加新的目標服務Pod時,避免新增Pod被大量請求擊垮,這些新目標服務可以根據指定的加速期在接受其均衡策略的請求之前進行預熱。
慢啟動對于依賴緩存并且需要預熱期才能以最佳性能響應請求的應用程序非常有用。在ASM下,您只需在服務對應的DestinationRule下的配置trafficPolicy/loadBalancer
即可,需要注意的是:
loadBalancer:表示負載均衡器信息。類型限定于ROUND_ROBIN和LEAST_REQUEST負載均衡器。
warmupDurationSecs:表示Service的預熱持續時間。如果設置,則新創建的服務端點在此窗口期間從其創建時間開始保持預熱模式,并且Istio逐漸增加該端點的流量,而不是發送成比例的流量。
慢啟動要求應用在當前可用區的副本數不為0。例如:
數據面集群只有一個可用區A,可用區A中當前有一個副本,啟動第二個時,慢啟動會生效。
數據面集群有兩個可用區A、B,當前應用只有一個副本,且位于可用區A,如果啟動的第二個副本位于可用區B(一些調度器會默認采用跨可用區分布的策略),則不會觸發慢啟動。此時,如果再啟動第三個副本,慢啟動會生效。
DestinationRule的YAML示例如下:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mocka
spec:
host: mocka
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
warmupDurationSecs: 100s
步驟一:配置路由規則并訪問入口網關
為方便演示,本文先將Reviews的v3版本的Deployment副本數調整為0,即在Kubernetes集群中將名為reviews-v3的Deployment部署的副本數縮容為0。
定義訪問入口。
使用以下內容,創建bookinfo-gateway.yaml文件。
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: bookinfo spec: gateways: - bookinfo-gateway hosts: - '*' http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 - match: - uri: prefix: /reviews route: - destination: host: reviews port: number: 9080
執行以下命令,部署bookinfo-gateway。
kubectl apply -f bookinfo-gateway.yaml
創建Reviews服務。
使用以下內容,創建reviews.yaml文件。
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: ROUND_ROBIN
執行以下命令,部署Reviews。
kubectl apply -f reviews.yaml
開啟網格拓撲, 持續訪問入口網關地址。
本文以通過hey命令發送壓測請求10s為例。關于hey命令的下載和安裝,請參見hey;關于開啟和查看網格拓撲的具體操作,請參見查看應用的網格拓撲。
hey -z 10s -q 100 -c 4 http://${網關地址}/reviews/0
調用拓撲示例圖如下:
步驟二:通過可觀測數據查看Pod啟動
登錄ASM控制臺。
在左側導航欄,選擇 。
在網格管理頁面,找到待配置的實例,單擊實例的名稱或在操作列中單擊管理。
在左側導航欄單擊 。
ASM實例版本為1.17.2.35以下:在監控指標頁面,單擊監控儀表頁簽,然后單擊網格服務級別監控頁簽,選擇對應的Reviews服務。
ASM實例版本為1.17.2.35及以上:在監控指標頁面,單擊網格工作負載級別監控頁簽,選擇對應的reviews-v3工作負載,選擇Reporter為source。
發送壓測請求并觀察監控數據。
在未開啟預熱功能的情況下,在Kubernetes集群中將名為reviews-v3的Deployment部署的副本數從0擴容為1。
執行以下命令,發送壓測請求入口網關。
本文以發送壓測請求120s為例。
hey -z 120s -q 100 -c 4 http://${網關地址}/reviews/0
觀察Prometheus監控的儀表盤數據。
大約需要45s左右,reviews-v3 Pod將接收均衡的請求(具體時間會跟實際壓測環境有關)。
在Kubernetes集群中將名為reviews-v3的Deployment部署的副本數縮容為0。
步驟三:啟用預熱功能
使用以下內容,更新reviews.yaml文件。
增加
warmupDurationSecs
字段,配置為120s
,即定義預熱持續時間為120s。apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: ROUND_ROBIN warmupDurationSecs: 120s
執行以下命令,更新Reviews。
kubectl apply -f reviews.yaml
步驟四:查看預熱效果
開啟預熱功能后,在Kubernetes集群中將名為reviews-v3的Deployment部署的副本數從0擴容為1。
執行以下命令,發送壓測請求入口網關。
本文以發送壓測請求150s為例。
hey -z 150s -q 100 -c 4 http://${網關地址}/reviews/0
在網格服務級別監控頁簽中,觀察Prometheus監控的儀表盤數據。
大概需要120s左右,reviews-v3 Pod將接收均衡的請求(具體時間會跟實際壓測環境有關)。由于Metrics的采集時間間隔限制,這條曲線并不平滑。實際上,到達reviews-v3 pod的流量是平滑增長的,如果您開啟了Sidecar日志采集,可以在SLS中搜索這個Sidecar對應的日志,可以看到近5分鐘的日志量。在啟用預熱功能的情況下,每當一個服務實例啟動時,請求方會向該實例發送一部分請求負載,并在配置的時間段內逐步增加請求量。當慢啟動窗口持續時間到達,就會退出慢啟動模式。
啟用預熱功能之后,需要2分30秒左右,流量將均衡地分布到v1、v2、v3版本。
相關文檔
您可以配置本地限流或全局限流,將流量維持在可控的閾值內,確保服務持續可用并維持性能穩定。具體操作,請參見在流量管理中心配置本地限流和使用ASMGlobalRateLimiter對應用服務入口流量配置全局限流。
您可以使用ASMAdaptiveConcurrency實現自適應并發控制,根據采樣的請求數據動態調整允許的并發的數量,當并發數量超過服務可承受范圍時拒絕請求,達到保護服務的目的。具體操作,請參見使用ASMAdaptiveConcurrency實現自適應并發控制。
您可以配置連接池實現熔斷功能,在系統出現故障或超負荷的情況下,保護系統免受進一步的損害。具體操作,請參見配置連接池實現熔斷功能。